BayFP: Concurrent and Multicore Haskell
•Download as PPT, PDF•
6 likes•2,300 views
- The document discusses concurrent and parallel programming in Haskell, including the use of threads, MVars, and software transactional memory (STM). - STM provides atomic execution of blocks of code, allowing failed transactions to automatically retry without race conditions or data corruption. - Strategies can be used to evaluate expressions in parallel using different evaluation models like head normal form or weak head normal form. - While functional programs may seem to have inherent parallelism, in practice extracting parallelism can be difficult due to data dependencies and irregular patterns of computation.
Report
Share
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to BayFP: Concurrent and Multicore Haskell
Similar to BayFP: Concurrent and Multicore Haskell (20)
Recently uploaded
Recently uploaded (20)
BayFP: Concurrent and Multicore Haskell
- 1. Concurrent and Multicore Haskell
- 2. Concurrent Haskell For responsive programs that multitask Plain old threads, with a few twists Popular programming model
- 3. A simple example backgroundWrite path contents = done <- newEmptyMVar forkIO $ do writeFile path contents putMVar done () return done
- 4. Imperative code!? Threads, assignment, “return”... huh ? Haskell is a multi-paradigm language Pure by default Imperative when you need it
- 5. What’s an MVar? An atomic variable Either empty or full takeMVar blocks if empty putMVar blocks if full Nice building block for mutual exclusion
- 6. Coding with MVars Higher-order programming modifyMVar: atomic modification Safe critical sections Combine MVars into a list FIFO message channels
- 7. FIFO channels (Chan) Writer does not block Reader blocks if channel is empty Duplicate a channel Broadcast to multiple threads
- 8. Smokin’ performance From the “Computer Language Benchmark Game” Create 503 threads Circulate token in a ring Iterate 10 million times Language Seconds GHC 6.70 Erlang 7.49 Scala 53.35 C / NPTL 56.74 Ruby 1890.92
- 9. Runtime GHC threads are incredibly cheap Run millions at a time File and network APIs are blocking Simple mental model Async I/O underneath
- 10. Time for a change That didn’t rewire my brain at all! Where’s the crazy stuff?
- 12. Concurrent vs parallel Concurrency Do many unrelated things “at once” Goals are responsiveness and multitasking Parallelism Get a faster answer with multiple CPUs
- 13. Pure laziness Haskell is not just functional (aka pure ) It’s non-strict : work is deferred until needed Implemented via lazy evaluation Can laziness and parallelism mix?
- 14. Laziness is the default What if something must happen right now ? Use a special combinator seq – adds strictness Evaluates its 1st argument, returns its 2nd
- 15. A simple use of seq daxpy k xs ys = zipWith f xs ys where f x y = k * x + y daxpy’ k xs ys = zipWith f xs ys where f x y = let a = k * x + y in a `seq` a
- 16. par “Sparks” its first argument Sparked evaluation occurs in parallel Returns its second
- 17. Our favourite whipping boy pfib n | n <= 1 = 1 pfib n = a `par` (b `pseq` (a + b + 1)) where a = pfib (n-1) b = pfib (n-2)
- 18. Parallel strategies par might be cute, but it’s fiddly Manual annotations are a pain Time for a Haskell hacker’s favourite hobby: Abstraction!
- 19. Algorithm + evaluation What’s a strategy ? How to evaluate an expression Result is in a normal form
- 20. Head normal form “What is my value?” Completely evaluates an expression Similar to traditional languages
- 21. Weak head normal form “What is my constructor ?” data Maybe a = Nothing | Just a Does not give us a complete value Only what constructor it was built with
- 22. Combining strategies A strategy is a normal Haskell function Want to apply some strategy in parallel across an entire list? parList strat [] = () parList strat (x:xs) = strat x `par` parList strat xs
- 23. Strategies at work Map a function over a list in parallel Pluggable evaluation strategy per element using x strat = strat x `seq` x parMap strat f xs = map f xs `using` parList strat
- 24. True or false? Inherent parallelism will save us! Functional programs have oodles ! All we need to do is exploit it!
- 25. Limit studies Gives a maximum theoretical benefit Model a resource, predict effect of changing it Years of use in CPU & compiler design Early days for functional languages
- 26. So ... true or false? Is there lots of “free” parallelism? Very doubtful Why? A familiar plague Data dependencies Code not written to be parallel isn’t
- 27. Current research Feedback-directed implicit parallelism Automated par annotations Tuned via profiled execution Results to date are fair Up to 2x speedups in some cases
- 28. Parallelism is hard Embarrassingly parallel: not so bad Hadoop, image convolution Regular, but squirrelly: pretty tough Marching cube isosurface interpolation, FFT Irregular or nested: really nasty FEM crack propagation, coupled climate models
- 29. Current state of the art Most parallelism added by hand Manual coordination & data layout MPI is akin to assembly language Difficult to use, even harder to tune Irregular data is especially problematic
- 30. Nested data parallelism Parallel functions invoke other parallel code One SIMD “thread of control” Friendly programming model
- 31. NPH automation Compiler transforms code and data Irregular, nested data becomes flat, regular Complexity hidden from the programmer
- 32. Current status Work in progress Exciting work, lots of potential Attack both performance and usability Haskell’s purity is a critical factor
- 34. Concurrency is hard Race conditions Data corruption Deadlock
- 35. Transactional memory Fairly new as a practical programming tool Implemented for several languages Typically comes with weird quirks Haskell’s implementation is beautiful
- 36. Atomic execution Either an entire block succeeds, or it all fails Failed transactions retry automatically Type system forbids non-atomic actions No file or network access
- 37. How does retry occur? When to wake a thread and retry a transaction? No programmer input needed Runtime tracks variables read by a failed transaction, retries automatically
- 38. Composability All transactions are flat Calling transactional code from the current transaction is normal This simply extends the current transaction
- 39. Early abort The retry action manually aborts a transaction early It will still automatically retry Handy if we know the transaction must fail
- 40. Choosing an alternative The orElse action combines two transactions If the first succeeds, both succeed Otherwise, it tries the second If the second succeeds, both succeed If both fail, the first will be retried
- 41. STM and IPC TVar – simple shared variable TMVar – atomic variable (like an MVar) TChan – FIFO channel If the enclosing transaction retries... ...then so does any modification
- 42. A useful analogy Concurrency Mutexes, semaphores, condition variables Software transactional memory Memory management malloc, free, manual refcounting Garbage collection
- 43. Manual / auto tradeoffs Memory management Performance, footprint Safety against memory leaks, corruption Concurrency Fine tuning for high contention Safety against deadlocks, corruption
- 44. Brief recap Concurrency Fast, cheap threads Blocking I/O and STM are friendly to your brain Multicore parallelism Explicit control or a strategic approach NPH offers an exciting future