RE: Proposal: Pooled memory management
Manuel wrote:
[...] * I want to get v1.0 of the spec fixed. We are really only in bug fix mode for quite a while and only the finalizer problems held us back from finishing the spec.
That's OK and I understand your motivation. Let's finish v1.0 first.
I agree, but I don't have any problem with forking the spec at this point. The changes to the current 1.0 RC are going to be very small from now on.
In a nutshell: Let's include as many useful "patterns" in the next FFI spec versions as possible! Otherwise we might talk the same language without recognizing it...
So we might well ask what useful new functionality is provided by a pool-style memory manager. One feature is performance: compared to using malloc/free, a pool is going to be much cheaper. But I'd be interested to compare the performance you get from using pools to GHC's implementation of mallocForeignPtr, which also sidesteps malloc/free to get decent performance. Compared to mallocForeignPtr, there are some qualitative differences which might make one or the other more convenient in some situations: - mallocForeignPtr provides garbage-collected storage. No need to free the storage later. - However, you do need to use withForeignPtr to get access to the object. This can be quite annoying. So, assuming the performance is roughly the same (I'm guessing that using pools may be slightly faster than mallocForeignPtr, but not significantly), do people see any other compelling reasons to be using pools? GHC's runtime has an Arena abstraction which is an implementation of pool-style memory management, and could be used to implement Pools, BTW. Cheers, Simon
Simon Marlow wrote:
[...] So we might well ask what useful new functionality is provided by a pool-style memory manager.
Well, I guess that about 90% of the hierarchical libraries don't provide any "new" functionality, but nevertheless they provide useful abstractions. The same holds for my proposal.
One feature is performance: [...]
That's a nice bonus, but I didn't have that in mind.
So, assuming the performance is roughly the same [..], do people see any other compelling reasons to be using pools?
I see the same compelling reasons as the ones for using foldl, sum, sequence, mapM, when, allocArray, with, ... :-)
GHC's runtime has an Arena abstraction which is an implementation of pool-style memory management, and could be used to implement Pools, BTW.
Nice, I wasn't aware of that. Cheers, S.
On 20-Jan-2003, Simon Marlow <simonmar@microsoft.com> wrote:
So, assuming the performance is roughly the same (I'm guessing that using pools may be slightly faster than mallocForeignPtr, but not significantly)
I am not yet convinced that this is a reasonable assumption if you are considering a wide range of Haskell implementations. Some Haskell implementations might use conservative collectors, and others (e.g. for .NET or JVM) may use collectors which are tuned for imperative/OO applications. On such implementations there might well be significant performance advantages to using pool-based manual memory management rather than garbage collection. In particular I suspect that pool-based manual memory management operations can be O(1) in some situations when non-copying GC'd allocation would be O(live data). I have observed significant overall speed-ups (e.g. for the Pseudoknot benchmark, about a factor of two) from using pool-like memory management rather than the Boehm collector. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
participants (3)
-
Fergus Henderson -
Simon Marlow -
Sven Panne