[Haskell-cafe] Parallel Haskell Digest 1

Eric Y. Kow eric at well-typed.com
Thu Mar 31 16:21:34 CEST 2011

Parallel Haskell Digest
Edition 1

Hello Haskellers!

If you're in the mood for a HWN chaser, I'd like to introduce the first
Parallel Haskell Digest, a newsletter aiming to show off all the work
that's going on using parallelism and concurrency in the Haskell

The digest is a bit of an experiment.  For the community in general, I
hope to help you catch up with a monthly recap of news, interesting blog
posts and discussions about parallelism in Haskell.  For people (like
me) who are new to parallelism and concurrency in Haskell, or maybe just
have a passing interest, I hope to give you little nibbles, with regular
features like the Word of Month, Featured Code and Parallel Puzzlers.

Finally, as a bit of disclosure, I'm writing this digest as part of my
work to promote the Parallel GHC Project.  So don't be surprised if I
give it a little special emphasis :-)

Word of the Month
This very first edition of the PH digest is brought to you by the word
/spark/.  You may have heard of sparks and threads in the same sentence.
What's the difference?

A Haskell thread is a thread of execution for IO code. Multiple Haskell
threads can execute IO code concurrently and they can communicate using
shared mutable variables and channels.

Sparks are specific to parallel Haskell. Abstractly, a spark is a pure
computation which may be evaluated in parallel. Sparks are introduced
with the par combinator; the expression (x `par` y) "sparks off" x,
telling the runtime that it may evaluate the value of x in parallel to
other work. Whether or not a spark is evaluated in parallel with other
computations, or other Haskell IO threads, depends on what your hardware
supports and on how your program is written. Sparks are put in a work
queue and when a CPU core is idle, it can execute a spark by taking one
from the work queue and evaluating it.

On a multi-core machine, both threads and sparks can be used to achieve
parallelism. Threads give you concurrent, non-deterministic parallelism,
while sparks give you pure deterministic parallelism.

Haskell threads are ideal for applications like network servers where
you need to do lots of I/O and using concurrency fits the nature of the
problem. Sparks are ideal for speeding up pure calculations where adding
non-deterministic concurrency would just make things more complicated.

Parallel GHC project news
The Parallel GHC Project is an MSR-funded project to push the real-world
use of parallel Haskell.  Part of this project involves effort by
Well-Typed to provide tools for use by the general community:

Work shall soon begin working on making the "Modified Additive Lagged
Fibonacci" and perhaps other random number generators from the SPRNG
library available in Haskell. Current plans are to implement the
algorithms directly in Haskell, and to expose them as instances of
System.Random.RandomGen. These generators are attractive for use in
Monte Carlo simulations because they are splittable and have good
statistical quality, while providing high performance.

Work is underway on extending the GHC EventLog and associated tools
(ghc-events, ThreadScope). The aim is to support profiling of
multi-process or distributed Haskell systems such as client/server or
MPI programs. This involves incorporate some changes made in related
projects (Eden, EdenTV). This work may have some benefits even for
profiling single-process programs. It should also allow comparative
profiling where multiple runs of the same program (e.g. different inputs
or slightly different code) are viewed on the same timeline.

For more information on the Parallel GHC project, see

Featured Code
The feature code for this month is hulk, an IRC server in 1250 lines of
code.  Hulk was coded up by Chris Done in one evening, and it was used
the next morning.  (Chris has done a bit of cleaning up since).

Here's what Chris had to say about his experience writing Hulk:

   Haskell's lightweight threads make it natural (and guilt-free!) to
   choose the design of one-thread-per-client. With a single MVar
   containing a pure value for the whole server-state, and the help of a
   monad stack of ReaderT(connection information), WriterT (replies) and
   StateT (user details), it was trivial to make the bulk of the code
   completely pure. LineBuffering on the (Handle-wrapped) sockets tripped
   me up; as opposed to NoBuffering, this did not behave as expected:
   *many* threads would block when only *one* should have. Overall, it
   was textbook Haskell; keep the main code pure, and only the truly
   impure in the outer shell.

It's up on hackage so you can install it with a quick

   cabal install hulk

You can also fork his code on GitHub


Got a cool use of Parallel Haskell or an interesting problem?
Nominate it for the PH digest featured code/parallel puzzler!

Blog Posts
1. Parallelism is not Concurrency - Bob Harper

2. Petri Net Concurrency - Edward Z. Yang

Parallel-Haskell and Haskell Cafe
1. How does the Yesod web framework deal with concurrency?

   Ertugrul Soeylemez is using concurrent Haskell to serve up
   two related sites and spawn off some background workers would
   pose any problems with Yesod and WAI.  No problem, according
   to Michael Snoyman


2. Concurrency best practices?

   Wren Ng Thorton is using STM to "run a lot of things in parallel
   without the headaches of locks." It works great, but then what if
   you want IO?  How would you enforce atomic IO operations, eg.
   printing log messages in two threads without getting garbage on
   screen?  Some suggestions were the twighlight-stm package, and using
   STM.TChan with potential performance penalty.


3. Possible bug in Control.Concurrent

   Krzysztof Skrzętnicki encountered an unexpected deadlock
   using Control.Concurrent.  Was it a normal consequence of repeatedly
   reading from channel with only a single element put into it, or a

   - http://www.haskell.org/pipermail/haskell-cafe/2011-February/089135.html
   - http://hackage.haskell.org/trac/ghc/ticket/4154

4. Faster timeout but is it correct?

   Bas van Dijk proposed increasingly faster potential replacements for
   System.Timeout, including some that use the new GHC event manager.
   After much scrutiny, it turns out that one version is not faster and
   the events based one had a bug.  Maybe next time!

   - http://www.haskell.org/pipermail/haskell-cafe/2011-February/089360.html
   - http://hackage.haskell.org/trac/ghc/ticket/4963

5. Unable to get parallelism using `par`.
   SMP parallelism gains inferior than expected.

   C K Kashyap followed /A tutorial on Parallel and Concurrent
   programming in Haskell/ but couldn't get a speed-up.  Others
   had better luck with different sets of inputs

   José Pedro Magalhães also tried using SMP parallelism without getting
   performance gains he was hoping for.  Simon Marlow suggested analysing
   with Threadscope, checking for too many/few sparks, and checking to
   see if a lot of time was being spent in GC.

   - http://www.haskell.org/pipermail/haskell-cafe/2011-February/089419.html
   - http://research.microsoft.com/en-us/um/people/.../parallel/AFP08-notes.pdf
   - http://www.haskell.org/pipermail/haskell-cafe/2011-February/089635.html

6. Auto elimination of MVars using a monad or monad transformer.

   Chris Dew asked if GHC eliminates MVars during compilation, or if there
   was a way to eliminate them automatically.  Ryan Ingram suggested
   looking into the Adaptive package and Functional Reactive Programming.


Stack Overflow
1. Parallelism on divide & conquer algorithm (7 Feb)

2. How to best synchronize game engine and network server in Haskell? (11 Feb)

3. Haskell concurrency and Handles (27 Feb)

4. Strict evaluation techniques for concurrent channels in Haskell (6 Mar)

Help and feedback
Got something for the digest? Send me an email at eric at well-typed.com.
I'm particularly interested in short parallelism/concurrency puzzles,
cool projects for featured code. Other comments and feedback (criticism
and corrections especially!) would be welcome too.

Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
For a faster response, try +44 (0)1273 64 2905 or
xmpp:kowey at jabber.fr (Jabber or Google Talk only)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20110331/52adc5e7/attachment.pgp>

More information about the Haskell-Cafe mailing list