| > 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! 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 [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
