Bulat, Thank you for being productive. =)
of course these results are useful! my own goal was just to make fair comparison. i'm bothered when people said that ghc should be used for something like video codecs based on those "let's optimize only for haskell" pseudo-benchmarks. if Don was omitted unoptimized gcc results from is chart and you don't wrote those "conclusions" based on the chart, i will never make this comment Haskellers do need a baseline, y'know. What I mean by that is, attempting to write Haskell code that is as fast as gcc-optimized "typical" code is a useful enterprise. Of course it's possible to write a faster gcc program than the one that Don compared to, but it's still a useful benchmark, and of course it's not fair to optimize the heck out of Haskell code and leave gcc code untouched and then say a comparison between *those* pieces of code is fair. I think we all agree on my original point now, that - Straightforward and simple Haskell code, written by an individual aware of issues with tail recursion and stream fusion, is frequently within 3x the speed of *straightforward and simple* GCC code when compiled with appropriate optimizations in GHC. Sebastian, yes, there's still useful conversation to be had about more super-heavily-optimized code. (Bulat, if you'd like to continue posting examples of more heavily optimized C and its outputted assembly, I think that'd still provide a useful comparison in a conversation that can be continued civilly on all sides.) Louis Wasserman wasserman.lo...@gmail.com
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
