documentation in GHC.Conc, Control.Parallel.Strategies; querying number of CPUs

[Donald Bruce Stewart]

frederik:
> Hello,
> 
> I am interested in implementing some multi-threaded algorithms in
> Haskell.
> 
> 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:
> 
> pseq
> par

These guys are documented in the parallel Haskell stuff (and should be
in the haddocks!!)

   http://www.haskell.org/ghc/dist/current/docs/users_guide/lang-parallel.html 

> forkOnIO
> childHandler
> ensureIOManagerIsRunning

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.

-- Don