Haskell performance

[Seth Kurtzberg]

> | > I am currently evaluating different languages for implementing an
> | > application which will have to manipulate large graphs representing
> | > the structure of programs and their evolution.
> |
> | > Speed is in fact a crucial criterium for the language choice.
>
> A wise man once warned about the danger of premature optimisation.  I
> often spend ages labouring over efficiency aspects of my code (GHC, for
> example) that turn out to be nowhere near the critical path.  Language
> choice is another example.
>
> My biased impression is that raw speed is seldom the determining factor in
> language choice.  Language shootouts are fun and motivating, and give
> results that have the respectability that numbers confer.  Other things
> being equal, one would always choose the fastest vehicle; but other things
> are *never* equal!   On the contrary, other factors are much more
> important than speed: how quick it is to get code written, how much
> debugging is required once it is written, what libraries are available,
> what the programming environment is like, how easy it is to modify the
> program without giving rise to unforeseen bugs, etc etc.
>
> Sometimes performance is indeed central, but seldom.   Usually the program
> is either 10x faster than necessary or 10x slower than necessary.  In
> neither case does a 2x factor in language make much difference; in the
> former case you're happy either way, in the latter you need to fix your
> algorithm either way.
>
> For GHC in particular, there are many places where performance is less
> good than it could be, simply due to lack of time from Simon and me to
> tune the compiler.  For example, there's been some correspondence recently
> about array-processing loops that's still on my to-do list.  We're always
> looking for people to help improve GHC's performance, where the problem is
> simply lack of effort.  Speak up, guys!

I would certainly be willing to assist in this area.

>
> That said, there are undoubtedly reasons why a high level language is
> fundamentally never going to be as fast as a low level one.  (GHC beats C
> on nfib, but that's about all.)  But I bet that this difference is only
> crucial in a small minority of applications.
>
> Simon
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>
> !DSPAM:40597a4996431794457586!
>
>
>