Replacement for GMP: Update

[skaller]

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