documentation in GHC.Conc, Control.Parallel.Strategies;
querying number of CPUs
Donald Bruce Stewart
dons at cse.unsw.edu.au
Sat Jul 14 20:02:13 EDT 2007
> I am interested in implementing some multi-threaded algorithms in
> I have run into some documentation dead-ends. The documentation in
> GHC.Conc is what I get when I search for "ghc pseq" on google, but it
> doesn't document pseq and some other functions:
These guys are documented in the parallel Haskell stuff (and should be
in the haddocks!!)
Not sure about these last ones.
> In particular, I wonder: How is pseq different from seq? Under what
> circumstances is it used? I have looked at the source code so I see
> that it is implemented in terms of 'seq' and 'lazy':
> > -- "pseq" is defined a bit weirdly (see below)
> > --
> > -- The reason for the strange "lazy" call is that
> > -- it fools the compiler into thinking that pseq and par are non-strict in
> > -- their second argument (even if it inlines pseq at the call site).
> > -- If it thinks pseq is strict in "y", then it often evaluates
> > -- "y" before "x", which is totally wrong.
> > pseq :: a -> b -> b
> > pseq x y = x `seq` lazy y
> - does this mean pseq should be used instead of 'seq' when I want the
> first argument to be evaluated first? And I am also curious about the
> others, although par seems to be documented in Control.Parallel.
> Also, the following functions in Control.Parallel.Strategies are not
> documented, at least in Haddock:
Yes, I don't understand either why Control.Parallel.Strategies isn't
documented. Please file a bug report!
> As an aside, if you've read this far then you may know the answer to a
> related question: is there a way to query how many processors the
> current machine has? I am implementing a parallel sort, and in cases
There's no builtin way, but there's an open trac ticket for this.
> such as sorting where one can decompose an algorithm into an
> arbitrarily large number of threads, I am wondering how to tell what
> the maximum useful number of threads is (usually this will be some
> increasing function of the number of CPUs) to avoid the overhead of
> spawning a thread when it is not needed. (I'm about to read
> "Lightweight concurrency primitives for GHC" by Li et al, if that's
> the right place to look)
I usually just ensure the 'n' value is available as a command line flag
to my program.
More information about the Libraries