[Haskell-cafe] Re: speed: ghc vs gcc

[Sebastian Sylvan]

On Sat, Feb 21, 2009 at 12:16 AM, Bulat Ziganshin <bulat.ziganshin at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090221/c90056b5/attachment.htm