On 09/17/2011 03:13 AM, dsimcha wrote:
On 9/16/2011 7:51 PM, Timon Gehr wrote:
4. I'd be worried about garbage collector performance, although this is
less of a concern than the others because it's not too difficult to work
around if you know you need performance up ahead.
Work around it, or develop a faster garbage collector. Again,
1000000000$.
BTW, the GC has massively improved in the past 7 months. It's no Java
Hotspot GC but I did make some optimizations that, depending on use
case, make it between 25% and 1,000 **times** faster in DMD 2.053 and up
than in previous releases. Additionally, the 64-bit support (since
2.052) reduces false pointer problems by making the address space more
sparse and the NO_INTERIOR flag (added in 2.055) and its internal use
with associative arrays further mitigates false pointer problems.
That is nice to hear, thanks! But as long as it is a simple mark and
sweep GC, it will be very slow. I have written some nice 'GC benchmarks'
while playing with the language, eg see:
http://pastebin.com/C6vf9DQQ
That program computes some hamming numbers in haskell-lazy-functional
style. It takes around 20min with GC turned on, and iirc about 20s with
GC turned off (on bearophiles machine, it runs out of memory on mine).
All the GC allocations are from closures.
