seth at cql.com
Thu Mar 18 12:48:12 EST 2004
> | > 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.
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
More information about the Glasgow-haskell-users