Replacement for GMP: Update

Simon Peyton-Jones simonpj at microsoft.com
Fri Aug 11 05:25:51 EDT 2006


The issue isn't that malloc is slow, but rather that we don't know when
to call 'free'.   To make sure that we do call free, we must make GHC's
garbage collector remember when it drops the reference to the object,
and then call free.  That is what Peter refers to as the ForeignPtr
solution.  It's gotten a lot cheaper in GHC 6.6 than it used to be, so
it's worth trying.  A merit of the approach is that is avoids fiddling
with the bignum allocator at all.

Simon

| -----Original Message-----
| From: glasgow-haskell-users-bounces at haskell.org
[mailto:glasgow-haskell-users-bounces at haskell.org]
| On Behalf Of skaller
| Sent: 11 August 2006 09:21
| To: Bulat Ziganshin
| Cc: Peter Tanski; glasgow-haskell-users at haskell.org
| Subject: Re: Re[2]: Replacement for GMP: Update
| 
| On Fri, 2006-08-11 at 09:34 +0400, Bulat Ziganshin wrote:
| 
| > why you say that ForeignPtr is slow? afaik, malloc/free is slow, but
| > starting from ghc 6.6 speed of _using_ ForeignPtr is the same as for
Ptr
| 
| Er, malloc/free is not slow .. its very fast. I implemented
| an arena based allocator (one which just increments a pointer)
| and it was slower than malloc .. ok so my implementation was
| naive, but still, that does make malloc pretty good.
| 
| After all on the average call where an object of that
| size is free already it is a single array lookup, we have:
| 
| (a) fetch pointer (one read)
| (b) fetch next (one read)
| (c) store next as current (one write)
| 
| It is very hard to beat that. Indeed, the whole cost
| of this technique is probably in the mutex
| based locking that wraps it on a multi-processor.
| 
| A purely functional system -- one which does NOT convert
| self tail calls into jumps and reuse storage -- can
| perhaps be faster, since each thread can have its own
| local arena to allocate from (without need of any write
| barrier) .. however it isn't clear to me what the trade
| off is between cache misses and parallelism.
| 
| Doesn't Haskell do that optimisation?
| 
| It is of course hard to test this today without a
| fairly expensive box with enough CPUs on the one bus.
| 
| --
| John Skaller <skaller at users dot sf dot net>
| Felix, successor to C++: http://felix.sf.net
| 
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users at haskell.org
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


More information about the Glasgow-haskell-users mailing list