Re[7]: [Haskell-cafe] Re: speed: ghc vs gcc
Hello Sebastian, Sunday, February 22, 2009, 2:55:38 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. yes, but does you know why his last program is 64x faster than simple code? it's because *gcc* optimize it this way. the first program i published there does it by mistake, then i fixed it by using 'xor' instead of (+) and published here that i've considered most fair comparison OTOH Don used this gcc optimization to generate faster code for haskell. he doesn't used this trick for C++ and doesn't omitted unoptimized gcc results from the chart. as a result people who don't analyzed details made conclusion that ghc outperformed gcc here so i have made experiment with cheating the same way, but in more obvious manner. and i got 3 angry answers in 5 minutes. so what are the difference? you don't catched details of Don comparison or you bothered only by gcc-related cheating? -- 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[7]: [Haskell-cafe] Re: speed: ghc vs gcc
On Sun, Feb 22, 2009 at 12:10 AM, Bulat Ziganshin bulat.zigans...@gmail.com wrote: Hello Sebastian, Sunday, February 22, 2009, 2:55:38 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. yes, but does you know why his last program is 64x faster than simple code? it's because *gcc* optimize it this way. the first program i published there does it by mistake, then i fixed it by using 'xor' instead of (+) and published here that i've considered most fair comparison OTOH Don used this gcc optimization to generate faster code for haskell. he doesn't used this trick for C++ and doesn't omitted unoptimized gcc results from the chart. as a result people who don't analyzed details made conclusion that ghc outperformed gcc here so i have made experiment with cheating the same way, but in more obvious manner. and i got 3 angry answers in 5 minutes. so what are the difference? you don't catched details of Don comparison or you bothered only by gcc-related cheating? Bulat, please stop insulting everyone whenever you discuss something. Was that sentence really necessary? You really think it's productive to insinuate that I'm intellectualy dishonest? I'm afraid I don't understand what you're talking about, could you try being a bit clearer? As I understand it you compared a gcc version which printed the precomputed result, with a GHC version which computed the result at runtime, and got the 150x figure from that. Is this incorrect? If so, say so. Don't accuse everyone who disagrees with you of being dishonest. NOBODY in this thread has said anything to even remotely suggest that they think it's okay to cheat in favour of Haskell and consider it fair, yet you jump to this conclusion every single time. Please, give people the benefit of the doubt? Just because someone disagrees with you does not make them stupid or dishonest. Maybe they're actually right, or maybe you didn't make your point clear enough, or maybe they just misunderstood you. Either way, please try to be civil. The only argument anyone made towards cheating on the gcc side is that ANY program which just prints a precomputed result is worthless for comparisoin (regardless of which side is doing it). -- 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[7]: [Haskell-cafe] Re: speed: ghc vs gcc
Hello Louis, Sunday, February 22, 2009, 2:59:05 AM, you 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.) :))) it was *ghc* who replaced 64 additions with just one: sum += [n..n+k] == sum += n*k+const my first program had this optimization by mistake. i've found way to avoid it completely, Don found way to use it only in Haskell :) 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. of course these results are useful! my own goal was just to make fair comparison. i'm bothered when people said that ghc should be used for something like video codecs based on those let's optimize only for haskell pseudo-benchmarks. if Don was omitted unoptimized gcc results from is chart and you don't wrote those conclusions based on the chart, i will never make this comment 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. -- 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[7]: [Haskell-cafe] Re: speed: ghc vs gcc
Bulat, Thank you for being productive. =) of course these results are useful! my own goal was just to make fair comparison. i'm bothered when people said that ghc should be used for something like video codecs based on those let's optimize only for haskell pseudo-benchmarks. if Don was omitted unoptimized gcc results from is chart and you don't wrote those conclusions based on the chart, i will never make this comment Haskellers do need a baseline, y'know. What I mean by that is, attempting to write Haskell code that is as fast as gcc-optimized typical code is a useful enterprise. Of course it's possible to write a faster gcc program than the one that Don compared to, but it's still a useful benchmark, and of course it's not fair to optimize the heck out of Haskell code and leave gcc code untouched and then say a comparison between *those* pieces of code is fair. I think we all agree on my original point now, that - 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 *straightforward and simple* GCC code when compiled with appropriate optimizations in GHC. Sebastian, yes, there's still useful conversation to be had about more super-heavily-optimized code. (Bulat, if you'd like to continue posting examples of more heavily optimized C and its outputted assembly, I think that'd still provide a useful comparison in a conversation that can be continued civilly on all sides.) Louis Wasserman wasserman.lo...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
