Subscribe to
Posts
Comments

Beautiful Parallelism: Harnessing Multicores with Haskell

November 12th, 2008 by Don Stewart

Don will be giving a talk SC’08 in Austin, Texas next week, as part of the Bridging Multicore’s Programmability Gap workshop, talking about programming mainstream multicore systems with Haskell, now. Here’s the abstract,
Haskell is a general purpose, purely functional programming language. If you want to program a parallel machine, a purely functional language such as Haskell is a good choice: purity ensures the language is by-default safe for parallel execution, (whilst traditional imperative languages are by-default unsafe). This foundation has enabled Haskell to become something of a melting pot for high level approaches to concurrent and parallel programming, all available with an industrial strength compiler and language toolchain, available now for mainstream multicore programming. In this talk I will introduce the features Haskell provides for writing high level parallel and concurrent programs. In particular we’ll focus on lightweight semi-explicit parallelism using annotations to express parallelism opportunities. We’ll then describe mechanisms for explicitly parallel programs focusing on software transactional memory (STM) for shared memory communication. Finally, we’ll look at how Haskell’s nested data parallelism allows programmers to use rich data types in data parallel programs which are automatically transformed into flat data parallel versions for efficient execution on multi-core processors.
See Simon Peyton-Jones and Satnam Singh’s recent tutorial for more background on multicore Haskell, on which this talk is based. See you in Texas!

2 Responses to “Beautiful Parallelism: Harnessing Multicores with Haskell”

  1. on 13 Nov 2008 at 06:29 America/New_York1 Stefan Chis

    Hi,

    I have some questions. Why does the Haskell community prefer STM? Why are people split about how to best approach multicore concurrency?
    STM camp: Haskell, Clojure
    Actor model camp: Erlang, Scala, Termite (Gambit Scheme)
    I would like to see an extensive argumentation of the choice, something like, “we chose X (STM) as opposed to Y (actor model), because …”.

    If Haskell is to play an important role, then how comes it has no JVM implementation? I don’t know much about .NET, but I haven’t heard of any implementation for .NET either.

    I don’t want to sound negative, but I think these are important issues that stand in the way of a more broad adoption of Haskell.

    Looking forward to reading your book.

    Best regards,
    Stefan

  2. on 13 Nov 2008 at 13:53 America/New_York2 Don Stewart

    Thanks Stefan.

    I don’t think the Haskell community necessarily /prefers/ STM .. there are also libraries for (new forms of) actors,

    http://hackage.haskell.org/cgi-bin/hackage-scripts/package/actor

    The Haskell community, as usual, is exploring all options for shared-memory multicore programming.

    There’s a .NET bridge too, by the way,

    http://www.haskell.org/haskellwiki/Salsa

    Thanks for you interest!

Leave a Reply