This is an outstanding discussion. I am learning a lot from it.

I would find it useful to pull all this information together into a single document that discusses all the performance issues in one place and shares the real life experience is dealing with each issue. I see this as a best practice paper rather than a research document.

Does such a document exist? If not, I am willing try and start one.

Ryan writes:

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.


I have heard similar comments  from other experienced Haskell users about how get better performance from their code by understanding the details of applying laziness. I would like to try and capture this.

Are there blogs, wiki postings, and list postings that provide information about particular issues?

Gregg

On 5/10/2012 11:53 PM, Ertugrul Söylemez wrote: 
Ryan Newton <rrnewton@gmail.com> wrote:


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/662fa05b2839c8a0a6473dc490ead8dd519ddd1b/examples/src/mandel.hs#L24H

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




_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe