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.lo...@gmail.com
On Sat, Feb 21, 2009 at 5:21 PM, Bulat Ziganshin
bulat.zigans...@gmail.comwrote:
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,
Bulatmailto:bulat.zigans...@gmail.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
