Ryan Newton
I think this is a bit of an unfair accusation ("simple-minded"). Performance is only relevant to certain domains, sure. But program performance is an entire *industry*. And I'd argue it's of massive importance to the world at large. Intel has an army of "AE"s (application engineers) that go out to other companies to make applications perform better. There are plenty of compute bound industries -- i.e. movie companies are limited by what kind of frame they can render in ~24 hrs; sequencing centers are limited by certain very slow bioinformatics algorithms; you can look almost anywhere you like for examples.
I'm sorry for the rough words. I didn't mean to overgeneralize. Of course in certain domains a reasonable performance is desirable, but the first question you should ask is whether you want high level or low level performance. Haskell performs amazingly at the high level and suboptimal at the low level. My point is: If you need C-like performance at a certain spot there is really no excuse for writing the entire application in C. Haskell has a working, powerful enough FFI. Also idiomatic Haskell code nowadays performs close to C. If your code doesn't, chances are that it's not even idiomatic. Sorting a list is easy and beautiful in code. But it's far from idiomatic. Using ST with destructive update is also not idiomatic. One of my performance masterpieces is the "instinct" AI library (see Hackage). It uses only immutable vectors and performs very heavy Double calculations, yet performs better than the same code with mutable arrays did. With a few years of Haskell experience in my backpack I know how to utilize laziness to get amazing performance for code that most people would feel must be written with destructively updating loop. And the resulting code is just beautiful to read and watch at work, a great demonstration of the wonders the GHC developers have created.
As a community I think we have to face the fact that writing the hot inner loop of your application as idiomatic Haskell is not [yet] going to give you C/Fortran performance off the bat. Though in some cases there's not really anything stopping us but more backend/codegen work (I'm thinking of arithmetically intensive loops with scalars only). For example, the following Mandel kernel is in many ways the *same* as the C version:
https://github.com/simonmar/monad-par/blob/662fa05b2839c8a0a6473dc490ead8dd5...
We have the types; we've got strictness (for this loop); but the C version was 6X faster when I tested it.
Well, if it's "in many ways the same as C", then again it's probably not
idiomatic Haskell. I don't know what a Mandel kernel is, so I can't
really tell you how I would write the code without further study.
However, I'm doing a lot of number crunching and my code usually gets
really close to C, and especially for Integer-heavy calculations
actually outperforms C. I have done the comparison. Using GMP with all
the features it provides in the mpz_* family of functions is in fact
slower than the same in Haskell (GHC 7.4.1 on Intel i5 64 bits here),
and from my C times I have experience using GMP properly including smart
allocation, etc.
If you want high performance Haskell, writing C in Haskell is /not/ the
solution. It /will/ result in suboptimal code, likely considerably
slower than the same code in C.
Greets,
Ertugrul
--
Key-ID: E5DD8D11 "Ertugrul Soeylemez