I seem to recall reading in a GHC status report that there was some work going on with parallel garbage-collection. Looking at 6.8.1, it seems pretty clear that it didn't make it. Is there any update about where things are on that front? It isn't an immediately pressing need a Bluespec, but we do get asked every once in a while about parallelizing the Bluespec compiler. One of the technical reasons we're holding off on that front is that it wouldn't win as much as people expect (because garbage collection is usually a decent fraction of a typical run), so we'd be interested if the state-of-play in that area changed. Thanks, - Ravi
Ravi Nanavati wrote:
It isn't an immediately pressing need a Bluespec, but we do get asked every once in a while about parallelizing the Bluespec compiler.
Roshan James was working on parallel GC at MSR Cambridge last year. Unfortunately, it's not an internship-sized project.
One of the technical reasons we're holding off on that front is that it wouldn't win as much as people expect (because garbage collection is usually a decent fraction of a typical run), so we'd be interested if the state-of-play in that area changed.
I think that the need for it will become more pressing among GHC's
developers as the NPH work matures, as the current GC reduces
performance even on two CPUs. The need to publish good numbers is
always a helpful motivator :-)
Bryan O'Sullivan wrote:
Ravi Nanavati wrote:
It isn't an immediately pressing need a Bluespec, but we do get asked every once in a while about parallelizing the Bluespec compiler.
Roshan James was working on parallel GC at MSR Cambridge last year. Unfortunately, it's not an internship-sized project.
One of the technical reasons we're holding off on that front is that it wouldn't win as much as people expect (because garbage collection is usually a decent fraction of a typical run), so we'd be interested if the state-of-play in that area changed.
I think that the need for it will become more pressing among GHC's developers as the NPH work matures, as the current GC reduces performance even on two CPUs. The need to publish good numbers is always a helpful motivator :-)
I tried it again recently, and for some reason I have yet to fathom, my parallel GC doesn't actually run any faster than single-threaded GC. That is, it divides the work equally between the processors, all processors are kept busy, but the total elapsed time is the same or greater than running the GC single-threaded. It seems unlikely that I've reached the limit of the memory bandwidth, but that's what it looks like. Rest assured that this is a high priority for us too. I have PAPI running on my laptop, and I'll keep investigating, hopefully the problem will reveal itself at some point. Cheers, Simon
Hello, Is real-time, parallel garbage collection at all feasible? My thinking is, real-time garbage collection requires the garbage collector to be able to work on the problem in small, predictable, pieces. That seems like something which would also be useful for scaling up GC to multiple cores? I am curious, because I have a project in mind that would benefit greatly from real-time, parallel garbage collection :) j.
Hi
I am curious, because I have a project in mind that would benefit greatly from real-time, parallel garbage collection :)
Is Haskell real-time? Doesn't lazy evaluation rather destroy lots of the real-time properties that you might like in a language. If you want a real-time functional language you might want to look at Hume. Thanks Neil
Using concurrency in GC usually implies one of - Parallel GC. Stop the mutator(s) and use multiple processors to do GC; when they are done, start the mutators. This isn't real-time, because there's an unbounded pause for GC. This is what Simon and Roshan's parallel collector does. - Interleaved GC. The mutator(s) alternate between GC and ordinary mutation. We once had a version of GHC that did this on a uni-processor, thanks to Andy Cheadle. See the paper "Non-stop Haskell". - Concurrent GC. Use multiple processors to do GC while running the mutator(s) at the same time. This can be near-real-time. You want concurrent GC I think. But it's a tough one: a) it's jolly complicated to get right b) it requires very fine-grain locking so that the mutators and collectors don't trip over each other. (b) is painful because it makes all programs run slower, whether or not they need the real-time behaviour. Yes, you could compile two ways, but that make it even harder to keep the system working! We don't (I think) have any current plans to implement concurrent GC on a multi-processor, but it'd be a great (hard) project. Andy's work on Non-Stop Haskell might be a good starting point. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users-bounces@haskell.org] On Behalf Of | Jeremy Shaw | Sent: 15 November 2007 18:20 | To: glasgow-haskell-users@haskell.org | Subject: Re: State of parallel GC? | | Hello, | | Is real-time, parallel garbage collection at all feasible? | | My thinking is, real-time garbage collection requires the garbage | collector to be able to work on the problem in small, predictable, | pieces. That seems like something which would also be useful for | scaling up GC to multiple cores? | | I am curious, because I have a project in mind that would benefit | greatly from real-time, parallel garbage collection :) | | j. | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
participants (6)
-
Bryan O'Sullivan -
Jeremy Shaw -
Neil Mitchell -
Ravi Nanavati -
Simon Marlow -
Simon Peyton-Jones