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 < [email protected]> wrote: > > > On Sat, Feb 21, 2009 at 12:16 AM, Bulat Ziganshin < > [email protected]> 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 [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
