ANNOUNCE: GHC 6.12.1 Release Candidate 1
marlowsd at gmail.com
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