Simon Peyton Jones: Data Parallel Haskell

nuACM · 27K views · 2010 · 1:19:57

Open on YouTube

Functional programmingCompilers, interpreters & program analysisComputer architecture & CPUstalkdated

Why Hacker News recommends it

Recommended as a fascinating look at easy parallelism abstractions, though other commenters note the approach never beat sequential C by much.

What it is

Simon Peyton Jones explains nested data parallelism and Data Parallel Haskell, an approach to exploiting multicore and distributed hardware while keeping a simple single-control-flow programming model.

Recommended by 5 HN commenters across 5 different months, 2010 to 2017.

What Hacker News said

Recommends drhodes · 2010-06 · on “SeaMicro drops an atom bomb on the server industry”

While this isn't undeniable proof, it's interesting none the less, Simon Peyton Jones: Data Parallel Haskell. [this video] He talks about how this scheme can parallelize non-trivial data structures, and how tedious book keeping can be avoided. I haven't used it yet in a project, so I can't speak of its efficacy - but worth a watch, imho.

Recommends Peaker · 2011-04 · on “Joel Spolsky: Can your programming language do this?”

Here's the main Haskell hero, Simon Peyton Jones giving a talk about data parallel Haskell, which I think is a promising language abstraction to do hard things with parallelism relatively easily: [this video] As for techniques that can be used now: Haskell's `par` and `pseq` combinators allow adding parallelization to "hard" code after-the-fact pretty easily.

Recommends reitzensteinm · 2014-04 · on “Speed memory access by arranging data to take advantage of CPU caching”

This is both a straw man (OP asked for limited help, not omnipotence), and predicting the future by drawing a line from the past. Functional compilers that outperform hand tuned C++ on many core machines may be possible, but very hard. Just because everyone has previously underestimated the difficulty does not mean it's an idea worthy of derision. I think it's much more likely that it's perpetually ten years away, until one day it's not (like the current, possibly temporary end to Moore's Law). Watching Simon Peyton Jones' talk on data parallel Haskell, I'd not make a bet against high performance Haskell's eventual success, especially as core counts continue to climb, and NUMA gets more NU.

Recommends sgrove · 2014-09 · on “Rhine – A Lisp on LLVM”

I believe Haskell compilers are pretty amenable to stuff like this - watching "Data Parallel Haskell", it was interesting to see how they actually map out contiguous memory, etc. [this video] Sadly, it doesn't seem to be as tightly integrated as what you'd see in SBCL from a developers PoV, but I'm certainly intrigued by their ability to achieve some very specific implementation while separating it from the expression of the algorithms.

Recommends anaphor · 2014-11 · on “Guy Steele on Functional Code for Parallel Execution (2009) [video]”

Well nested data parallelism generally applies to hierarchical structures like trees, whereas flat data parallelism applies to things like arrays and whatnot. You might want to watch this (similar in some ways) talk by SPJ on Data Parallel Haskell [this video]

Cites thirsteh · 2012-09 · on “White Paper: Haskell vs. F# vs. Scala [pdf]”

tl;dr: "we remark that all 3 languages provide easy-to-use, high-level and efficient support for parallelism. Haskell has an edge in its rich libraries and aggressive optimisation. Through laziness, top-level parallelism can be specified in a more modular way, minimising the need to modify components and avoiding any notion of explicit threads. Thus, Haskell is the language of choice for minimally intrusive parallelism. F# and Scala provide several mechanisms for parallelisation, some as high level as Haskell’s, some lower level with more potential for performance tuning. Thus, these languages provide a more direct route to controlling low level aspects and can use object-oriented and impure l

Cites mpweiher · 2014-06 · on “Teenage Haskell”

Your make some good points, but I don't quite buy them. Turbo Pascal for example was written by a single guy, Anders Hejlsberg, in about 2 years for several platforms in assembly language, and included an integrated (though primitive) text editor/IDE. Smalltalk was taken from ST-72 to ST-80 in 8 years, with small teams that also had to invent/implement complete VMs, operating systems, bitmap graphics engines, GUI framework(s) and sophisticated IDEs. You write that it would be nice to have an FP IDE so it could give you better feedback (or were you talking about an existing FP IDE). These guys built the live IDE (even better than types for direct feedback) in a fraction of the time. Does OPAL

Critical mpweiher · 2014-09 · on “Programming without objects”

LOL! My 1st year university course was 1989. When were you born? Interestingly, that is exactly what I see in the current generation of FP hypsters. Grandiose claims based on very limited experience. Aka: know so little, assume so much. But don't worry, it happens to the best. My favorite is still the Simon Peyton-Jones talk on Data Parallel Haskell, where he can't help himself, but just has to make the snide comment "this is only possible in a language like Haskell". Hand raised in the auditorium: The HPC community has been doing this for years. In FORTRAN. But carry on... (And of course, the results are dismal: 6 cores required to match sequential C! Considering that this sort of concurren