Skip to content
Hallway
0:00 / 0:00

#simonpeytonjones#haskell#parallelprogramming

The Future is Parallel, and the Future of Parallel is Declarative

Dimchansky

452 subscribers • 1 video on Hallway

YouTube
  • Recommended by 3 people: 3 in engineering communities.
  • Presented by Simon Peyton Jones

Advanced. Deep dive for people who know the field.

17K views14 years ago3 recommendations

Programming languagesSystems programmingFunctional programmingConcurrency and parallelismHaskell

Simon Peyton Jones surveys various approaches to parallel programming in functional languages, explaining why side effects must be tightly controlled.

The Future is Parallel, and the Future of Parallel is Declarative Simon Peyton Jones If you want to program a parallel computer, it obviously makes sense to start with a computational paradigm in which parallelism is the default (ie functional programming), rather than one in which computation is based on sequential flow of control (the imperative paradigm). And yet... functional programmers have been singing this tune since the 1980s, but do not yet rule the world. In this talk I'll say why I think parallelism is too complex a beast to be slain at one blow, and how we are going to be driven, willy-nilly, towards a world in which side effects are much more tightly controlled than now. I'll give a whirlwind tour of a whole range of ways of writing parallel program in a functional paradigm (implicit parallelism, transactional memory, data parallelism, DSLs for GPUs, distributed processes, etc, etc), illustrating with examples from the rapidly moving Haskell community, and identifying some of the challenges we need to tackle. yow.eventer.com/events/1004/talks/1055

Why it's here

3 people recommend this

What people say. Highly recommended by Haskellers as an excellent survey of parallel programming paradigms and why implicit parallelism is difficult.

u/Drezilin r/haskell • Recommends

On “General purpose libraries”

…h get used inside the other given libraries. edit: i learned it best when looking at examples of stuff (esp. RWST, attoparsec, yesod) and then read the "abstract nonsens" on typeclassopedia for a more general view. i "understood" lenses after https://skillsmatter.com/skillscasts/4251-lenses-compositional-data-access-and-manipulation monads after link to this video and stm after link to this video .. but thats just my opinion. YMMV.…
13View on Reddit

u/gilmiin r/haskell • Recommends

On “Quote from Guy Steele on Fortress”

Are you interested in parallel and concurrent programming in Haskell? Just watch this and read this :)
12View on Reddit

u/vem_in r/haskell • Recommends

On “What are some quintessential early Haskell papers I should read?”

Bananas, lenses, and barbed wire is one of my favorites. Not explicitly Haskell-related, but it's targeted at lazy functional languages so it implicitly is. Simon Peyton-Jones also has a nice talk here on parallelism and declarative languages. If you're interested in recursion schemes, this paper has a nice example of a zygomorphism.
5View on Reddit

u/gilmiin r/haskell • Recommends

On “Implicit parallelism”

There's a great talk by SPJ (here) that describe the design space of parallel programming which I really recommend watching.
4View on Reddit

u/gilmiin r/haskell • Recommends

On “Pureli - My haskell project”

Haskell has great solutions for parallel programming. This lecture by SPJ surveys some of them, the semi-implicit approach being the closest one. It also highlights a problem with Pureli's idea - the cost model matters and right now we can't just leave it up to the system to parallelize everything if we care about it. It's a good thing this is more of an experiment than a production system :)
3View on Reddit

u/gilmiin r/haskell • Recommends

On “Automatic Parallelisation at runtime”

This is a good presentation about parallelism by SPJ, he talks about implicit parallelism as well, saying it's difficult to determine the cost model. I recommend watching it!
2View on Reddit

u/gilmiin r/ProgrammingLanguages • Recommends

On “Any way around this ugly pattern in procedural languages?”

> Do Haskellers think that's revealing itself to be a somewhat anachronistic design given that computers are rapidly becoming multi-core to a significant degree? I don't understand this question. can you clarify? If you want to take a look at haskell's parallel story and also why it doesn't do implicit parallelism check this lecture.
1View on Reddit