Observation:

The best gcc result shown in the thread, if I recall, precomputed the result of the full computation at compiletime and simply outputted it, when we looked at the assembly.

While I will accept that this could be seen as an optimization GHC should have made, I do not accept that this will be the case with most everyday code a programmer writes, as most code is not used to simply compute arithmetic constants.

For code that actively requires computation at runtime, I have seen no examples of an instance where well-optimized GHC is actually dozens or hundreds of times slower than GCC output.

Louis Wasserman
wasserman.louis@gmail.com


On Sat, Feb 21, 2009 at 5:21 PM, Bulat Ziganshin <bulat.ziganshin@gmail.com> wrote:
Hello Louis,

Saturday, February 21, 2009, 4:16:10 AM, you wrote:

> In the meantime, a brief summary:

a minor correction: the best gcc result shown in the thread was 50x
faster than Don's one, so you need to miltiple all ratios by a factor
of 50

> 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.

yes, within 150x margin

> When performance is an absolute necessity,
> Haskell code can sometimes be manually modified (e.g. with manual
> loop unrolls) to equal GCC in performance.

yes, to make it only 50x slower while being only 7 times larger (i
mean source lines)

> Can we move on?

yes, we can! :)


--
Best regards,
 Bulat                            mailto:Bulat.Ziganshin@gmail.com