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 <wasserman.lo...@gmail.com > 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