Faster, GHC, and floating point.

[Simon Marlow]

> 1. Use -fexcess-precision, unless you really need the
> exact (lesser) precision. Otherwise each intermediate
> result is spilled in memory. This hurts!

There is currently a bug in GHC that the native code generator runs in
-fexcess-precision mode all the time (in other words, it doesn't
truncate to 64-bit precision like it should do).

> 2. Use floats rather than doubles. You won't lose so
> much precision because all intermediate computations
> will use 80-bit precision. This saves some memory.
> Plus, GHC doesn't align on 64 bits, which slows down
> access to doubles.

It is more-or-less random which intermediate computations will end up
using 80-bit precision.  You really shouldn't rely on this.

The alignment issue is a problem, but we don't have an easy fix.  If it
weren't for that, the only reason to use Floats would be to save memory.
If you get runtimes that vary randomly between two distinct values, the
chances are that it's a Double alignment issue.

Cheers,
	Simon