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: 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: 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[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
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
