I am no longer sure that this conversation is producing useful information or a learning experience for any involved party, and suggest it ends.<br><br>In the meantime, a brief summary:<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 GCC code when compiled with appropriate optimizations in GHC.</li>
<li>When performance is an absolute necessity, Haskell code can sometimes be manually modified (e.g. with manual loop unrolls) to equal GCC in performance.</li><li>The amount of effort required for manually unrolling loops is greater than simply using standard GCC optimizations, and in practice few programmers will want to make this extra effort.&nbsp; For your everyday programmer, achieving that sort of performance is typically easier when writing in C.</li>
<li>If anybody wants a Haskell compiler to achieve GCC-level speeds while writing short and concise Haskell, it is preferable to add a ticket with examples already written out and exhaustively examined to minimize the effort Simon needs to make in working on the problem.&nbsp; GHC has had considerably fewer person-hours devoted to it than GCC, and only additional person-hours can improve it.<br>
</li><li>Even though it might not match with the amount of effort an average Haskell programmer would put into their code, it is *still* constructive to attempt to optimize Haskell code exhaustively and at a low level, if only to help us learn what sorts of transformations it would be useful for GHC to do automatically.&nbsp; This sort of information, I imagine, would be of significant use to Simon when attempting to improve GHC.</li>
</ul>Nobody is opining that everyday Haskell code will compile to code as speedy as GCC output.&nbsp; People *are* attempting to find out how Haskell code can be hacked at a low level to run as fast as GCC code, but not because they&#39;re claiming GHC output is as fast as GCC output.&nbsp; Rather, they&#39;re attempting to find out <br>
a) what sorts of approaches a really determined Haskell programmer can use to improve speed<br>b) the sorts of optimizations a later version of GHC might be able to make, and<br>c) what sort of code its optimizer might produce.<br>
<br>This is not being reported as &quot;fair Haskell vs C++ comparison&quot; -- this is a collaborative effort to *improve* Haskell that was motivated by Bulat&#39;s original comparison.<br><br>Can we move on?<br><br clear="all">
Louis Wasserman<br><a href="mailto:wasserman.louis@gmail.com">wasserman.louis@gmail.com</a><br>