[Haskell-cafe] Re: A suggestion for the next high profile Haskell project

[Simon Peyton-Jones]

| > Is that an intrinsic feature of the language, or could compilers'
| > optimisation plausibly get clever enough to do well without lots of
| seq
| > and explicit unboxings and suchlike?
|
| I believe that compilers can get a lot cleverer - my hope is that one
| day the natural Haskell definition will outperform a C definition.
|
| Of course, lazy evaluation makes that hard work, but I think it can be
| done eventually.

My view is that Haskell's performance is very seldom the limiting factor
  - often it is simply fast enough
  - when it isn't, optimising the algorithm often suffices
        (and that sort of refactoring can be much easier in a
        functional language)
  - when it doesn't, using lower-level stuff on small chunks
        of code often suffices
  - when none of these are enough, even C is sometimes not fast enough

Of course there is a window in which C is fast enough and Haskell isn't.  But I think that the window is fairly narrow.

Much more significant are libraries, GUIs, database connections, integration with other languages etc.  It's great to see so much work on these aspects happening in the Haskell community.

All of that said, I agree with Neil that there is plenty of room for further improvement of performance. For example, in our data-parallel Haskell project, we're hoping for highly-competitive performance by doing aggressive fusion that just would not be possible in an imperative setting.  (There's a status report on my home page.)  Whole-program optimisation is another fertile area (e.g. jhc, mlton).

Simon