Default options for -threaded

Eric Seidel eric at seidel.io
Sat Oct 8 17:13:02 UTC 2016


I would prefer keeping -N1 as a default, especially now that the number
of capabilities can be set at runtime. Programs can then use the more
common -j flag to enable parallelism.

Regarding -qa, I was experimenting with it over the summer and found its
behavior a bit surprising. It did prevent threads from being moved
between capabilities, but it also forced all of the threads (created
with forkIO) to be *spawned* on the same capability, which was
unexpected. So -N -qa was, in my experience, equivalent to -N1!

On Sat, Oct 8, 2016, at 09:55, Ben Gamari wrote:
> lonetiger at gmail.com writes:
> 
> > Hi All,
> >
> > A user on https://ghc.haskell.org/trac/ghc/ticket/11054 has asked why 
> > -N -qa isn’t the default for -threaded.
> >
> I'm not sure that scheduling on all of the cores on the user's machine by
> default is a good idea, especially given that our users have 
> learned to expect the existing default. Enabling affinity by default
> seems reasonable if we have evidence that it helps the majority of
> applications, but we would first need to introduce an additional
> flag to disable it.
> 
> In general I think -N1 is a reasonable default as it acknowledges the
> fact that deploying parallelism is not something that can be done
> blindly in many (most?) applications. To make effective use of
> parallelism the user needs to understand their hardware, their
> application, and its interaction with the runtime system and configure
> the RTS appropriately.
> 
> Of course, this is just my two-cents.
> 
> Cheers,
> 
> - Ben
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-signature)


More information about the ghc-devs mailing list