> | > 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 > [EMAIL PROTECTED] > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > > !DSPAM:40597a4996431794457586! > > > _______________________________________________ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
