Ah, I'm sorry, I believe I was thinking of -qm, which is supposed to prevent threads from being moved. I forgot these were separate options! And the latest version of the User's Guide includes a comment about -qm
> This option is probably only of use for concurrent programs that explicitly > schedule threads onto CPUs with Control.Concurrent.forkOn. which is exactly what I had to do. On Mon, Oct 10, 2016, at 03:34, Phyx wrote: > 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 <e...@seidel.io> wrote: > > > 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: > > > loneti...@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 > > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
