[erlang-bugs] Fwd: Rounding errors with hipe

[Fredrik Svahn]

>
> First of all you do know that floating-point (FP) is inherently
> imprecise, right?
>

Oh yes, that's why I wrote the disclaimer about "known problem"... :-)

Its trivial to write a c program with the exact same behaviour, unless you
add e.g. "-mfpmath=sse -msse2" for gcc (as you say, this is enabled by
default on x86-64).


> However, the problem here is the quirky nature of the old x87 FP unit,
> which is what 32-bit x86s use by default in most OS environments.
> (I believe MacOSX is one of the few to default to SSE2 even in 32-bit.)
>
> The x87 computes internally with an 80-bit format different from
> standard IEEE 64-bit floats. It does however round the result of
> each computation according to the precision control (which defaults
> to the 80-bit extended format), and it rounds when storing values
> to IEEE 64-bit floats in memory. So the final result is highly
> sensitive to the sequence of loads, arithmetics, and stores done
> during the computation.
>
> The BEAM virtual machine will store each intermediate result to
> memory, causing rounding to the IEEE 64-bit format.
>
> HiPE on x86-32/x87 will keep intermediate results in the x87
> register file (which technically is a stack) as long as possible.
> The benefit is improved performance from avoiding memory accesses.
> It also improves accuracy by avoiding some rounding operations.
>
> And that's the problem. The nature of FP is such that computing
> a more accurate result can be considered an error.
>
> A possible solution might be to program the x87's rounding control
> to always round to standard double precision. That should make BEAM
> and HiPE produce similar results, but it might break FP library
> routines.
>
> Having HiPE store each intermediate value just for the sake of
> BEAM compatibility would be awful.
>

I fully agree!


>
> The real solution is to forget about x87 and go to x86-64/SSE2.
>

sse/sse2 support on x86-32 is not an option?

I am just asking out of curiosity, I already have a workaround so this is
not critical for me in any way. I guess money/time is better spent elsewhere
if this is a lot of work.

BR /Fredrik


> /Mikael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20081203/42e2698f/attachment.htm>