ANNOUNCE: GHC 6.12.1 Release Candidate 1

Simon Marlow marlowsd at
Mon Oct 12 08:02:32 EDT 2009

On 12/10/2009 10:07, Bulat Ziganshin wrote:
> Hello Simon,
> Monday, October 12, 2009, 12:32:05 PM, you wrote:
>> Release notes here, for now:
> 1. it says
>> The following options are all described in Section 4.15.3, “RTS
>> options to control the garbage collector”.
>> * The flag +RTS -N now automatically determines how many threads to
>>    use, based on the number of CPUs in your machine.
> actually -N is decribed in "4.13.2. RTS options for SMP parallelism"
> also, i propose to enable +RTS -N by default. Haskell is very popular
> as multithreaded language, don't fool novices!

I don't think we're ready for that yet.  The current implementation 
assumes that it has access to the given number of cores, and performance 
degrades severely if it doesn't.  So for example, using -N2 on a 2-core 
machine may perform badly unless the machine is otherwise very quiet. 
I've been working on improving this, but it's quite difficult: using 
spinlocks and busy-waiting is a lot faster than using sleep/wakeup 
synchronisation when you really have all the cores, but when you lose a 
core things go haywire.  I've tried the usual "spin for a bit and then 
go to sleep" technique, but even that can adversely affect performance 
when you really do have all the cores, because sometimes we do have to 
spin for quite a long time.  The only proper solution is not to 
synchronise at all, which is what we're looking at now (CPU-independent GC).

You may notice this effect more with 6.12.1 because we turned on the 
parallel GC for generation 0 by default.  This improves performance for 
parallel programs a lot (see ICFP paper), but also means there are many 
more all-core synchronisation points, which in turn will really hurt if 
any of our threads is descheduled by the OS.

So right now, on a dual-core I'd recommend using -N2 -qg1 (don't use 
parallel GC in gen 0), or -N2 -H<large>.

>> "The -gn RTS option has been removed, except that -g1 is still
>> accepted for backwards compatibility. "
> why not ignore whole option for a 6.12.*?

Because people might be using -g1?


More information about the Glasgow-haskell-users mailing list