Re: [lmi] rounding unit test under Linux/x86-64

[Greg Chicares]

On 2010-03-25 21:21Z, Vadim Zeitlin wrote:
> On Wed, 24 Mar 2010 11:39:39 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> >         **** test failed:   '-3' == '-2'
> GC> >         [file fenv_lmi_test.cpp, line 211]
[...]
>  Actually the problem is not in fenv_rounding() but is due to the fact that
> the FPU control word is not being used at all. Under Linux/x86-64 platform
> math operations are implemented using SSE2 as it's faster and always
> available for all 64 bit CPUs [...]

It could be faster still if they used 16-bit floats. And even faster
with 8-bit half precision, though the reduced precision might trouble
a few of us dinosaurs.

We could simply use '-mfpmath=387', couldn't we? Probably some low-end
chip will remove the 80-bit hardware in the future, if indeed none has
already done so, but is that going to affect us this decade or the next?

[...SSE asm stuff in glibc...]
>  Of course, we could do the same ourselves in LMI-specific code.

I suppose we shouldn't add SSE asm instructions to lmi.

For pre-C99 toolchains, asm was the portable way to take control of
floating point, on machines with at least the capabilities of an 8087.

For C99 toolchains, we have fesetround(), but there's no such thing
as fesetprec() in standard C:

/// According to Goldberg:
///   http://docs.sun.com/source/806-3568/ncg_goldberg.html#4130
/// "fegetprec and fesetprec functions" were recommended in early
/// drafts, but "this recommendation was removed before the changes
/// were made to the C99 standard." The Rationale:
///   www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf
/// suggests that IEC 60559 is "ambivalent" as to whether precision
/// control must be dynamic. Yet IEEE 754r Draft 1.2.5 [G.2] says:
/// "changing the rounding direction or precision during execution may
/// help identify subprograms that are unusually sensitive to roundoff"

However, with SSE, there's no extended precision anyway, so there'd
be nothing useful for fesetprec() to control...so fegetprec() is all
we can hope for, and it should be available in any new compiler. For
legacy compilers, we can just keep the 80x87 asm.

> But I
> really think that if we're interested in fixing this at all,

Yes, controlling rounding direction is imperative, and I would prefer
to control precision as well.

> we should just
> use fesetround() i.e. fix the
> 
>       // SOMEDAY !! Revisit suppressed __STDC_IEC_559__ support. See:
>       //   http://lists.nongnu.org/archive/html/lmi/2008-06/msg00033.html
> 
> comment from fenv_lmi.hpp.

Yes, we should do that (even if we use '-mfpmath=387' for now) just
because IIRC it's nearly done, and it shouldn't be hard to get it to
work correctly; your next paragraph gives another reason.

>  For me a more interesting question is whether we actually want to fix it.
> AFAIK currently LMI is neither used nor compiled under 64 bit platforms at

Actually, I think Wendy has (at home) a 64-bit machine with a 64-bit
version of msw; and I have a 64-bit machine with 64-bit *nix. For
msw, a 64-bit MinGW-ish compiler is available, though we don't use
it yet.

> all so it's probably not a priority. OTOH it's not totally impossible that
> one day you may wish to enabled SSE support even in 32 bit builds, i.e. use
> -mfpmath=sse2 option, for performance reasons and it would be a nasty

Perhaps someday when you have the machine cycles to spare you could
compile with '-mfpmath=sse2' and '-mfpmath=387' separately and post
speed measurements. (Any of us could, but you'll probably finish
soonest.) I'm expecting little difference, but maybe there's a
surprise awaiting me--they might have let the 80-bit hardware rot.
For speed measurements, I think
  make cli_tests
would be appropriate. That's equivalent to
  ./lmi_cli_shared --accept --data_path=WHATEVER --selftest
if you throw away the first run to eliminate cache effects.
Some errors might be reported with SSE (due to lower precision),
but that ought not to affect the usefulness of the timings.

> surprise to (re)discover this breakage then. And unfortunately I don't know
> of any way to test, during compilation, if SSE instructions are being used
> so we can't even generate a #error or something.
> 
>  Please let me know if you'd like me to enable LMI_IEC_559 and retest with
> it.

Yes, would you please do that?