I said nothing about fairness, and *never at any point said I thought Don&#39;s results were more useful or fair.*&nbsp; What makes you think that&#39;s what I meant to imply?<br><br>You have not responded to my separate concern that<br>
&gt; For code that actively requires computation at runtime, I have seen<br>
&gt; no examples of an instance where well-optimized GHC is actually<br>
&gt; dozens or hundreds of times slower than GCC output.<br><br>Rather than accusing me of taking sides, if you&#39;d take an actual apples-to-apples comparison, citing the best Haskell results and best GCC results -- without using examples from either language which performed computation at compile-time that would not be possible in everyday programs -- my original claims were true: that GHC code is frequently within 3x the speed of GCC code, and hacked-up GHC code can reach and match GCC performance -- though I agree those hacks require an impractical blowup in code size.&nbsp; (Depending on your individual interpretation of what an average Haskell program looks like, I concede that 3x might be off by a factor of 2 or so -- but not the factor of 50 you claimed.)<br>
<br>Don&#39;s &quot;-D64&quot; results, while *not* a useful gcc-vs-ghc comparison, are relevant if really determined Haskellers are interested in learning how to obtain the absolute optimal perfection from their code.&nbsp; Don&#39;s results *are* useful, but not in the way you say we&#39;re claiming.<br>
<br clear="all">Louis Wasserman<br><a href="mailto:wasserman.louis@gmail.com">wasserman.louis@gmail.com</a><br>
<br><br><div class="gmail_quote">On Sat, Feb 21, 2009 at 5:35 PM, Bulat Ziganshin <span dir="ltr">&lt;<a href="mailto:bulat.ziganshin@gmail.com">bulat.ziganshin@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hello Louis,<br>
<br>
Sunday, February 22, 2009, 2:30:23 AM, you wrote:<br>
<br>
yes, you are right. Don also compared results of 64x-reduced<br>
computation with full one. are you think that these results are more<br>
fair?<br>
<div><div></div><div class="Wj3C7c"><br>
&gt; Observation:<br>
<br>
&gt; The best gcc result shown in the thread, if I recall, precomputed<br>
&gt; the result of the full computation at compiletime and simply<br>
&gt; outputted it, when we looked at the assembly.<br>
<br>
&gt; While I will accept that this could be seen as an optimization GHC<br>
&gt; should have made, I do not accept that this will be the case with<br>
&gt; most everyday code a programmer writes, as most code is not used to<br>
&gt; simply compute arithmetic constants.<br>
&gt;<br>
&gt; For code that actively requires computation at runtime, I have seen<br>
&gt; no examples of an instance where well-optimized GHC is actually<br>
&gt; dozens or hundreds of times slower than GCC output.<br>
<br>
&gt; Louis Wasserman<br>
&gt; &nbsp;<a href="mailto:wasserman.louis@gmail.com">wasserman.louis@gmail.com</a><br>
&gt;<br>
<br></div></div></blockquote></div><br>