himself: > It would be enough to exhaustively analyse examples of the kind I gave: > single algorithm with fast non-Haskell implementation but very slow in > Haskell. The article describes laborious but unsuccessful attempt to > pinpoint what makes Haskell over 500 times slower than SML on a genetic > algorithm. 7 years have passed and nobody cares.
This is wrong. We do care, greatly. Efforts are underway right now to improve the output of the native code generator in GHC, great steps have been made in improving the GHC optimiser over the last year (Larry Wall mentioned that Pugs compiled under ghc 6.6 ran his perl6 programs 60x faster than under ghc 6.4.2). And numerous new libraries have appeared to allow for high performance Haskell without sacrificing clarity. Additionally, we have collected information on standard approaches to optimising Haskell code on the wiki under haskell.org/haskellwiki/Performance. Just yesterday a project was announced to provide cross-compiler low level benchmarks to help focus performance issues. The Haskell of 2007 is a very different beast from 2000: its significatnly eaier to reach OCaml, or even C-like performance, now than it was even a year ago. Just introducing a strict, packed string type makes a huge difference. Performance concerns are very hot right now in the Haskell community! And compared to ruby or python we're swimming along ;) > So, for those avoiding fundamental issues I would suggest stretching > imagination into successors of Wiki and consider something that starts as > automated online benchmarking. It could: > (1) initiate research that would answer the questions you asked me:-) > (2) introduce performance awareness through immediate feedback > (3) automatically collect test results > (4) feed databases with classified results and reusable code > (5) pinpoint bad solutions if combined with inductive database > (6) evolve into a mighty development platform if combined with prove system. > (7) in 20 years be referred as Haskell method... These are all good ideas. Feel free to contribute code! You could start by modifying the night benchmarks for GHC to include statistics stating performance changes with respect to previous runs, so we know if things are getting better or worse. As a developer of libraries where performance is very important, I know that once I have performance numbers, I tend to try to make those numbers smaller! Its good motivation. -- Don _______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
