On 21 August 2006 16:20, Bulat Ziganshin wrote:
Hello Simon,
Monday, August 21, 2006, 6:55:47 PM, you wrote:
Parallel major GC was worked on by Roshan James during his
internship here this summer, and we have some working code, but it
needs a lot more testing and tuning, and it may be
Hello Simon,
Monday, August 21, 2006, 6:55:47 PM, you wrote:
is not exactly true. look at Non-stop Haskell
Simply because it adds overhead (both in runtime and code complexity), and the
benefits are relatively modest.
i think that GC that don't stops the world is just a different
product.
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
| To: Bulat Ziganshin
| Cc: Peter Tanski; glasgow-haskell-users@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
Simon PJ and Bulat,
[the] ForeignPtr
solution [has] 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.
I actually did not know that until today; I have tried to keep up
with the
John,
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)
This is true for memory access; it is not true for memory
allocation. I do
On Fri, 2006-08-11 at 18:56 -0400, Peter Tanski wrote:
John,
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)
This is true
Hello Simon,
Wednesday, August 2, 2006, 4:05:51 PM, you wrote:
(2) We're concerned about performance. Replacing GMP, but losing
substantial performance on bignum-intensive programs would be
unattractive.
don't forget about speed/memory efficiency of any programs that use
Integer just for
Hi Bulat,
don't forget about speed/memory efficiency of any programs that use
Integer just for case but really most of their numbers fit in 32/64
bits. i have one particular program of this type - it builds list of
all files on disk and Integers are used to save filesizes. i will be
glad if,
