[Haskell-cafe] Known Unknowns
haskell at list.mightyreason.com
Wed Feb 1 05:50:42 EST 2006
Donald Bruce Stewart wrote:
> This entry in fact runs faster than the original (though not the new vectorised
> entry) optimised C entry (and faster than all other languages):
> So, by carefully tweaking things, we first squished a space leak, and then gained another
> In summary:
> * Check the Core that is generated
> * Watch out for optimisations that are missed
> * Read the generated C for the tight loops.
> * Make sure tight loops are unboxed
> * Use -fexcess-precision and -optc-ffast-math for doubles
> This is roughly the process I used for the other shootout entries.
I just looked hard at the "new vectorised entry" and the original entry for C.
In both, the last two functions, which use the alt-ernating sign, are *not* done
in the required naive fashion:
> sum = 0.0;
> for (k = 1; k <= n-1; k += 2) sum += 1.0/kd;
> for (k = 2; k <= n; k += 2) sum -= 1.0/kd;
> printf("%.9f\tAlternating Harmonic\n", sum);
> sum = 0.0;
> for (k = 1; k <= 2*n-1; k += 4) sum += 1.0/kd;
> for (k = 3; k <= 2*n; k += 4) sum -= 1.0/kd;
> printf("%.9f\tGregory\n", sum);
As you can see, all the positive terms are added to sum, then all the negative
terms. The double precision math comes to a different result, but this is
hidden by printing only 9 digits.
I just modified the g++ entry and the Haskell entry which do it right and the c
entry to print more digits (e.g. "show sum" in Haskell).
The Haskell entry and g++ entry agree, as expected. The c entry does *not* agree:
AltHarm 0.6931469805600938 Haskell
Gregory 0.7853980633974356 Haskell
The gcc entry is computing a different answer since it uses the wrong order for
making the partial sum.
More information about the Haskell-Cafe