I have finally gotten around to what I have been promising to do for years and implemented a garbage collector for jhc. It is still fairly rough, but is very promising. In truth, I was worried it might kill jhc's performance advantage, but quite the opposite, it actually improves the performance of several benchmarks, and doesn't cut too deep into jhc's speed advantage in others. In particular, it seems to help ones where jhc did particularly worse than ghc, I had always assumed those cases were due to some pathological case in an inner loop that ghc was able to catch but jhc wasn't, but it turns out the presence of the GC played some role in their speed. I am not sure whether it is the short circuiting redirects or memory locality that is helping. In any case, JGC seems to be a couple times faster than the boehm collector so all in all, it is a good option to have. Right now, using jgc means you have to link against the judy library, this restriction may or may not be lifted in the future. libJudy is an amazingly useful and versatile library, keeping the GC information stored independently of the heap allows me to garbage collect without trouncing all over the memory space and I think this is key to getting acceptable performance from the GC. I am actually quite pleased with the results, the implementation is a very naive mark-and-don't-quite-sweep collector and achieves good performance, in particular, it isn't even generational. So there is still a fair amount of room for speed improvement. The GC is still experimental, it still doesn't support some features like IORefs and the method for collecting gc roots is fairly brute force and sloppy, but the essential work is done. John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
On Thu, Apr 8, 2010 at 11:30 AM, John Meacham
I have finally gotten around to what I have been promising to do for years and implemented a garbage collector for jhc.
YAAAAAAAAY!
--
Taral
Hi people
I'm a little outdated regarding the current status of jhc. As John said he'd
wired in a garbage collector, does it mean that jhc doesn't use region
inference anymore?
I've set up a party today so I can impress the girls with that... (just
kidding :-)
2010/4/8 John Meacham
I have finally gotten around to what I have been promising to do for years and implemented a garbage collector for jhc. It is still fairly rough, but is very promising. In truth, I was worried it might kill jhc's performance advantage, but quite the opposite, it actually improves the performance of several benchmarks, and doesn't cut too deep into jhc's speed advantage in others.
In particular, it seems to help ones where jhc did particularly worse than ghc, I had always assumed those cases were due to some pathological case in an inner loop that ghc was able to catch but jhc wasn't, but it turns out the presence of the GC played some role in their speed. I am not sure whether it is the short circuiting redirects or memory locality that is helping.
In any case, JGC seems to be a couple times faster than the boehm collector so all in all, it is a good option to have. Right now, using jgc means you have to link against the judy library, this restriction may or may not be lifted in the future. libJudy is an amazingly useful and versatile library, keeping the GC information stored independently of the heap allows me to garbage collect without trouncing all over the memory space and I think this is key to getting acceptable performance from the GC.
I am actually quite pleased with the results, the implementation is a very naive mark-and-don't-quite-sweep collector and achieves good performance, in particular, it isn't even generational. So there is still a fair amount of room for speed improvement.
The GC is still experimental, it still doesn't support some features like IORefs and the method for collecting gc roots is fairly brute force and sloppy, but the essential work is done.
John
-- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/ _______________________________________________ jhc mailing list jhc@haskell.org http://www.haskell.org/mailman/listinfo/jhc
On Fri, Apr 09, 2010 at 11:09:14AM -0300, Vinicius Callegari wrote:
I'm a little outdated regarding the current status of jhc. As John said he'd wired in a garbage collector, does it mean that jhc doesn't use region inference anymore?
It has had a basic form of region inference for a while that was able to allocate some structures on the stack. However, a hybrid approach seems to be the best. The GC can perform optimiaztions such as short circuiting indirections that can't be done with pure region inference, and there never was a good way to infer the lifetime of mutable objects like IORefs. So, it is likely both will co-exist in jhc. This is fairly straightforward as I just need to maintain the invarient that objects allocated in regions can only point to objects in other regions or constants. That way the GC can stop tracing as soon as it hits a region. This is fairly straightforward to ensure statically, since for the most part haskell data structures arn't mutable.
I've set up a party today so I can impress the girls with that... (just kidding :-)
Hey. That's why we write compilers. To get the ladies. Also, why no invite? :) John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
participants (3)
-
John Meacham -
Taral -
Vinicius Callegari