Re[5]: [Haskell-cafe] Re: speed: ghc vs gcc
Hello Louis, Sunday, February 22, 2009, 2:30:23 AM, you wrote: yes, you are right. Don also compared results of 64x-reduced computation with full one. are you think that these results are more fair? 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 -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[5]: [Haskell-cafe] Re: speed: ghc vs gcc
I said nothing about fairness, and *never at any point said I thought Don's results were more useful or fair.* What makes you think that's what I meant to imply? You have not responded to my separate concern that 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. Rather than accusing me of taking sides, if you'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. (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.) Don's -D64 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. Don's results *are* useful, but not in the way you say we're claiming. Louis Wasserman wasserman.lo...@gmail.com On Sat, Feb 21, 2009 at 5:35 PM, Bulat Ziganshin bulat.zigans...@gmail.comwrote: Hello Louis, Sunday, February 22, 2009, 2:30:23 AM, you wrote: yes, you are right. Don also compared results of 64x-reduced computation with full one. are you think that these results are more fair? 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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[5]: [Haskell-cafe] Re: speed: ghc vs gcc
On Sat, Feb 21, 2009 at 11:35 PM, Bulat Ziganshin bulat.zigans...@gmail.com wrote: Hello Louis, Sunday, February 22, 2009, 2:30:23 AM, you wrote: yes, you are right. Don also compared results of 64x-reduced computation with full one. are you think that these results are more fair? Yes. Clearly so. It still computes the result from scratch - it just uses a trick which generates better code. This is clearly a useful and worthwhile exercise as it shows A) A neat trick with TH, B) A reasonably practical way to produce fast code for the critical parts of a Haskell app, C) a motivating example for implementing a compiler optimization to do it automatically. Just outputting the precomputed result means nothing. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[5]: [Haskell-cafe] Re: speed: ghc vs gcc
Sebastian, that's not Bulat's point. He's saying that if we make that optimization in Haskell, we should at least make the same optimization in GCC for fair comparison. (Though I'm not entirely sure that that optimization would be of any use to GCC, but that's a linguistic concern, no more.) His point is valid. But Don's results *not* obtained by optimizing in this fashion are valid comparisons, and the results obtained with this optimization are useful for other reasons. Louis Wasserman wasserman.lo...@gmail.com On Sat, Feb 21, 2009 at 5:55 PM, Sebastian Sylvan syl...@student.chalmers.se wrote: On Sat, Feb 21, 2009 at 11:35 PM, Bulat Ziganshin bulat.zigans...@gmail.com wrote: Hello Louis, Sunday, February 22, 2009, 2:30:23 AM, you wrote: yes, you are right. Don also compared results of 64x-reduced computation with full one. are you think that these results are more fair? Yes. Clearly so. It still computes the result from scratch - it just uses a trick which generates better code. This is clearly a useful and worthwhile exercise as it shows A) A neat trick with TH, B) A reasonably practical way to produce fast code for the critical parts of a Haskell app, C) a motivating example for implementing a compiler optimization to do it automatically. Just outputting the precomputed result means nothing. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[5]: [Haskell-cafe] Re: speed: ghc vs gcc
No, he asked if comparing the D64 version with the straight gcc one was more fair then comparing a version that precomputes the result with one that doesn't. That's what I responded to. On Sat, Feb 21, 2009 at 11:59 PM, Louis Wasserman wasserman.lo...@gmail.com wrote: Sebastian, that's not Bulat's point. He's saying that if we make that optimization in Haskell, we should at least make the same optimization in GCC for fair comparison. (Though I'm not entirely sure that that optimization would be of any use to GCC, but that's a linguistic concern, no more.) His point is valid. But Don's results *not* obtained by optimizing in this fashion are valid comparisons, and the results obtained with this optimization are useful for other reasons. Louis Wasserman wasserman.lo...@gmail.com On Sat, Feb 21, 2009 at 5:55 PM, Sebastian Sylvan syl...@student.chalmers.se wrote: On Sat, Feb 21, 2009 at 11:35 PM, Bulat Ziganshin bulat.zigans...@gmail.com wrote: Hello Louis, Sunday, February 22, 2009, 2:30:23 AM, you wrote: yes, you are right. Don also compared results of 64x-reduced computation with full one. are you think that these results are more fair? Yes. Clearly so. It still computes the result from scratch - it just uses a trick which generates better code. This is clearly a useful and worthwhile exercise as it shows A) A neat trick with TH, B) A reasonably practical way to produce fast code for the critical parts of a Haskell app, C) a motivating example for implementing a compiler optimization to do it automatically. Just outputting the precomputed result means nothing. -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[5]: [Haskell-cafe] Re: speed: ghc vs gcc
It's not practical at all. It's monstrously more complicated than C. It would be much simpler to do it in C and use FFI. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 21, 2009, at 4:55 PM, Sebastian Sylvan wrote: B) A reasonably practical way to produce fast code for the critical parts of a Haskell app, ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
