On 02/08/2013 04:12 PM,
Daniel J Sebald wrote:
On 02/08/2013
03:54 PM, Mike Miller wrote:
On Thu, Feb 7,
2013 at 1:27 PM, Daniel J Sebald wrote:
On
02/07/2013 09:32 AM, John W. Eaton wrote:
That's
odd. Does the JVM set some FPU flags that are different
from the
default that could affect the values that std::pow
computes?
I was just about to email to propose that could be
happening. Perhaps
there
is a bug in Java that isn't fully restoring the state of
the CPU
registers
when it returns. Could be a machine specific problem.
tl;dr - Yes, Java does in fact modify the FPU control word
which ends
up reducing the floating point precision that Octave
normally
calculates with. I think the right way to handle this is to
restore
the FPU flags so that values are computed consistently
whether Java is
loaded or not. I will work on a changeset that restores the
expected
precision on i386.
As Jordi said, nice detective work there.
Details:
From some
searching and looking through the openjdk source, I gather
that the Java spec requires all floating point operations to
be either
single or double, even intermediate results [1]. What this
translates
to in the openjdk implementation (and probably others) is
that they
disable the long double format at the hardware level in the
x87 FPU
control word; this does not apply to x86_64. This is almost
certainly
the source of all of the differences I have been observing,
I will
soon have standalone C examples to confirm each of the
effects.
Yeah, I suppose it's aiming to be device independent, so all
one or all
the other, and no worries about the various combinations of
address
length and register length.
Actually, it's a mix of 32 bit and 64 bit with promotion rules.
I've tried to locate the source code, but openjdk is a pretty
big project with multiple repositories. I'm not sure if it
would be in the development kit or the virtual machine either.
I'm guessing that Java is running in the same thread, correct?
Otherwise, it seems like the OS might handle restoring the
state.
Well, use your judgment as to what level of software should be
concerned about this.
Dan