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.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.zigans...@gmail.com > >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe