High-Performance Haskell Johan Tibell email@example.com 2010-10-01
Welcome! A few things about this tutorial: Stop me and ask questionsearly and often I assume no prior Haskell exposure
Sequential performance is still important Parallelism is not a magic bullet: The speedup of a program using multiple processors is limited by the time needed for the sequential fraction of the program. (Amdahls law) We want to make ecient use of every core.
Caveats The usual caveats about performance optimizations: Improvements to the compiler might make some optimizations redundant. Write benchmarks to detect these cases. Some optimizations are compiler (i.e. GHC) specic That being said, many of these optimizations have remained valid over a number of GHC releases.
Software prerequisites The Haskell Platform: Download installer for Windows, OS X, or Linux here: http://hackage.haskell.org/platform The Criterion benchmarking library: cabal install -f-Chart criterion
Outline Introduction to Haskell Lazy evaluation Reasoning about space usage Benchmarking Making sense of compiler output Proling
Haskell in 10 minutes Our rst Haskell program sums a list of integers: sum : : [ I n t ] > I n t sum [ ] = 0 sum ( x : x s ) = x + sum x s main : : IO ( ) main = p r i n t (sum [ 1 . . 1 0 0 0 0 ] )
Type signatures Denition A type signature describes the type of a Haskell expression: sum : : [ I n t ] > I n t Int is an integer. [a] is a list of as So [ Int ] is a list of integers > denotes a function. So sum is a function from a list of integers to an integer.
Dening a function Functions are dened as a series of equations, using pattern matching: sum [ ] = 0 sum ( x : x s ) = x + sum x s The list is dened recursively as either an empty list, written as  , or an element x, followed by a list xs.  is pronounced nil and : is pronounced cons.
Function application Function application is indicated by juxtaposition: main = p r i n t (sum [ 1 . . 1 0 0 0 0 ] ) [1..10000] creates a list of 10,000 integers from 1 to 10,000. We apply the sum function to the list and then apply the result to the print function. We say that we apply rather then call a function: Haskell is a lazy language The result may not be computed immediately
Compiling and running our program Save the program in a le called Sum.hs and then compile it using ghc: $ ghc -O --make Sum.hs [1 of 1] Compiling Main ( Sum.hs, Sum.o ) Linking Sum ... Now lets run the program $ ./Sum 50005000
Dening our own data types Data types have one or more constructors, each with zero or more arguments (or elds). data Shape = C i r c l e Double | R e c t a n g l e Double Double And a function over our data type, again dened using pattern matching: a r e a : : Shape > Double area ( C i r c l e r ) = r r 3.14 area ( Rectangle w h) = w h Constructing a value uses the same syntax as pattern matching: area ( Rectangle 3.0 5.0)
Back to our sum function Our sum has a problem. If we increase the size of the input main = p r i n t (sum [ 1 . . 1 0 0 0 0 0 0 0 ] ) and run the program again $ ghc -O --make Sum.hs [1 of 1] Compiling Main ( Sum.hs, Sum.o ) Linking Sum ... $ ./Sum Stack space overflow: current size 8388608 bytes. Use +RTS -Ksize -RTS to increase it.
Tail recursion Our function creates a stack frame for each recursive call, eventually reaching the predened stack limit. Must do so as we still need to apply + to the result of the call. Make sure that the recursive application is the last thing in the function sum : : [ I n t ] > I n t sum x s = sum 0 x s where sum a c c [ ] = acc sum a c c ( x : x s ) = sum ( a c c + x ) x s
Polymorphic functions Many functions follow the same pattern. For example, product : : [ I n t ] > I n t product x s = product 1 x s where product a c c [ ] = acc product a c c ( x : x s ) = product ( a c c x ) x s is just like sum except we replace 0 with 1 and + with *. We can generalize sum and product to f o l d l : : ( a > b > a ) > a > [ b ] > a foldl f z  = z f o l d l f z ( x : xs ) = f o l d l f ( f z x ) xs sum = f o l d l (+) 0 product = f o l d l ( ) 1
Summing some numbers... Using our new denition of sum, lets sum all number from 1 to 1000000: $ ghc -O --make Sum.hs [1 of 1] Compiling Main ( Sum.hs, Sum.o ) Linking Sum ... $ ./Sum Stack space overflow: current size 8388608 bytes. Use +RTS -Ksize -RTS to increase it. What went wrong this time?
Laziness Haskell is a lazy language Functions and data constructors dont evaluate their arguments until they need them cond : : Bool > a > a > a cond True t e = t cond F a l s e t e = e Same with local denitions abs : : I n t > I n t abs x | x > 0 = x | otherwise = neg x where n e g x = negate x
Why laziness is important Laziness supports modular programming Programmer-written functions instead of built-in language constructs ( | | ) : : Bool > Bool > Bool True | | = True False | | x = x
Laziness and modularity Laziness lets us separate producers and consumers and still get ecient execution: Generate all solutions (a huge tree structure) Find the solution(s) you want nextMove : : Board > Move nextMove b = s e l e c t M o v e a l l M o v e s where allMoves = allMovesFrom b The solutions are generated as they are consumed.
Back to our missbehaving function How does evaluation of this expression proceed? sum [ 1 , 2 , 3 ] Like this: sum [1,2,3] ==> foldl (+) 0 [1,2,3] ==> foldl (+) (0+1) [2,3] ==> foldl (+) ((0+1)+2)  ==> foldl (+) (((0+1)+2)+3)  ==> ((0+1)+2)+3 ==> (1+2)+3 ==> 3+3 ==> 6
Thunks A thunk represents an unevaluated expression. GHC needs to store all the unevaluated + expressions on the heap, until their value is needed. Storing and evaluating thunks is costly, and unnecessary if the expression was going to be evaluated anyway. foldl allocates n thunks, one for each addition, causing a stack overow when GHC tries to evaluate the chain of thunks.
Controlling evaluation order The seq function allows to control evaluation order. seq : : a > b > b Informally, when evaluated, the expression seq a b evaluates a and then returns b.
Weak head normal form Evaluation stops as soon as a data constructor (or lambda) is reached: ghci> seq (1 div 0) 2 *** Exception: divide by zero ghci> seq ((1 div 0), 3) 2 2 We say that seq evaluates to weak head normal form (WHNF).
Weak head normal form Forcing the evaluation of an expression using seq only makes sense if the result of that expression is used later: l e t x = 1 + 2 i n seq x ( f x ) The expression p r i n t ( seq ( 1 + 2 ) 3 ) doesnt make sense as the result of 1+2 is never used.
Exercise Rewrite the expression (1 + 2 , a ) so that the component of the pair is evaluated before the pair is created.
Solution Rewrite the expression as l e t x = 1 + 2 i n seq x ( x , a )
A strict left fold We want to evaluate the expression f z x before evaluating the recursive call: f o l d l : : ( a > b > a ) > a > [ b ] > a foldl f z [ ] = z foldl f z ( x : xs ) = l e t z = f z x i n seq z ( f o l d l f z x s )