Re: [Haskell-cafe] Re: speed: ghc vs gcc
I think this thread has stopped being useful and started going round in circles, so I've blocked all messages to it and... On Sat, Feb 21, 2009 at 04:28:21PM -0800, Donald Bruce Stewart wrote: > > I'm setting your moderation bit now ...reverted this. Thanks Ian ___ 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
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
Re: [Haskell-cafe] Re: speed: ghc vs gcc
Bulat, you've some serious lessons to learn on how to interact with online communities. First, 1. Stop posting replies to every post on this thread 2. Read some of the fine literature on how to be a productive, contributing member of a mailing list community, http://haskell.org/haskellwiki/Protect_the_community 3. Then see if you can rephrase your concerns in a form that will be useful. Claus (as always) has made a fine suggestion: http://www.haskell.org/pipermail/haskell-cafe/2009-February/056241.html 3. Come back with some analysis, or a ticket, and authentically try to collaborate with people here to improve or fix the problems you see. I'm setting your moderation bit now, and in public so we all know what is going on, so your posts will bounce until you do something constructive. This will likely expire in a few days - just enough to calm things down. -- Don (on jerk police protrol today) P.S. if anyone strongly objects, let's talk offline how better to manage things. ___ 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 > wrote: > > On Sat, Feb 21, 2009 at 11:35 PM, Bulat Ziganshin > 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
On Sun, Feb 22, 2009 at 12:10 AM, Bulat Ziganshin 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 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: [Haskell-cafe] Re: speed: ghc vs gcc
Am Sonntag, 22. Februar 2009 00:50 schrieb Bulat Ziganshin: > Hello Daniel, > > Sunday, February 22, 2009, 2:36:57 AM, you wrote: > > You're referring to the freak result of Dan Doel? > > Come on, be serious, please. I have a Haskell result that runs in 7ms, > > too. Just use a rewrite rule and hey presto :) > > Dan, why you have not said the same about test where ghc becomes 4x > faster than gcc? Because, as has been explained several times to you, it was not a test of ghc's code generation vs. gcc's, and it was NOT meant to be. It was explicitely an investigation of how effective an improvement loop-unrolling could be. > > > Bulat, your obsession has become obnoxious and ridiculous. > > i really, really wonder why cheating on gcc side is "obsession that > become obnoxious and ridiculous" while cheating on ghc side is ok for > you. can you explain? Seriously You have one case where gcc calculated the result for an extremely simple programme during the compilation and you use that to say that gcc's code is routinely 50-150 times faster than ghc's. Very convincing. ___ 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 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
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
On Sat, Feb 21, 2009 at 11:35 PM, Bulat Ziganshin 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
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 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? > > > 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[2]: [Haskell-cafe] Re: speed: ghc vs gcc
Hello Daniel, Sunday, February 22, 2009, 2:36:57 AM, you wrote: > You're referring to the freak result of Dan Doel? > Come on, be serious, please. I have a Haskell result that runs in 7ms, too. > Just use a rewrite rule and hey presto :) Dan, why you have not said the same about test where ghc becomes 4x faster than gcc? > Bulat, your obsession has become obnoxious and ridiculous. i really, really wonder why cheating on gcc side is "obsession that become obnoxious and ridiculous" while cheating on ghc side is ok for you. can you explain? -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
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 > 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: [Haskell-cafe] Re: speed: ghc vs gcc
Am Sonntag, 22. Februar 2009 00:21 schrieb Bulat Ziganshin: > 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 You're referring to the freak result of Dan Doel? Come on, be serious, please. I have a Haskell result that runs in 7ms, too. Just use a rewrite rule and hey presto :) > > > 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 Bulat, your obsession has become obnoxious and ridiculous. > > > 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! :) Apparently not :( ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[3]: [Haskell-cafe] Re: speed: ghc vs gcc
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 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, > Bulatmailto:bulat.zigans...@gmail.com > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[3]: [Haskell-cafe] Re: speed: ghc vs gcc
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
Re: Re[6]: [Haskell-cafe] Re: speed: ghc vs gcc
> > > nothing should stop you from writing video games in Haskell since > > video codec isn't video game :))) > ouch, mea culpa, I misread your message. > > > but I've worked with people that wrote physics engines in C/C++, > > and they also had to hand optimize specifically for a certain compiler to > get things fast. > > that's important signal. if you need to hand-optimize your code even > if you use icl to compile it, using haskell will be like hunting with > a hand instead of gun well in the past I wrote a couple of video codecs (one was a multi core motion JPEG decoder), and I had to write parts of it in assembler to get fast enough frame rates. but that is already more than 10 years ago, today I don't think I could beat a C/C++ compiler like ICL anymore, at least not in a reasonable time frame ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: speed: ghc vs gcc
Most people in the games industry that I knew don't even know haskell. they are trained imperative hackers. However tim sweeney studies haskell, so it cetainly has influenced at least one well known game developer. But I wasn't saying that Haskell *is* used, I said one could use it for programming the logic of a game. And I'm not saying a AAA nexgen title :-) On Sat, Feb 21, 2009 at 1:10 AM, Achim Schneider wrote: > Peter Verswyvelen wrote: > > > nothing should stop you from writing video games in Haskell > > > Show me a studio that uses Haskell and I'd even accept dollars or pounds > as payment. > > -- > (c) this sig last receiving data processing entity. Inspect headers > for copyright history. All rights reserved. Copying, hiring, renting, > performance and/or quoting of this signature prohibited. > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: speed: ghc vs gcc
Bulat Ziganshin ha scritto: [...] but problem - not mine, but for haskellers, is that some people said that ghc can generate code that is as fast as gcc one. it will be stupid if someone will start to write say mpeg4 codec and after year of work will find that it need 100 Ghz cpu to work. IMHO, a more viable solution is to write the *parser* in GHC, but use the raw code written in C. As an example, I get some problems from mplayer, not caused by the codec, but by the demuxer and stream parsing. Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: speed: ghc vs gcc
bertram.felgenhauer: > This is odd, but it doesn't hurt the inner loop, which only involves > $wsum01_XPd, and is identical to $wfold_s15t above. > > > Checking the asm: > > $ ghc -O2 -fasm > > > > sQ3_info: > > .LcRt: > > cmpq 8(%rbp),%rsi > > jg .LcRw > > leaq 1(%rsi),%rax > > addq %rsi,%rbx > > movq %rax,%rsi > > jmp sQ3_info > > So for some reason ghc ends up doing the (n + 1) addition before the > (acc + n) addition in this case - this accounts for the extra > instruction, because both n+1 and n need to be kept around for the > duration of the addq (which does the acc + n addition). Yep, well spotted. > > Checking via C: > > > >$ ghc -O2 -optc-O3 -fvia-C > > > > Better code, but still a bit slower: > > > > sQ3_info: > > cmpq8(%rbp), %rsi > > jg .L8 > > addq%rsi, %rbx > > leaq1(%rsi), %rsi > > jmp sQ3_info > > This code is identical (up to renaming registers and one offset that > I can't fully explain, but is probably related to a slight difference > in handling pointer tags between the two versions of the code) to the > "nice assembly" above. Indeed, which is gratifying. > > Running: > > > > $ time ./B > > 55 > > ./B 1.01s user 0.01s system 97% cpu 1.035 total > > Hmm, about 5% slower, are you sure this isn't just noise? > > If not noise, it may be some alignment effect. Hard to say. I couldn't get it under 1s from a dozen runs, so assuming some small effect with alignment. Why we get the extra test in the outer loop though, not sure. That's new too I think -- at least I've not seen that pattern before. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: speed: ghc vs gcc
Don Stewart wrote:
> If we take what I usually see as the best loops GHC can do for this kind
> of thing:
>
> import Data.Array.Vector
>
> main = print (sumU (enumFromToU 1 (10^9 :: Int)))
>
> And compile it:
>
> $ ghc-core A.hs -O2 -fvia-C -optc-O3
>
> We get ideal core, all data structures fused away, and no heap allocation:
>
> $wfold_s15t :: Int# -> Int# -> Int#
> $wfold_s15t =
> \ (ww1_s150 :: Int#) (ww2_s154 :: Int#) ->
> case ># ww2_s154 ww_s14U of wild_aWm {
> False ->
> $wfold_s15t
> (+# ww1_s150 ww2_s154) (+# ww2_s154 1);
> True -> ww1_s150
> }; } in
> case $wfold_s15t 0 1
>
> Which produces nice assembly:
>
> s16e_info:
> cmpq6(%rbx), %rdi
> jg .L2
> addq%rdi, %rsi
> leaq1(%rdi), %rdi
> jmp s16e_info
Note that this does the addition to the accumulator first, and then
increments the counter.
[snip]
> I wondered if we just got worse code on backwards counting loops. So
> translating into the "obvious" translation, counting up:
>
> main = print (sum0 0 1)
>
> sum0 :: Int -> Int -> Int
> sum0 acc n | n > 10^9 = acc
>| otherwise = sum0 (acc + n) (n + 1)
>
> We start to notice something interesting:
>
>
> $wsum0 :: Int# -> Int# -> Int#
> $wsum0 =
> \ (ww_sOH :: Int#) (ww1_sOL :: Int#) ->
> case lvl2 of wild1_aHn { I# y_aHp ->
> case ># ww1_sOL y_aHp of wild_B1 {
> False ->
> letrec {
>
> $wsum01_XPd :: Int# -> Int# -> Int#
> $wsum01_XPd =
> \ (ww2_XP4 :: Int#) (ww3_XP9 :: Int#) ->
> case ># ww3_XP9 y_aHp of wild11_Xs {
> False ->
> $wsum01_XPd (+# ww2_XP4 ww3_XP9) (+# ww3_XP9 1);
> True -> ww2_XP4
> }; } in
> $wsum01_XPd (+# ww_sOH ww1_sOL) (+# ww1_sOL 1);
>
> True -> ww_sOH
> }
This is odd, but it doesn't hurt the inner loop, which only involves
$wsum01_XPd, and is identical to $wfold_s15t above.
> Checking the asm:
> $ ghc -O2 -fasm
>
> sQ3_info:
> .LcRt:
> cmpq 8(%rbp),%rsi
> jg .LcRw
> leaq 1(%rsi),%rax
> addq %rsi,%rbx
> movq %rax,%rsi
> jmp sQ3_info
So for some reason ghc ends up doing the (n + 1) addition before the
(acc + n) addition in this case - this accounts for the extra
instruction, because both n+1 and n need to be kept around for the
duration of the addq (which does the acc + n addition).
> Checking via C:
>
>$ ghc -O2 -optc-O3 -fvia-C
>
> Better code, but still a bit slower:
>
> sQ3_info:
> cmpq8(%rbp), %rsi
> jg .L8
> addq%rsi, %rbx
> leaq1(%rsi), %rsi
> jmp sQ3_info
This code is identical (up to renaming registers and one offset that
I can't fully explain, but is probably related to a slight difference
in handling pointer tags between the two versions of the code) to the
"nice assembly" above.
> Running:
>
> $ time ./B
> 55
> ./B 1.01s user 0.01s system 97% cpu 1.035 total
Hmm, about 5% slower, are you sure this isn't just noise?
If not noise, it may be some alignment effect. Hard to say.
Bertram
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[4]: [Haskell-cafe] Re: speed: ghc vs gcc
--- On Fri, 2/20/09, Bulat Ziganshin wrote: > From: Bulat Ziganshin > Subject: Re[4]: [Haskell-cafe] Re: speed: ghc vs gcc > To: "Isaac Gouy" > Cc: haskell-cafe@haskell.org > Date: Friday, February 20, 2009, 4:43 PM > Hello Isaac, > > Saturday, February 21, 2009, 3:28:31 AM, you wrote: > > > When did you look - six months ago? a year ago? 3 > years ago? > > ah, again this argument. two weeks ago Don said that ghc > changed a lot > in 2 years, now when we see that there is no difference, he > says that > those loop optimizer is somewhere noone know where. now i > should look > into new set of tests just because everyone else believe > that ghc is > shiny. please look yourself, i will continue to say about > testset i > have seen when 6.6 arrived If you're going to continue talking about a testset you saw in 2006 then tell people you are talking about 2006. > >> most of these tests depends on libraries speed > > Most? > > 2 of 12 strongly depend on libraries because PCRE and > GMP are explicitly allowed. > > *were* depending on libs speed. in particular, > haskell's triumph - > multithreading tests, chameneos or so Most? If you add those 2, that makes 4 out of 12 (4 out of 17 in the old data). > >> in one test, PHP is 1st > > I don't believe that has ever been true - which > test? > > large regexps one PHP is not 1st in regex-dna. PHP is not even 1st in regex-dna in the old data. PHP is not even in the first 15 in regex-dna in the old data. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: speed: ghc vs gcc
I am no longer sure that this conversation is producing useful information or a learning experience for any involved party, and suggest it ends. In the meantime, a brief summary: - 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. - When performance is an absolute necessity, Haskell code can sometimes be manually modified (e.g. with manual loop unrolls) to equal GCC in performance. - The amount of effort required for manually unrolling loops is greater than simply using standard GCC optimizations, and in practice few programmers will want to make this extra effort. For your everyday programmer, achieving that sort of performance is typically easier when writing in C. - If anybody wants a Haskell compiler to achieve GCC-level speeds while writing short and concise Haskell, it is preferable to add a ticket with examples already written out and exhaustively examined to minimize the effort Simon needs to make in working on the problem. GHC has had considerably fewer person-hours devoted to it than GCC, and only additional person-hours can improve it. - Even though it might not match with the amount of effort an average Haskell programmer would put into their code, it is *still* constructive to attempt to optimize Haskell code exhaustively and at a low level, if only to help us learn what sorts of transformations it would be useful for GHC to do automatically. This sort of information, I imagine, would be of significant use to Simon when attempting to improve GHC. Nobody is opining that everyday Haskell code will compile to code as speedy as GCC output. People *are* attempting to find out how Haskell code can be hacked at a low level to run as fast as GCC code, but not because they're claiming GHC output is as fast as GCC output. Rather, they're attempting to find out a) what sorts of approaches a really determined Haskell programmer can use to improve speed b) the sorts of optimizations a later version of GHC might be able to make, and c) what sort of code its optimizer might produce. This is not being reported as "fair Haskell vs C++ comparison" -- this is a collaborative effort to *improve* Haskell that was motivated by Bulat's original comparison. Can we move on? Louis Wasserman wasserman.lo...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Re: speed: ghc vs gcc
I was intending to send this privately but clicked the wrong button. Apologies for adding even more noise to this discussion. On Sat, Feb 21, 2009 at 12:47 AM, Sebastian Sylvan < syl...@student.chalmers.se> wrote: > > > On Sat, Feb 21, 2009 at 12:16 AM, Bulat Ziganshin < > bulat.zigans...@gmail.com> wrote: > >> Hello Sebastian, >> >> Saturday, February 21, 2009, 2:42:33 AM, you wrote: >> >> > Bulat, please, you're missing the point. >> >> actually you are missing the point. i mirror Don's >> "non-attacking" style of comments on my person. are you mentioned >> those Don letter? sure - no >> >> > Nobody is saying that the >> > template-haskell trick was somehow a viable general strategy right >> > now that everyone should use by default. It was used as a >> > proof-of-concept that a simple technique can lead to massive >> > performance improvements - and we get numbers for how massive it >> > would be (beating gcc for this benchmark). >> >> sorry, but you was fooled too. the situation was the following: i >> wrote non-optimal code for 64-bit platforms (using 32-bit int) and Don >> don't corrected it. then he compiled TH-generated code via *gcc* that >> used "fusion" technique - the same that was used by 32-bit C++ code >> >> are you wondered why -D64 version is 8 times faster than -D8 one? it's >> exactly because *gcc* reduced 64 additions to just one operation. so >> this "fair" comparison used TH+gcc to generate faster code than gcc >> with improper data type definitions. if Don will fix C++ program, he >> will find that it's speed reduced in the same proportion - without TH >> tricks >> >> > >> > This isn't about "faking" a benchmark, it's about investigating the >> > reasons for why the benchmark looks they way it does, doing testing >> > to verify the assumptions (in this case using TH), and making >> > constructive suggestions (add loop-unrolling to the compiler). This >> > investigation tells us that in this case a compiler could beat gcc, >> > if only it were to do loop unrolling in the way the TH code does. That's >> a result! >> >> yes, in the cases when *gcc* "fuse" loops and you don't allow it do it >> for C++ code but allows for Haskell - you will win >> >> >> > I would ask you to note the simple fact that every single >> > constructive message in this thread has come from people other than >> > you. >> >> you are ignore, though, the fact that every destructive message in >> this thread comes against me. it seems that it's a crime here to write >> about ghc speed anything but praise. in best case people will said >> that these tests are destructive :lol: >> >> >> > I hope this leads you reconsider your tone and general approach >> > in the future. Haskell people in general are always pretty good at >> > accepting criticism IME (they tend to want to fix the problem), >> >> that criticism??? cows can't fly, and ghc cannot beat gcc in 2 >> months. that bothers me is people that attack me just for comparing >> compilers head-to-head >> > > I'm not going to debate all these points with you because I don't think you > actually responded to mine, but let me just say that MY impression of this > thread is that people attack you not because you compare compilers > head-to-head, but because you do it in an incredibly abrasive and hostile > manner (your messages read much more like "Haha! I told you so, look how > stupid/dishonest you are!", than "Here's a case where GHC produces bad code, > here's some analysis, and here's a ticket/patch for it"). > Just because you put a smiley at the end of a thinly veiled ad hominem > doesn't mean you get to pretend that you're just a victim when people get > understandably ticked off at your tone and respond in kind. > > Search the archives, performance discussions come up all the time, often > with quite vigorous criticism of GHC's current results, but somehow those > threads manage to stay civil and on point. Please, do a little introspection > and see if you can stick to a more constructive and friendly tone in the > future - I would be willing to bet that if you did, you wouldn't get > "attacked". > > -- > 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[2]: [Haskell-cafe] Re: speed: ghc vs gcc
On Sat, Feb 21, 2009 at 12:16 AM, Bulat Ziganshin wrote: > Hello Sebastian, > > Saturday, February 21, 2009, 2:42:33 AM, you wrote: > > > Bulat, please, you're missing the point. > > actually you are missing the point. i mirror Don's > "non-attacking" style of comments on my person. are you mentioned > those Don letter? sure - no > > > Nobody is saying that the > > template-haskell trick was somehow a viable general strategy right > > now that everyone should use by default. It was used as a > > proof-of-concept that a simple technique can lead to massive > > performance improvements - and we get numbers for how massive it > > would be (beating gcc for this benchmark). > > sorry, but you was fooled too. the situation was the following: i > wrote non-optimal code for 64-bit platforms (using 32-bit int) and Don > don't corrected it. then he compiled TH-generated code via *gcc* that > used "fusion" technique - the same that was used by 32-bit C++ code > > are you wondered why -D64 version is 8 times faster than -D8 one? it's > exactly because *gcc* reduced 64 additions to just one operation. so > this "fair" comparison used TH+gcc to generate faster code than gcc > with improper data type definitions. if Don will fix C++ program, he > will find that it's speed reduced in the same proportion - without TH > tricks > > > > > This isn't about "faking" a benchmark, it's about investigating the > > reasons for why the benchmark looks they way it does, doing testing > > to verify the assumptions (in this case using TH), and making > > constructive suggestions (add loop-unrolling to the compiler). This > > investigation tells us that in this case a compiler could beat gcc, > > if only it were to do loop unrolling in the way the TH code does. That's > a result! > > yes, in the cases when *gcc* "fuse" loops and you don't allow it do it > for C++ code but allows for Haskell - you will win > > > > I would ask you to note the simple fact that every single > > constructive message in this thread has come from people other than > > you. > > you are ignore, though, the fact that every destructive message in > this thread comes against me. it seems that it's a crime here to write > about ghc speed anything but praise. in best case people will said > that these tests are destructive :lol: > > > > I hope this leads you reconsider your tone and general approach > > in the future. Haskell people in general are always pretty good at > > accepting criticism IME (they tend to want to fix the problem), > > that criticism??? cows can't fly, and ghc cannot beat gcc in 2 > months. that bothers me is people that attack me just for comparing > compilers head-to-head > I'm not going to debate all these points with you because I don't think you actually responded to mine, but let me just say that MY impression of this thread is that people attack you not because you compare compilers head-to-head, but because you do it in an incredibly abrasive and hostile manner (your messages read much more like "Haha! I told you so, look how stupid/dishonest you are!", than "Here's a case where GHC produces bad code, here's some analysis, and here's a ticket/patch for it"). Just because you put a smiley at the end of a thinly veiled ad hominem doesn't mean you get to pretend that you're just a victim when people get understandably ticked off at your tone and respond in kind. Search the archives, performance discussions come up all the time, often with quite vigorous criticism of GHC's current results, but somehow those threads manage to stay civil and on point. Please, do a little introspection and see if you can stick to a more constructive and friendly tone in the future - I would be willing to bet that if you did, you wouldn't get "attacked". -- 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[4]: [Haskell-cafe] Re: speed: ghc vs gcc
Hello Isaac, Saturday, February 21, 2009, 3:28:31 AM, you wrote: > When did you look - six months ago? a year ago? 3 years ago? ah, again this argument. two weeks ago Don said that ghc changed a lot in 2 years, now when we see that there is no difference, he says that those loop optimizer is somewhere noone know where. now i should look into new set of tests just because everyone else believe that ghc is shiny. please look yourself, i will continue to say about testset i have seen when 6.6 arrived >> most of these tests depends on libraries speed > Most? > 2 of 12 strongly depend on libraries because PCRE and GMP are explicitly > allowed. *were* depending on libs speed. in particular, haskell's triumph - multithreading tests, chameneos or so >> in one test, PHP is 1st > I don't believe that has ever been true - which test? large regexps one > Please note that "sum-file" has not been included since autumn 2008. ok -- 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[2]: [Haskell-cafe] Re: speed: ghc vs gcc
--- On Fri, 2/20/09, Bulat Ziganshin wrote: -snip- > > You need look no further than the debian language > shootout that things > > really aren't as bad as you're making out √ > Haskell comes in in > > general less than 3x slower than gcc compiled C. > > you should look inside these tests, as i done :) When did you look - six months ago? a year ago? 3 years ago? > most of these tests depends on libraries speed Most? 2 of 12 strongly depend on libraries because PCRE and GMP are explicitly allowed. > in one test, PHP is 1st I don't believe that has ever been true - which test? > from 2 or 3 tests that depends on compiler speed, one > was fooled by adding special function readInt to ghc libs and the rest > are written in low-level haskell code - look the sources Please note that "sum-file" is not included in the current tests. Please note that "sum-file" has not been included since autumn 2008. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: speed: ghc vs gcc
Hello Achim, Saturday, February 21, 2009, 2:37:55 AM, you wrote: > not having enough weight in the shootout. For now, you can just use TH > to force things getting evaluated. (Try to do that in C) they have Templates axe too :) -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: speed: ghc vs gcc
Hello Sebastian, Saturday, February 21, 2009, 2:42:33 AM, you wrote: > Bulat, please, you're missing the point. actually you are missing the point. i mirror Don's "non-attacking" style of comments on my person. are you mentioned those Don letter? sure - no > Nobody is saying that the > template-haskell trick was somehow a viable general strategy right > now that everyone should use by default. It was used as a > proof-of-concept that a simple technique can lead to massive > performance improvements - and we get numbers for how massive it > would be (beating gcc for this benchmark). sorry, but you was fooled too. the situation was the following: i wrote non-optimal code for 64-bit platforms (using 32-bit int) and Don don't corrected it. then he compiled TH-generated code via *gcc* that used "fusion" technique - the same that was used by 32-bit C++ code are you wondered why -D64 version is 8 times faster than -D8 one? it's exactly because *gcc* reduced 64 additions to just one operation. so this "fair" comparison used TH+gcc to generate faster code than gcc with improper data type definitions. if Don will fix C++ program, he will find that it's speed reduced in the same proportion - without TH tricks > > This isn't about "faking" a benchmark, it's about investigating the > reasons for why the benchmark looks they way it does, doing testing > to verify the assumptions (in this case using TH), and making > constructive suggestions (add loop-unrolling to the compiler). This > investigation tells us that in this case a compiler could beat gcc, > if only it were to do loop unrolling in the way the TH code does. That's a > result! yes, in the cases when *gcc* "fuse" loops and you don't allow it do it for C++ code but allows for Haskell - you will win > I would ask you to note the simple fact that every single > constructive message in this thread has come from people other than > you. you are ignore, though, the fact that every destructive message in this thread comes against me. it seems that it's a crime here to write about ghc speed anything but praise. in best case people will said that these tests are destructive :lol: > I hope this leads you reconsider your tone and general approach > in the future. Haskell people in general are always pretty good at > accepting criticism IME (they tend to want to fix the problem), that criticism??? cows can't fly, and ghc cannot beat gcc in 2 months. that bothers me is people that attack me just for comparing compilers head-to-head -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: speed: ghc vs gcc
Peter Verswyvelen wrote: > nothing should stop you from writing video games in Haskell > Show me a studio that uses Haskell and I'd even accept dollars or pounds as payment. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[4]: [Haskell-cafe] Re: speed: ghc vs gcc
On Fri, Feb 20, 2009 at 11:51:43PM +0100, Thomas Davie wrote: >> of course. what fool will say that ghc cannot be optimized the same >> way as gcc? if we spent the same amount of time for improving ghc >> back-end as was spent for gcc (tens or hundreds man-years?), then >> *low-level* Haskell code will become as fast as C one, while remaining >> several times slower to write > > Considering Haskell compilers have lots more guarenteed conditions to go > on (like referential transparency etc), I'd imagine actually that given > the same amount of effort, they could compile Haskell code to *much* > faster code than C. Indeed. This is my thesis and jhc is my constructive proof (in progress) of said thesis. :) John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[6]: [Haskell-cafe] Re: speed: ghc vs gcc
Now perhaps I'll be stepping into some lines of fire as it seems like this thread is full of them. If I get in anyone's way please kindly hold your shot ;-) That said, video codecs are the kinds of things that usually benefit greatly from vectorization and parallelization right? These are two areas that have been getting concentration recently. I'm not really familiar with all the codecs involved, but it would probably be a great test case if someone could write a video codec (perhaps not H.264 since I recall someone saying it was ridiculously complicated) in C/C++ and in Haskell using all the DPH/parallelization tricks, as a comparison benchmark to improve the performance of the compiled code coming out of GHC. Having two pieces of code that are decently optimized and should do the same thing seems like it would make finding snags in the GHC performance and fixing them that much easier. Also, hunting with your bare hands rather than with a gun is provably more bad-ass ;-) -Ross On Feb 20, 2009, at 6:52 PM, Bulat Ziganshin wrote: Hello Peter, Saturday, February 21, 2009, 2:36:15 AM, you wrote: nothing should stop you from writing video games in Haskell since video codec isn't video game :))) but I've worked with people that wrote physics engines in C/C++, and they also had to hand optimize specifically for a certain compiler to get things fast. that's important signal. if you need to hand-optimize your code even if you use icl to compile it, using haskell will be like hunting with a hand instead of gun -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[4]: [Haskell-cafe] Re: speed: ghc vs gcc
Turning this into a ticket with associated test will: but why you think that this is untypical and needs a ticket? ;) Because generally ghc is doing a good-enough job. And it is doing that because long ago, ghc hq's war cry was "if ghc generates code that is slower than any other haskell implementation, it is a bug, and you should file a ticket". The failure of "avoid success at all cost" has meant shifting priorities, and those priorities tend to imply that alternative implementations can't keep up (not over the full range of ghc's offerings). So there is less "internal" competition, more "other stuff" on todo lists, and good enough just has to be good enough most of the time. But when it isn't, then not just people at ghc hq are still listening. And among all the other good stuff they keep adding, they also keep tweaking ghc's basics, in such a way that what would be hard to do now, may be easier to implement in future ghc versions. And for that, they need input about what they should focus on. And the advertised way of providing that input is the ticket tracker. For tickets, small examples are great - they often highlight aspects that are still present in real code, but are hard to see there (let alone reducing complex code to small test cases that help to fix those cases). In the particular example of unrolling, iirc, the issue was that ghc's internal representation does not easily lend itself to adding some counter that would keep the very modular optimizer from applying recursive unfoldings uselessly. Once that fundamental problem is fixed, I am optimistic that this useful optimization will be looked at again - if there is a ticket to remind everyone. And if -as I suspect- lots of ghc users find themselves doing loop unrolling/partial recursion unfoldings by hand (worker/wrapper for recursive functions is just such an example), they will up the priority on that ticket. You're right that ghc hq can't be everywhere, but they aren't the only ones who are invited to look at those tickets. And everytime someone starts on ghc hacking for some unrelated purpose, they need a small project to start on - well-defined tickets have a chance there. I'm not at all happy with Haskell optimists turning evangelists, but neither is it productive for Haskell pessimists to spread their frustration. There are useful ways for both sides to contribute to the Haskell world, can we focus on those ways? Claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[6]: [Haskell-cafe] Re: speed: ghc vs gcc
Hello Peter, Saturday, February 21, 2009, 2:36:15 AM, you wrote: > nothing should stop you from writing video games in Haskell since video codec isn't video game :))) > but I've worked with people that wrote physics engines in C/C++, > and they also had to hand optimize specifically for a certain compiler to get > things fast. that's important signal. if you need to hand-optimize your code even if you use icl to compile it, using haskell will be like hunting with a hand instead of gun -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: speed: ghc vs gcc
On Fri, Feb 20, 2009 at 10:33 PM, Bulat Ziganshin wrote: > Hello Achim, > > Saturday, February 21, 2009, 1:17:08 AM, you wrote: > > >> nothing new: what you are not interested in real compilers comparison, > >> preferring to demonstrate artificial results > >> > > ...that we have a path to get better results than gcc -O3 > > -funroll-loops, and it's within reach... we even can get there now, > > albeit not in the most hack-free way imaginable? > > well, can this be made for C++? yes. moreover, gcc does this trick > *automatically*, while with ghc we need to write 50-line program using > Template Haskell and then run it through gcc - and finally get exactly > the same optimization we got automatic for C code > > so, again: this confirms that Don is always build artificial > comparisons, optimizing Haskell code by hand and ignoring obvious ways > to optimize Haskell code. unfortunately, this doesn't work in real > live. and even worse - Don reports this as fair Haskell vs C++ > comparison > Bulat, please, you're missing the point. Nobody is saying that the template-haskell trick was somehow a viable general strategy right now that everyone should use by default. It was used as a proof-of-concept that a simple technique can lead to massive performance improvements - and we get numbers for how massive it would be (beating gcc for this benchmark). This isn't about "faking" a benchmark, it's about investigating the reasons for why the benchmark looks they way it does, doing testing to verify the assumptions (in this case using TH), and making constructive suggestions (add loop-unrolling to the compiler). This investigation tells us that in this case a compiler could beat gcc, if only it were to do loop unrolling in the way the TH code does. That's a result! I would ask you to note the simple fact that every single constructive message in this thread has come from people other than you. I hope this leads you reconsider your tone and general approach in the future. Haskell people in general are always pretty good at accepting criticism IME (they tend to want to fix the problem), don't you think it's odd that it's only *your* criticism that gets so much flak? Maybe some part of the reason almost every discussion you're in here usually ends up hostile is *your* approach? Regards, -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: speed: ghc vs gcc
Khudyakov Alexey wrote: > On Friday 20 February 2009 16:29:29 Bulat Ziganshin wrote: > > Hello haskell-cafe, > > > > since there are no objective tests comparing ghc to gcc, i made my > > own one. these are 3 programs, calculating sum in c++ and haskell: > > > > main = print $ sum[1..10^9::Int] > > > > ... skipped ... > > The discussion is mostly about low level optimizations such as loop > unrolling etc. > > I have another question. Why shouldn't compiler realize that `sum > [1..10^9]' is constant and thus evaluate it at compile time? > +1. There's a lot that can be done in this area, even without complete information (though I wouldn't mind Haskell being total and dependently typed...), if you hack around unsafePerformIO. There's a good reason the language shootout passes such things as arguments to the program, but not getting faster there doesn't mean that it doesn't make sense to aggressively compile-time evaluate... or automagically memoise, or do any of those other optimisations gcc can only dream of. On the "why"-question... lacking manpower, and, possibly, line count not having enough weight in the shootout. For now, you can just use TH to force things getting evaluated. (Try to do that in C) -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[4]: [Haskell-cafe] Re: speed: ghc vs gcc
nothing should stop you from writing video games in Haskell since the control logic of many video games is written in e.g. a scripting language like LUA :-) sure if you want to write a physics engine in Haskell, that's something else. but I've worked with people that wrote physics engines in C/C++, and they also had to hand optimize specifically for a certain compiler to get things fast. so some manual tweaking to Haskell could be acceptable if you want to get high performance. and I hope that in the future the Haskell compilers will optimize more and more and more... 2009/2/20 Bulat Ziganshin > Hello Thomas, > > Saturday, February 21, 2009, 1:19:47 AM, you wrote: > > > I'm not sure what you're getting at Bulat √ it's been demonstrated > > that ghc is slower than gcc for most cases at the moment (many > > benchmarks will back this up), *however*, it's also easily verified > > that ghc has had significantly less effort directed at it than gcc and > > other imperative compilers, thus, there are many places it can improve > > greatly. > > of course. what fool will say that ghc cannot be optimized the same > way as gcc? if we spent the same amount of time for improving ghc > back-end as was spent for gcc (tens or hundreds man-years?), then > *low-level* Haskell code will become as fast as C one, while remaining > several times slower to write > > > In this case, you've pointed out a really great source of heavy > > optimisation. Thanks a lot :) Now perhaps it might be an idea to be > > constructive, rather than trying to stand like nelson going "HA HA" at > > the people with the inferior compiler. > > ghc is superior compiler and it's my main instrument. but it can't > make coffee and doesn't contain sophisticated code generator. it's why > i dissuade from writing video codes in haskell and i don't like > situation when someone too lazy to test speed yourself tell us tales > and attack me when i say about real situation > > > -- > Best regards, > Bulatmailto:bulat.zigans...@gmail.com > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: speed: ghc vs gcc
Bulat Ziganshin wrote: > but problem - not mine, but for haskellers, is that some people said > that ghc can generate code that is as fast as gcc one. it will be > stupid if someone will start to write say mpeg4 codec and after year > of work will find that it need 100 Ghz cpu to work. it's why i made > this test, which you are trying to fool now. people that will believe > your "arguments" instead of checking numbers may spend a lot of time > meaningless. but it's doesn't matter for you, fanatics > /me takes a breath Well, _if_ I was going to write a mpeg4 codec, I'd be starting of in Haskell, anyway, to get to terms with the algorithm. After being satisfied, in terms of quality and big-O, I'd start investigating how to do it as fast as possible. Most likely, that would include serious amounts of C. In any case, I could point out non-perfect optimisation to the ghc devs. Out of those devs, someone will know why the current optimisations don't work for that case. As soon as the devs know why it doesn't work, chances are that someone else does, or, at least, is curious enough. I certainly don't know jack about the latter topics, I only know that _my_ code doesn't work as it would, were the world perfect. From that, I can infer with certainty that I don't know jack about how long it would take the ghc devs to enable me to replace C with the original Haskell. I only know that, most likely, I couldn't do it faster. Therefore, I just take the chance, open a ticket, and see what happens. After all, if I _don't_ open a ticket, chances that it gets fixed are lower, if not non-existent. Doing all this, I couldn't care less about what you or Don say. One says that you can't have fast Haskell, the other one says that you can, the first one says that yes, in that case, but not in that, the second continues saying well but if you do that, then the first one goes but that doesn't count... I don't care: Both are right, from their own perspectives. If you make predictions on how people are going to interpret something someone says, you're bound to be mistaken. You won't make me believe that ghc can't produce fast code, and Don won't convince me that I will be able to, in every case. What'll make me happy, right now, isn't random test cases, but a test framework that lets us all reproduce each other's experiments in a controlled -- and thus numerically comparable without discussion -- environment. The current state of things leaks information, and isn't able to catch possible regressions, at all. Still, I could not care less about ghc's performance, right now: I'm much more concerned with high-level stuff, right now. What I _do_ know, is that all the results, collected in this thread, won't mean a thing the instant we get another ghc release, and that noone will be able to update the results without wading through flames, again. So, here's my advice: If you care about performance and best-possible communication of its state to the community, set up a page, in the spirit of the language shootout, that compares haskell compilers vs. chosen c and fortran compilers, in a variety of cases. Did I mention that we need automated benchmark comparisons? -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: speed: ghc vs gcc
Hello Don, Saturday, February 21, 2009, 1:55:19 AM, you wrote: > This is extremely depressing to read after the good results and lessons of > this thread. you misunderstand, it is not personal! We just want something to sarcasm on. Something specific. -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[4]: [Haskell-cafe] Re: speed: ghc vs gcc
Hello Thomas, Saturday, February 21, 2009, 1:55:33 AM, you wrote: >> most of these tests depends on libraries speed. in one test, PHP is >> 1st. from 2 or 3 tests that depends on compiler speed, one was fooled >> by adding special function readInt to ghc libs and the rest are >> written in low-level haskell code - look the sources > Shock news – benchmarks lead to compiler and library optimisations. read carefully - it was not general-purpose optimization, Don just added function readInt since Haskell read is very slow. if he was optimized general read so many applications will benefit from this - it would be great but if you want to believe that ghc was optimised in the way that avery program becomes 50x faster - i can't stop you :D >> i'm sorry, but this test only shows amount of work spent to optimize >> these programs. results of some tests was made 10-100 times better, >> while improving real programs performance needs much more work :) > I don't get your point at all. Are you implying that none of the code > for any of the other languages up there is optimized in any way? code for other languages usually written in idiomatic way. it was local Haskell epidemy. you may compare mandelbrot sources in C and Haskell -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: speed: ghc vs gcc
On 21 Feb 2009, at 00:10, Ahn, Ki Yung wrote: Thomas Davie wrote: You need look no further than the debian language shootout that things really aren't as bad as you're making out – Haskell comes in in general less than 3x slower than gcc compiled C. Of note, of all the managed languages, this is about the fastest – none of the other languages that offer safety and garbage collection etc get as close as Haskell does. Bob OCaml and Clean seems to be pretty fast too. Very true :). As does C#, but using MS's compiler not mono. I think my conclusion from this thread is "stop arguing, someone being wrong on the internet is not worth it", oh and "cool, new possibly major optimisation for ghc". And finally, something I'd known all along – Haskell is plenty fast enough for writing real world programs, it's not as fast as C, but I don't care – I write so much better code so much faster in it that the tradeoff becomes worth it. Sorry for getting into the slagging match so much, and count me out of this one from now on. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: speed: ghc vs gcc
Thomas Davie wrote: You need look no further than the debian language shootout that things really aren't as bad as you're making out – Haskell comes in in general less than 3x slower than gcc compiled C. Of note, of all the managed languages, this is about the fastest – none of the other languages that offer safety and garbage collection etc get as close as Haskell does. Bob OCaml and Clean seems to be pretty fast too. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: speed: ghc vs gcc
bulat.ziganshin: > Hello Achim, > > Saturday, February 21, 2009, 1:17:08 AM, you wrote: > > >> nothing new: what you are not interested in real compilers comparison, > >> preferring to demonstrate artificial results > >> > > ...that we have a path to get better results than gcc -O3 > > -funroll-loops, and it's within reach... we even can get there now, > > albeit not in the most hack-free way imaginable? > > well, can this be made for C++? yes. moreover, gcc does this trick > *automatically*, while with ghc we need to write 50-line program using > Template Haskell and then run it through gcc - and finally get exactly > the same optimization we got automatic for C code > > so, again: this confirms that Don is always build artificial > comparisons, optimizing Haskell code by hand and ignoring obvious ways > to optimize Haskell code. unfortunately, this doesn't work in real > live. and even worse - Don reports this as fair Haskell vs C++ > comparison This is extremely depressing to read after the good results and lessons of this thread. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: speed: ghc vs gcc
Hello Thomas, Saturday, February 21, 2009, 1:41:24 AM, you wrote: >> so, again: this confirms that Don is always build artificial >> comparisons, optimizing Haskell code by hand and ignoring obvious ways > You need look no further than the debian language shootout that things and yes - this is the most well-known example of fooled comparison. just ask Don how much time haskell community spent rewriting this code -- 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[2]: [Haskell-cafe] Re: speed: ghc vs gcc
On 20 Feb 2009, at 23:52, Bulat Ziganshin wrote: Hello Thomas, Saturday, February 21, 2009, 1:41:24 AM, you wrote: You need look no further than the debian language shootout that things really aren't as bad as you're making out √ Haskell comes in in general less than 3x slower than gcc compiled C. you should look inside these tests, as i done :) most of these tests depends on libraries speed. in one test, PHP is 1st. from 2 or 3 tests that depends on compiler speed, one was fooled by adding special function readInt to ghc libs and the rest are written in low-level haskell code - look the sources Shock news – benchmarks lead to compiler and library optimisations. News at 11! Of note, of all the managed languages, this is about the fastest √ none of the other languages that offer safety and garbage collection etc get as close as Haskell does. i'm sorry, but this test only shows amount of work spent to optimize these programs. results of some tests was made 10-100 times better, while improving real programs performance needs much more work :) I don't get your point at all. Are you implying that none of the code for any of the other languages up there is optimized in any way? Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[4]: [Haskell-cafe] Re: speed: ghc vs gcc
2009/2/20 Bulat Ziganshin : > Hello Thomas, > > Saturday, February 21, 2009, 1:19:47 AM, you wrote: > >> I'm not sure what you're getting at Bulat √ it's been demonstrated >> that ghc is slower than gcc for most cases at the moment (many >> benchmarks will back this up), *however*, it's also easily verified >> that ghc has had significantly less effort directed at it than gcc and >> other imperative compilers, thus, there are many places it can improve >> greatly. > > of course. what fool will say that ghc cannot be optimized the same > way as gcc? if we spent the same amount of time for improving ghc > back-end as was spent for gcc (tens or hundreds man-years?), then > *low-level* Haskell code will become as fast as C one, while remaining > several times slower to write > >> In this case, you've pointed out a really great source of heavy >> optimisation. Thanks a lot :) Now perhaps it might be an idea to be >> constructive, rather than trying to stand like nelson going "HA HA" at >> the people with the inferior compiler. > > ghc is superior compiler and it's my main instrument. but it can't > make coffee and doesn't contain sophisticated code generator. it's why > i dissuade from writing video codes in haskell and i don't like > situation when someone too lazy to test speed yourself tell us tales > and attack me when i say about real situation Please people, I found the ghc/ghc+D64/jhc/gcc/ comparison awesome to read; but find quite distracting to have all those 'other' comments. I guess everyone knows quite clearly what others have in mind and where they stand. Maybe it is not necessary to repeat those things every time ? And more specifically, is it necessary to get some inflamatory tone ? Thanks to share knowledge and haskell love ! Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: speed: ghc vs gcc
Hello Thomas, Saturday, February 21, 2009, 1:41:24 AM, you wrote: > You need look no further than the debian language shootout that things > really aren't as bad as you're making out √ Haskell comes in in > general less than 3x slower than gcc compiled C. you should look inside these tests, as i done :) most of these tests depends on libraries speed. in one test, PHP is 1st. from 2 or 3 tests that depends on compiler speed, one was fooled by adding special function readInt to ghc libs and the rest are written in low-level haskell code - look the sources > Of note, of all the managed languages, this is about the fastest √ > none of the other languages that offer safety and garbage collection > etc get as close as Haskell does. i'm sorry, but this test only shows amount of work spent to optimize these programs. results of some tests was made 10-100 times better, while improving real programs performance needs much more work :) -- 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[4]: [Haskell-cafe] Re: speed: ghc vs gcc
On 20 Feb 2009, at 23:41, Bulat Ziganshin wrote: Hello Thomas, Saturday, February 21, 2009, 1:19:47 AM, you wrote: I'm not sure what you're getting at Bulat √ it's been demonstrated that ghc is slower than gcc for most cases at the moment (many benchmarks will back this up), *however*, it's also easily verified that ghc has had significantly less effort directed at it than gcc and other imperative compilers, thus, there are many places it can improve greatly. of course. what fool will say that ghc cannot be optimized the same way as gcc? if we spent the same amount of time for improving ghc back-end as was spent for gcc (tens or hundreds man-years?), then *low-level* Haskell code will become as fast as C one, while remaining several times slower to write Considering Haskell compilers have lots more guarenteed conditions to go on (like referential transparency etc), I'd imagine actually that given the same amount of effort, they could compile Haskell code to *much* faster code than C. In this case, you've pointed out a really great source of heavy optimisation. Thanks a lot :) Now perhaps it might be an idea to be constructive, rather than trying to stand like nelson going "HA HA" at the people with the inferior compiler. ghc is superior compiler and it's my main instrument. but it can't make coffee and doesn't contain sophisticated code generator. it's why i dissuade from writing video codes in haskell and i don't like situation when someone too lazy to test speed yourself tell us tales and attack me when i say about real situation I'd hardly say that dons is too lazy – he has after all contributed rather large chunks of code to coming up with good examples, and optimising ghc. Secondly, I don't see him telling tales either – he's being very honest about the performance of Haskell here, and how it might be improved. Finally, I'd hardly call computing a constant in an arbitrarily complex way a "real situation". I think someone needs to get off their high horse and reflect a little. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[4]: [Haskell-cafe] Re: speed: ghc vs gcc
Hello Thomas, Saturday, February 21, 2009, 1:19:47 AM, you wrote: > I'm not sure what you're getting at Bulat √ it's been demonstrated > that ghc is slower than gcc for most cases at the moment (many > benchmarks will back this up), *however*, it's also easily verified > that ghc has had significantly less effort directed at it than gcc and > other imperative compilers, thus, there are many places it can improve > greatly. of course. what fool will say that ghc cannot be optimized the same way as gcc? if we spent the same amount of time for improving ghc back-end as was spent for gcc (tens or hundreds man-years?), then *low-level* Haskell code will become as fast as C one, while remaining several times slower to write > In this case, you've pointed out a really great source of heavy > optimisation. Thanks a lot :) Now perhaps it might be an idea to be > constructive, rather than trying to stand like nelson going "HA HA" at > the people with the inferior compiler. ghc is superior compiler and it's my main instrument. but it can't make coffee and doesn't contain sophisticated code generator. it's why i dissuade from writing video codes in haskell and i don't like situation when someone too lazy to test speed yourself tell us tales and attack me when i say about real situation -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: speed: ghc vs gcc
On 20 Feb 2009, at 23:33, Bulat Ziganshin wrote: Hello Achim, Saturday, February 21, 2009, 1:17:08 AM, you wrote: nothing new: what you are not interested in real compilers comparison, preferring to demonstrate artificial results ...that we have a path to get better results than gcc -O3 -funroll-loops, and it's within reach... we even can get there now, albeit not in the most hack-free way imaginable? well, can this be made for C++? yes. moreover, gcc does this trick *automatically*, while with ghc we need to write 50-line program using Template Haskell and then run it through gcc - and finally get exactly the same optimization we got automatic for C code so, again: this confirms that Don is always build artificial comparisons, optimizing Haskell code by hand and ignoring obvious ways to optimize Haskell code. unfortunately, this doesn't work in real live. and even worse - Don reports this as fair Haskell vs C++ comparison You need look no further than the debian language shootout that things really aren't as bad as you're making out – Haskell comes in in general less than 3x slower than gcc compiled C. Of note, of all the managed languages, this is about the fastest – none of the other languages that offer safety and garbage collection etc get as close as Haskell does. Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: speed: ghc vs gcc
Hello Achim, Saturday, February 21, 2009, 1:17:08 AM, you wrote: >> nothing new: what you are not interested in real compilers comparison, >> preferring to demonstrate artificial results >> > ...that we have a path to get better results than gcc -O3 > -funroll-loops, and it's within reach... we even can get there now, > albeit not in the most hack-free way imaginable? well, can this be made for C++? yes. moreover, gcc does this trick *automatically*, while with ghc we need to write 50-line program using Template Haskell and then run it through gcc - and finally get exactly the same optimization we got automatic for C code so, again: this confirms that Don is always build artificial comparisons, optimizing Haskell code by hand and ignoring obvious ways to optimize Haskell code. unfortunately, this doesn't work in real live. and even worse - Don reports this as fair Haskell vs C++ comparison -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: speed: ghc vs gcc
Hello Achim, Saturday, February 21, 2009, 12:54:33 AM, you wrote: >> so - why YOU think that ghc >> generates fast code and this example is something unusual? >> > I think ghc has decent performance, and that there's room for > improvement. I don't care whether you compare it to gcc, i'm asking specifically about ghc vs gcc performance. what i'm said is that ghc generates slow code compared to gcc, if you don't agree with me - why you think opposite? are these reasons technical, i.e. some numbers or not? > if there's any way to have faster code than you get with ghc, right > now, it's worth a bug report, even if it's going to be tagged as > Milestone: ghc 120.10. Non-tracked issues are non-issues. again, this looks strange. does you mean that every program you analyzed on assembler level has perfect code? or that you just don't need any more speed? i personally checked ghc performance 3 years ago and wrote decent s/w those days. i think that library i wrote was the first with hard low-level optimization and may be becomes an inspiration for ByteString optimizations nevertheless, ghc cannot generate really fast code and when i need speed, i use C++. my archiver is known as world fastest one and it's written in C++ and Haskell combination - C++ where we need speed, Haskell for the rest: i'm sure that it's the best combination until ghc 120.1 next, imagine that you live 20 years ago. you wrote in C and finds that gcc generates slower code than hand-written assembler. you report it - are you think that next day gcc will become as fast as assembler? gcc, like other best C++ compilers, spend many man-years before it got the current speed. ghc back-end developed by just Simon Marlow, and he cannot write gcc-like backend in less than 120 years, with reports or without next, the program i wrote is very primitive. are you really think that Simon can't build a lot of such examples without my help? it's why i consider your idea meaningless and more like an personal attack than real concern about ghc actually, me, like probably you, are not interested so much in better ghc optimizing backend. it's enough fast for my tasks, i use C++ for speed-critical code. i prefer that Simon will improve other sides of backend but problem - not mine, but for haskellers, is that some people said that ghc can generate code that is as fast as gcc one. it will be stupid if someone will start to write say mpeg4 codec and after year of work will find that it need 100 Ghz cpu to work. it's why i made this test, which you are trying to fool now. people that will believe your "arguments" instead of checking numbers may spend a lot of time meaningless. but it's doesn't matter for you, fanatics -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: speed: ghc vs gcc
Bulat Ziganshin wrote: > Hello Don, > > Saturday, February 21, 2009, 12:43:46 AM, you wrote: > > > gcc -O3 -funroll-loops 0.318 > > ghc "-funroll-loops" -D64 0.088 > > > So what did we learn here? > > nothing new: what you are not interested in real compilers comparison, > preferring to demonstrate artificial results > > ...that we have a path to get better results than gcc -O3 -funroll-loops, and it's within reach... we even can get there now, albeit not in the most hack-free way imaginable? -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Re: speed: ghc vs gcc
On 20 Feb 2009, at 22:57, Bulat Ziganshin wrote: Hello Don, Saturday, February 21, 2009, 12:43:46 AM, you wrote: gcc -O3 -funroll-loops 0.318 ghc "-funroll-loops" -D64 0.088 So what did we learn here? nothing new: what you are not interested in real compilers comparison, preferring to demonstrate artificial results I'm not sure what you're getting at Bulat – it's been demonstrated that ghc is slower than gcc for most cases at the moment (many benchmarks will back this up), *however*, it's also easily verified that ghc has had significantly less effort directed at it than gcc and other imperative compilers, thus, there are many places it can improve greatly. In this case, you've pointed out a really great source of heavy optimisation. Thanks a lot :) Now perhaps it might be an idea to be constructive, rather than trying to stand like nelson going "HA HA" at the people with the inferior compiler. ;) Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: speed: ghc vs gcc
"Bryan O'Sullivan" wrote: > On Fri, Feb 20, 2009 at 12:44 PM, Achim Schneider > wrote: > > > > Bulat, you are right in every aspect. You never did anything wrong. > > Back when you debugged your code all night long, you were only > > dreaming. > > > Achim, this doesn't seem like a constructive way to respond. Bulat's > already been taken to task repeatedly for the manner in which he > carries on, but being sarcastic in response doesn't help anyone, and > serves only to lower the tone of the mailing list. > > Please keep things polite. > I don't do sarcasm, and I don't attack persons. I was merely pointing out the impressions his bug-reports give to the devs (there isn't anything wrong), and asked him whether there's something strange with that notion. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: speed: ghc vs gcc
Hello Manlio, Saturday, February 21, 2009, 12:54:00 AM, you wrote: >> ghc -O2 naive left fold15.680 > As a full comparison I would like to see time for > ghc -O0 naive left fold he is still waiting :))) but that's really has only theoretical interest, comparing ghc -O2 on low-level haskell code to gcc -O0 has more meaning since ghc has no serious low-level optimizer so these results should be close -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: speed: ghc vs gcc
Hello Don, Saturday, February 21, 2009, 12:43:46 AM, you wrote: > gcc -O3 -funroll-loops 0.318 > ghc "-funroll-loops" -D64 0.088 > So what did we learn here? nothing new: what you are not interested in real compilers comparison, preferring to demonstrate artificial results -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: speed: ghc vs gcc
Bulat Ziganshin wrote: > so - why YOU think that ghc > generates fast code and this example is something unusual? > I think ghc has decent performance, and that there's room for improvement. I don't care whether you compare it to gcc, malbolge, or hand-written assembly, what matters isn't whether something is unusual, it is that look below vv if there's any way to have faster code than you get with ghc, right now, it's worth a bug report, even if it's going to be tagged as Milestone: ghc 120.10. Non-tracked issues are non-issues. ^^ look above Disk space is cheap, nowadays, and we can't have Simon's backlog run empty. Anything could happen. BTW: If you think I was being sarcastic in my last post, you are mistaken. The message is much simpler. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: speed: ghc vs gcc
Don Stewart ha scritto: dons: bulat.ziganshin: Hello Achim, Friday, February 20, 2009, 11:44:49 PM, you wrote: Turning this into a ticket with associated test will: but why you think that this is untypical and needs a ticket? ;) Bulat, you are right in every aspect. You never did anything wrong. Achim, this is simplest code one can imagine. so when Simon will go to check ghc optimizations, he will try it without any reports. but Simon, unlike Don, never said that ghc may be compared to gcc. Don, on the other hand, say this everyday. when he is asked for code that shows this, he declined to answer. so - why YOU think that ghc generates fast code and this example is something unusual? can you provide any *technical* arguments or will continue to make personal attacks together with Don? Bulat, you misunderstand, it is not personal! We just want something to work on. Something specific. For example, you've identified loop unrolling as something that could very profitably be improved in GHC, and Claus even wrote a prototype to see what kind of speedups to guess. This is a great contribution! Now we know where to hunt. And just to summarise what we have seen: ghc -O2 naive left fold15.680 gcc -O0 4.500 ghc manual recursion -fasm 1.328 ghc manual recursion1.035 ghc naive left fold "stream fusion" 0.967 gcc -O1 0.892 ghc "-funroll-loops" -D80.623 gcc -O3 -funroll-loops 0.318 ghc "-funroll-loops" -D64 0.088 As a full comparison I would like to see time for ghc -O0 naive left fold Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: speed: ghc vs gcc
On Fri, Feb 20, 2009 at 12:44 PM, Achim Schneider wrote: > Bulat, you are right in every aspect. You never did anything wrong. > Back when you debugged your code all night long, you were only > dreaming. Achim, this doesn't seem like a constructive way to respond. Bulat's already been taken to task repeatedly for the manner in which he carries on, but being sarcastic in response doesn't help anyone, and serves only to lower the tone of the mailing list. Please keep things polite. Thanks, Bryan. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: speed: ghc vs gcc
dons: > bulat.ziganshin: > > Hello Achim, > > > > Friday, February 20, 2009, 11:44:49 PM, you wrote: > > > > >> > Turning this into a ticket with associated test will: > > >> > > >> but why you think that this is untypical and needs a ticket? ;) > > >> > > > Bulat, you are right in every aspect. You never did anything wrong. > > > > Achim, this is simplest code one can imagine. so when Simon will go to > > check ghc optimizations, he will try it without any reports. but > > Simon, unlike Don, never said that ghc may be compared to gcc. Don, on > > the other hand, say this everyday. when he is asked for code that > > shows this, he declined to answer. so - why YOU think that ghc > > generates fast code and this example is something unusual? can you > > provide any *technical* arguments or will continue to make personal > > attacks together with Don? > > Bulat, you misunderstand, it is not personal! We just want something to > work on. Something specific. > > For example, you've identified loop unrolling as something that could > very profitably be improved in GHC, and Claus even wrote a prototype to > see what kind of speedups to guess. > > This is a great contribution! Now we know where to hunt. And just to summarise what we have seen: ghc -O2 naive left fold15.680 gcc -O0 4.500 ghc manual recursion -fasm 1.328 ghc manual recursion1.035 ghc naive left fold "stream fusion" 0.967 gcc -O1 0.892 ghc "-funroll-loops" -D80.623 gcc -O3 -funroll-loops 0.318 ghc "-funroll-loops" -D64 0.088 So what did we learn here? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: speed: ghc vs gcc
bulat.ziganshin: > Hello Achim, > > Friday, February 20, 2009, 11:44:49 PM, you wrote: > > >> > Turning this into a ticket with associated test will: > >> > >> but why you think that this is untypical and needs a ticket? ;) > >> > > Bulat, you are right in every aspect. You never did anything wrong. > > Achim, this is simplest code one can imagine. so when Simon will go to > check ghc optimizations, he will try it without any reports. but > Simon, unlike Don, never said that ghc may be compared to gcc. Don, on > the other hand, say this everyday. when he is asked for code that > shows this, he declined to answer. so - why YOU think that ghc > generates fast code and this example is something unusual? can you > provide any *technical* arguments or will continue to make personal > attacks together with Don? Bulat, you misunderstand, it is not personal! We just want something to work on. Something specific. For example, you've identified loop unrolling as something that could very profitably be improved in GHC, and Claus even wrote a prototype to see what kind of speedups to guess. This is a great contribution! Now we know where to hunt. -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: speed: ghc vs gcc
Hello Achim, Friday, February 20, 2009, 11:44:49 PM, you wrote: >> > Turning this into a ticket with associated test will: >> >> but why you think that this is untypical and needs a ticket? ;) >> > Bulat, you are right in every aspect. You never did anything wrong. Achim, this is simplest code one can imagine. so when Simon will go to check ghc optimizations, he will try it without any reports. but Simon, unlike Don, never said that ghc may be compared to gcc. Don, on the other hand, say this everyday. when he is asked for code that shows this, he declined to answer. so - why YOU think that ghc generates fast code and this example is something unusual? can you provide any *technical* arguments or will continue to make personal attacks together with Don? -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: speed: ghc vs gcc
claus.reinke:
> Concrete examples always help, thanks.
>
> In simple enough situations, one can roll one's own loop unrolling;),
> somewhat like shown below (worker/wrapper split to bring the function
> parameter representing the loop body into scope, then template haskell
> to unroll its applications syntactically, then optimization by
> transformation
> to get rid of the extra code). It is all rather more complicated than one
> would like it to be, what with TH scoping restrictions and all, but
> perhaps a library of self-unrolling loop combinators along these lines
> might help, as a workaround until ghc does its own unrolling.
>
> Claus
>
> {-# LANGUAGE TemplateHaskell #-}
> module Apply where
> import Language.Haskell.TH.Syntax
> apply i bound | i $(apply (i+1) bound) f (f i x) |]
> | otherwise = [| \f x -> x |]
>
> {-# LANGUAGE CPP #-}
> {-# LANGUAGE TemplateHaskell #-}
> {-# LANGUAGE BangPatterns #-}
> {-# OPTIONS_GHC -DN=8 -ddump-splices #-}
> module Main(main) where
> import Apply
> main = print $ loopW 1 (10^9) body 0
>
> {-# INLINE loopW #-}
> loopW :: Int -> Int -> (Int -> Int -> Int) -> Int -> Int
> loopW i max body acc = loop i acc
> where
> loop :: Int -> Int -> Int
> loop !i !acc | i+N<=max = loop (i+N) ($(apply (0::Int) N) (\j acc->body
> (i+j) acc) acc)
> {-
> loop !i !acc | i+8<=max = loop (i+8) ( body (i+7)
>$ body (i+6)
>$ body (i+5)
>$ body (i+4)
>$ body (i+3)
>$ body (i+2)
>$ body (i+1)
>$ body i acc)
> -}
> loop !i !acc | i<=max= loop (i+1) (body i acc)
> | otherwise = acc
>
> body :: Int -> Int -> Int
> body !i !acc = i+acc
>
Great thinking! This is EXTREMELY COOL!
Main.hs:15:42-57: Splicing expression
let
apply = apply
$dOrd = GHC.Base.$f1
$dNum = GHC.Num.$f6
$dLift = Language.Haskell.TH.Syntax.$f18
in apply (0 :: Int) 8
==>
\ f[a1KU] x[a1KV]
-> \ f[a1KW] x[a1KX]
-> \ f[a1KY] x[a1KZ]
-> \ f[a1L0] x[a1L1]
-> \ f[a1L2] x[a1L3]
-> \ f[a1L4] x[a1L5]
-> \ f[a1L6] x[a1L7]
-> \ f[a1L8] x[a1L9]
-> \ f[a1La]
x[a1Lb] -> x[a1Lb]
f[a1L8]
(f[a1L8] 7 x[a1L9])
f[a1L6] (f[a1L6]
6 x[a1L7])
f[a1L4] (f[a1L4] 5
x[a1L5])
f[a1L2] (f[a1L2] 4 x[a1L3])
f[a1L0] (f[a1L0] 3 x[a1L1])
f[a1KY] (f[a1KY] 2 x[a1KZ])
f[a1KW] (f[a1KW] 1 x[a1KX])
f[a1KU] (f[a1KU] 0 x[a1KV])
In the second argument of `loop', namely
`($(apply (0 :: Int) 8) (\ j acc -> body (i + j) acc) acc)'
In the expression:
loop
(i + 8) ($(apply (0 :: Int) 8) (\ j acc -> body (i + j) acc) acc)
In the definition of `loop':
loop !i !acc
| i + 8 <= max
= loop
(i + 8) ($(apply (0 :: Int) 8) (\ j acc -> body (i + j)
acc) acc)
So, that's the fastest yet:
$ time ./Main
55
./Main 0.61s user 0.00s system 98% cpu 0.623 total
And within 2x the best GCC was doing,
gcc -O3 -funroll-loops 0.318
If we unroll even further...
$ ghc -O2 -fvia-C -optc-O3 -D64 Main.hs
$ time ./Main
55
./Main 0.08s user 0.00s system 94% cpu 0.088 total
Very very nice, Claus!
Now I'm wondering if we can do this via rewrite rules
-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: speed: ghc vs gcc
Bulat Ziganshin wrote: > Hello Claus, > > Friday, February 20, 2009, 11:15:59 PM, you wrote: > > > Turning this into a ticket with associated test will: > > but why you think that this is untypical and needs a ticket? ;) > Bulat, you are right in every aspect. You never did anything wrong. Back when you debugged your code all night long, you were only dreaming. It ran perfectly from the very beginning. Your every utterance is Truth as well as every line of your code breathes the Tao. Therefore, we are thankful and never tell you about things that you didn't mess up, overlooked, or ignored and later on plainly forgot, as you just don't do such things. Notice something strange? -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: speed: ghc vs gcc
Don Stewart wrote: > (The bang patterns aren't needed). Note how he counts backwards from > 10^9. Was there a reason for that, Bulat? > Tests against zero are faster, as you don't need a second operand... by now, some platforms might be smart enough, but down-counting in loops is still in my hard-wired optimisation generator, alongside with xor op, op to set op to zero, shifts instead of divides and similar no-brainers. Testing an Integer against 0 is certainly faster than testing it against 2^128^128. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[4]: [Haskell-cafe] Re: speed: ghc vs gcc
Hello Claus, Friday, February 20, 2009, 11:15:59 PM, you wrote: > Turning this into a ticket with associated test will: but why you think that this is untypical and needs a ticket? ;) -- 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[2]: [Haskell-cafe] Re: speed: ghc vs gcc
Concrete examples always help, thanks.
Turning this into a ticket with associated test will:
- enable others to find and repeat the test when this thread is long gone,
to see whether any other ghc changes have helped in any way
- enable documentation of what exactly the issue is (why is it slow?)
- enable others to vote for having this issue addressed
- help to keep the various performance issues separate (I seem to
recall that you and others had found some other infelicities in
ghc-generated code, and lots of other useful bits a pieces over
the years, not all of which have been resolved or made into tickets?)
Without ticket, such examples will be snowed under here in no
time. With ticket, it will take a little longer!-)
afaik, ghc can be compared with 20-years old C compilers. it uses
registers for performing tight loops but has very simple register
allocation procedure. also it doesn't unroll loops
I've occasionally run into situations where it would have been nice
to have loop unrolling, or more generally, partial unfolding of recursive
functions. But I've got the feeling that this isn't the whole story here,
or is it?
In simple enough situations, one can roll one's own loop unrolling;),
somewhat like shown below (worker/wrapper split to bring the function
parameter representing the loop body into scope, then template haskell
to unroll its applications syntactically, then optimization by transformation
to get rid of the extra code). It is all rather more complicated than one
would like it to be, what with TH scoping restrictions and all, but perhaps
a library of self-unrolling loop combinators along these lines might help, as
a workaround until ghc does its own unrolling.
Claus
{-# LANGUAGE TemplateHaskell #-}
module Apply where
import Language.Haskell.TH.Syntax
apply i bound | i $(apply (i+1) bound) f (f i x) |]
| otherwise = [| \f x -> x |]
{-# LANGUAGE CPP #-}
{-# LANGUAGE TemplateHaskell #-}
{-# LANGUAGE BangPatterns #-}
{-# OPTIONS_GHC -DN=8 -ddump-splices #-}
module Main(main) where
import Apply
main = print $ loopW 1 (10^9) body 0
{-# INLINE loopW #-}
loopW :: Int -> Int -> (Int -> Int -> Int) -> Int -> Int
loopW i max body acc = loop i acc
where
loop :: Int -> Int -> Int
loop !i !acc | i+N<=max = loop (i+N) ($(apply (0::Int) N) (\j acc->body (i+j)
acc) acc)
{-
loop !i !acc | i+8<=max = loop (i+8) ( body (i+7)
$ body (i+6)
$ body (i+5)
$ body (i+4)
$ body (i+3)
$ body (i+2)
$ body (i+1)
$ body i acc)
-}
loop !i !acc | i<=max= loop (i+1) (body i acc)
| otherwise = acc
body :: Int -> Int -> Int
body !i !acc = i+acc
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: speed: ghc vs gcc
barsoap:
> Don Stewart wrote:
>
> > No! This is not how open source works! You *should submit bug
> > reports* and *analysis*. It is so so much more useful than
> > complaining and throwing stones.
> >
> Exactly. I don't know where, but I read that the vast majorities of
> Linux bugs are reported, nailed, and then fixed, by at least three
> different persons: The first reports a misbehaviour, the second manages
> to find it surfacing in a certain line of code, the third instantly
> knows how to make it go away.
Elaboarting further:
Thinking more about Bulat's code gen observations, I think there's something
wrong here -- other than that GHC needs the new codegen to do any of the
fancier loop optimisations.
If we take what I usually see as the best loops GHC can do for this kind of
thing:
import Data.Array.Vector
main = print (sumU (enumFromToU 1 (10^9 :: Int)))
And compile it:
$ ghc-core A.hs -O2 -fvia-C -optc-O3
We get ideal core, all data structures fused away, and no heap allocation:
$wfold_s15t :: Int# -> Int# -> Int#
$wfold_s15t =
\ (ww1_s150 :: Int#) (ww2_s154 :: Int#) ->
case ># ww2_s154 ww_s14U of wild_aWm {
False ->
$wfold_s15t
(+# ww1_s150 ww2_s154) (+# ww2_s154 1);
True -> ww1_s150
}; } in
case $wfold_s15t 0 1
Which produces nice assembly:
s16e_info:
cmpq6(%rbx), %rdi
jg .L2
addq%rdi, %rsi
leaq1(%rdi), %rdi
jmp s16e_info
This is the best GHC will do here, in my experience, and I'm satisifed with it.
Short of new backend tweaks, and realising that GHC is not the loop magic
compiler GCC is.
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/IntegratedCodeGen
We can be happy with this. The compiler is doing exactly what we expect.
$ time ./B
55
./B 0.96s user 0.00s system 99% cpu 0.967 total
Now, going back to the low level version, Bulat's loop:
main()
{
int sum=0;
//for(int j=0; j<100;j++)
for(int i=0; i<1000*1000*1000;i++)
sum += i;
return sum;
}
What was first confusing for me was that he wrote the loop "backwards" when
translating to Haskell,
like this:
main = print $ sum0 (10^9) 0
sum0 :: Int -> Int -> Int
sum0 0 !acc = acc
sum0 !x !acc = sum0 (x-1) (acc+x)
(The bang patterns aren't needed). Note how he counts backwards from 10^9. Was
there a reason for that, Bulat?
I wondered if we just got worse code on backwards counting loops. So
translating into the "obvious" translation, counting up:
main = print (sum0 0 1)
sum0 :: Int -> Int -> Int
sum0 acc n | n > 10^9 = acc
| otherwise = sum0 (acc + n) (n + 1)
Which I actually consider to be the same difficulty as writing the C version,
fwiw...
We start to notice something interesting:
$wsum0 :: Int# -> Int# -> Int#
$wsum0 =
\ (ww_sOH :: Int#) (ww1_sOL :: Int#) ->
case lvl2 of wild1_aHn { I# y_aHp ->
case ># ww1_sOL y_aHp of wild_B1 {
False ->
letrec {
$wsum01_XPd :: Int# -> Int# -> Int#
$wsum01_XPd =
\ (ww2_XP4 :: Int#) (ww3_XP9 :: Int#) ->
case ># ww3_XP9 y_aHp of wild11_Xs {
False ->
$wsum01_XPd (+# ww2_XP4 ww3_XP9) (+# ww3_XP9 1);
True -> ww2_XP4
}; } in
$wsum01_XPd (+# ww_sOH ww1_sOL) (+# ww1_sOL 1);
True -> ww_sOH
}
Why is there an extra test? What is GHC doing?
Checking the asm:
$ ghc -O2 -fasm
sQ3_info:
.LcRt:
cmpq 8(%rbp),%rsi
jg .LcRw
leaq 1(%rsi),%rax
addq %rsi,%rbx
movq %rax,%rsi
jmp sQ3_info
$ time ./B
55
./B 1.30s user 0.01s system 98% cpu 1.328 total
So its a fair bit slower. Now, we should, as a principle, be able to write sum
directly as I did , and get the
same code from the manual, and automatically , fused version. But we didn't.
Checking via C:
$ ghc -O2 -optc-O3 -fvia-C
Better code, but still a bit slower:
sQ3_info:
cmpq8(%rbp), %rsi
jg .L8
addq%rsi, %rbx
leaq1(%rsi), %rsi
jmp sQ3_info
Running:
$ time ./B
55
./B 1.01s user 0.01s system 97% cpu 1.035 total
So I think we have a bug report! Why did GHC put that extra test in place?
Now, none of this addresses (I think) Bulat's point that GCC can unroll loops
and do other loop magic.
That's handled under a different workflow - the new code generator.
I'll create the ticket.
-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: speed: ghc vs gcc
Don Stewart wrote: > No! This is not how open source works! You *should submit bug > reports* and *analysis*. It is so so much more useful than > complaining and throwing stones. > Exactly. I don't know where, but I read that the vast majorities of Linux bugs are reported, nailed, and then fixed, by at least three different persons: The first reports a misbehaviour, the second manages to find it surfacing in a certain line of code, the third instantly knows how to make it go away. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: speed: ghc vs gcc
Bulat Ziganshin wrote: > Hello Peter, > > Friday, February 20, 2009, 6:34:04 PM, you wrote: > > > Well C# does it with a for loop in 2300ms, and when using a > > IEnumerable sequence it needs__19936ms. Very much like the Haskell > > code. But of course the Haskell code could optimize the sum I guess, > > I assume it is using the lazy version of sum by default. > > the question is what is the natural for every language > > > Anyway it was more of a question.__Does GHC perform register > > allocation (e.g. using graph colouring) __and loop unrolling? > > afaik, ghc can be compared with 20-years old C compilers. it uses > registers for performing tight loops but has very simple register > allocation procedure. also it doesn't unroll loops > hmmm... do we have magic-hash vector types and folds and maps on them? I'm only asking because gcc fails to use _anything_ but plain registers. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: speed: ghc vs gcc
Hello Peter, Friday, February 20, 2009, 6:34:04 PM, you wrote: > Well C# does it with a for loop in 2300ms, and when using a > IEnumerable sequence it needs 19936ms. Very much like the Haskell > code. But of course the Haskell code could optimize the sum I guess, > I assume it is using the lazy version of sum by default. the question is what is the natural for every language > Anyway it was more of a question. Does GHC perform register > allocation (e.g. using graph colouring) and loop unrolling? afaik, ghc can be compared with 20-years old C compilers. it uses registers for performing tight loops but has very simple register allocation procedure. also it doesn't unroll loops > On Fri, Feb 20, 2009 at 4:22 PM, Colin Paul Adams > wrote: > >> "Peter" == Peter Verswyvelen writes: > > Peter> So GHC is about 3 to 4 times slower as Visual C++ / GCC > Peter> without loop unrolling, which is not too bad since GHC does > Peter> not perform register optimization and loop unrolling yet > Peter> no? > > I would call it rather poor. > > And I don't accept a since of that form as valid mitigation. > -- > Colin Adams > Preston Lancashire > > -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: speed: ghc vs gcc
Hello Achim, Friday, February 20, 2009, 6:25:31 PM, you wrote: >> it was done in order to simplify sources. are you really believe that >> ghc needs more than 1 millisecond to print one number? :) >> > Well, I know that (Show a) is about as slow as you can get. yes, but it's printed only once against 10^9 computations -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: speed: ghc vs gcc
Well C# does it with a for loop in 2300ms, and when using a IEnumerable sequence it needs 19936ms. Very much like the Haskell code. But of course the Haskell code could optimize the sum I guess, I assume it is using the lazy version of sum by default. Anyway it was more of a question. Does GHC perform register allocation (e.g. using graph colouring) and loop unrolling? On Fri, Feb 20, 2009 at 4:22 PM, Colin Paul Adams wrote: > > "Peter" == Peter Verswyvelen writes: > >Peter> So GHC is about 3 to 4 times slower as Visual C++ / GCC >Peter> without loop unrolling, which is not too bad since GHC does >Peter> not perform register optimization and loop unrolling yet >Peter> no? > > I would call it rather poor. > > And I don't accept a since of that form as valid mitigation. > -- > Colin Adams > Preston Lancashire > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: speed: ghc vs gcc
Bulat Ziganshin wrote: > Hello Achim, > > Friday, February 20, 2009, 5:44:44 PM, you wrote: > > > Nice! Now we know that gcc can calculate faster than Haskell can > > calculate and print. Next time, use exitWith, please. > > it was done in order to simplify sources. are you really believe that > ghc needs more than 1 millisecond to print one number? :) > Well, I know that (Show a) is about as slow as you can get. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: speed: ghc vs gcc
Hello Peter, Friday, February 20, 2009, 6:18:50 PM, you wrote: > So GHC is about 3 to 4 times slower as Visual C++ / GCC without > loop unrolling why stop on disabling loop unrolling? there are lot of options we can use if we want to make gcc slower :D -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: speed: ghc vs gcc
> "Peter" == Peter Verswyvelen writes: Peter> So GHC is about 3 to 4 times slower as Visual C++ / GCC Peter> without loop unrolling, which is not too bad since GHC does Peter> not perform register optimization and loop unrolling yet Peter> no? I would call it rather poor. And I don't accept a since of that form as valid mitigation. -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: speed: ghc vs gcc
Hello Achim, Friday, February 20, 2009, 5:44:44 PM, you wrote: > Nice! Now we know that gcc can calculate faster than Haskell can > calculate and print. Next time, use exitWith, please. it was done in order to simplify sources. are you really believe that ghc needs more than 1 millisecond to print one number? :) -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: speed: ghc vs gcc
When I change the C++ program into:
int n;
scanf("%d", &n);
for(i=0; i wrote:
> Bulat Ziganshin wrote:
>
>
> > execution times:
> > sum:
> >ghc 6.6.1 -O2 : 12.433 secs
> >ghc 6.10.1 -O2 : 12.792 secs
> > sum-fast:
> >ghc 6.6.1 -O2 : 1.919 secs
> >ghc 6.10.1 -O2 : 1.856 secs
> >ghc 6.10.1 -O2 -fvia-C : 1.966 secs
> > C++:
> >gcc 3.4.5 -O3 -funroll-loops: 0.062 secs
> >
> Nice! Now we know that gcc can calculate faster than Haskell can
> calculate and print. Next time, use exitWith, please.
>
>
> --
> (c) this sig last receiving data processing entity. Inspect headers
> for copyright history. All rights reserved. Copying, hiring, renting,
> performance and/or quoting of this signature prohibited.
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: speed: ghc vs gcc
On a G4:
s.hs (which does not need bang patterns) is:
main = seq (sum0 (10^9) 0) (return ())
sum0 :: Int -> Int -> Int
sum0 0 acc = acc
sum0 x acc = sum0 (x-1) $! (acc+x)
And s.c is (actually including 10^9, which Bulat's did not):
main()
{
int sum=0;
for(int i=1000*1000*1000; i>0; i--)
sum += i;
}
I compiled them with
ghc --make -O2 s.hs -o shs
gcc -o sc -std=c99 -O3 -funroll-loops s.c
And timed them:
$ time ./shs
real0m3.309s
user0m3.008s
sys 0m0.026s
$ time ./sc
real0m0.411s
user0m0.316s
sys 0m0.006s
So C is 9.4 times faster.
And via-C did not help:
$ ghc -fvia-C -optc "-O3 -funroll-loops" --make -O2 s.hs -o shs-via-C
$ time ./shs-via-C
real0m7.051s
user0m3.010s
sys 0m0.050s
--
Chris
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: speed: ghc vs gcc
Bulat Ziganshin wrote: > execution times: > sum: >ghc 6.6.1 -O2 : 12.433 secs >ghc 6.10.1 -O2 : 12.792 secs > sum-fast: >ghc 6.6.1 -O2 : 1.919 secs >ghc 6.10.1 -O2 : 1.856 secs >ghc 6.10.1 -O2 -fvia-C : 1.966 secs > C++: >gcc 3.4.5 -O3 -funroll-loops: 0.062 secs > Nice! Now we know that gcc can calculate faster than Haskell can calculate and print. Next time, use exitWith, please. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
