[Haskell-cafe] RE: Haskell Performance

[Simon Peyton-Jones]

Dear Dave

| My question to you is, if you were asked to make a recommendation on
| which programming language to use for a program which would run on a
| multiple core processor, but also required adequate memory and running
| time performance, would you lean towards or away from Haskell?  What
| other factors would you consider?  In other words, was I correct in my
| initial opinion that Haskell was more concerned about code expression
| rather than performance?

Thanks for your email.  I'm ccing the Haskell Cafe, which is full of people with practical experience (many more than I) of using Haskell for real applications.

I don't think it's possible to give a categorical yes/no answer to your question.  Yes, Haskell is designed primarily for high-level expressiveness rather than performance.  This is good for programmers, but it cuts both ways for implementation.  On the one hand, the programmer is taking less control, and the implementation may not be as clever as a programmer could be (the quicksort example you cite is a good example).  On the other hand, the high-level-ness gives the opportunity for the implementation to do stuff that the programmer could not feasibly do by hand; the vectorisation transformation in nested data parallelism is a good example (http://research.microsoft.com/~simonpj/papers/ndp/index.htm).

Long term, my bet is that the second trend will win.  If you want to write parallel programs, it makes sense to start with a language that is by-default parallel, rather than by-default sequential.  But that does not mean that you get parallel performance without tears.  Far from it: parallelism is a complex, multi-faceted beast (concurrency, communication, locality, granularity...).  So the short-term answer might be different to the long term one.

That said, GHC comes out very competitively in the (flawed, but available) language shootout
http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all.  So performance is not at all bad.

Simon


| -----Original Message-----
| From: Dave Roberts [mailto:dave.a.roberts at gmail.com]
| Sent: 15 December 2008 14:42
| To: Simon Peyton-Jones
| Subject: Haskell Performance
|
| Dear Mr. Peyton Jones,
|
| I recently watched a video of you giving a talk about type driven
| testing in Haskell.
|
| http://video.google.com/videoplay?docid=-
| 4991530385753299192&ei=PWFGSaazDJPuqAL779n1DA&q=simon+peyton+jones+testing&emb=1
|
| I found it to be a very informative and entertaining presentation
| about Haskell.  About halfway through the video you examine the
| performance of the n-shell problem in Haskell versus C++.  You say the
| functional solution to the problem is 100x faster than the C++
| implementation.  You continue to examine reasons why, citing that set
| operations in a purely functional language can make assumptions that
| side-effect laden languages cannot.  For example creating a union of
| two sets does not need to allocate a new set in memory because it can
| reuse large portions of the original sets.  You continue to show that
| purely functional languages lend themselves to parallelism better than
| imperative languages because state is not being changed by default.
|
| Taking this into consideration, the Haskell website has a section
| titled, When C is better.
|
| http://www.haskell.org/haskellwiki/Introduction#When_C_is_better
|
| (I suspect you have already read this if not wrote it yourself)  This
| section looks at the quick sort example presented in the wiki and
| claims that if written in an imperative language, the quick sort can
| have time and memory requirement advantages over the Haskell version.
| I read the haskellwiki long before viewing the video and at the time I
| branded Haskell as a language which stresses expression over
| performance.
|
| My question to you is, if you were asked to make a recommendation on
| which programming language to use for a program which would run on a
| multiple core processor, but also required adequate memory and running
| time performance, would you lean towards or away from Haskell?  What
| other factors would you consider?  In other words, was I correct in my
| initial opinion that Haskell was more concerned about code expression
| rather than performance?  What you suggest in the video seems to be to
| the contrary.
|
|