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


On Sat, Feb 21, 2009 at 5:55 PM, Sebastian Sylvan <sylvan@student.chalmers.se> wrote:


On Sat, Feb 21, 2009 at 11:35 PM, Bulat Ziganshin <bulat.ziganshin@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