Bulat,<br><br>Thank you for being productive. =)<br><br><div style="margin-left: 40px;">of course these results are useful! my own goal was just to make fair<br>
comparison. i&#39;m bothered when people said that ghc should be used<br>
for something like video codecs based on those &quot;let&#39;s optimize only<br>
for haskell&quot; pseudo-benchmarks. if Don was omitted unoptimized gcc<br>
results from is chart and you don&#39;t wrote those &quot;conclusions&quot; based on<br>
the chart, i will never make this comment<br></div><br>Haskellers do need a baseline, y&#39;know.&nbsp; What I mean by that is, attempting to write Haskell code that is as fast as gcc-optimized &quot;typical&quot; code is a useful enterprise.&nbsp; Of course it&#39;s possible to write a faster gcc program than the one that Don compared to, but it&#39;s still a useful benchmark, and of course it&#39;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.<br>
<br>I think we all agree on my original point now, that<br><ul><li>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.</li></ul>Sebastian, yes, there&#39;s still useful conversation to be had about more super-heavily-optimized code.&nbsp; (Bulat, if you&#39;d like to continue posting examples of more heavily optimized C and its outputted assembly, I think that&#39;d still provide a useful comparison in a conversation that can be continued civilly on all sides.)<br>
<br clear="all">Louis Wasserman<br><a href="mailto:wasserman.louis@gmail.com">wasserman.louis@gmail.com</a><br>
<br><br>