Oh, this is surprising, I must admit I haven't tried forkIO, but with
forkOS is doesn't move the threads across capabilities.
Do you know if this is by design or a bug?
On Sat, Oct 8, 2016 at 6:13 PM, Eric Seidel
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@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@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs Email had 1 attachment: + signature.asc 1k (application/pgp-signature)
ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs