On Mon, Feb 26, 2007 at 03:43:08AM +0100, Andrzej Jaworski wrote:
It sounds reasonable. However knowledge of how program performs in micro-steps does not add up, so the benchmarks may wet up appetite for lunch that does not come. I have pointed into such example - an astonishing and unexplained underperformance of Haskell with all the profiling information at hand.
I guess Haskell compilers are not particularly good at detecting specific properties of a program and hence with optimizing it. This however shows up with size so Donald's benchmarks cannot catch that out.
For this reason, undiagnosed and untreated, Haskell has been abandoned for example in Algebraic Dynamic Programming, in spite of its unparallel expressive power and a lot of hope. In ILP/IFP and GP it failed too.
C, thirty years ago: (disclaimer, I'm 16) * Very much slower than assembly * Very much easier to use than assembly * Very easy to interface with assembly So everyone used C with assembler inner loops, no big deal. Haskell, now: * Very much slower than C * Very much easier to use than C * Very easy to interface with C So I think we should do the same. It even shows in the Shootout - the programs that are simultaneously fastest and clearest are not pure Haskell, but delegate their innermost loops to tuned C libraries (FPS and GMP). Stefan