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

[Vadim Zeitlin]

On Fri, 26 Mar 2010 00:52:50 +0000 Greg Chicares <address@hidden> wrote:

GC> [...SSE asm stuff in glibc...]
GC> >  Of course, we could do the same ourselves in LMI-specific code.
GC> 
GC> I suppose we shouldn't add SSE asm instructions to lmi.
...
GC> Yes, controlling rounding direction is imperative, and I would prefer
GC> to control precision as well.

 Hello,

 I finally have a sequence of patches which implement the proposed changes.
For now I've uploaded them at http://review.bakefile.org/r/231/ where you
could look at (and possibly comment on) them but I can also post them here
(easily) or attach them to a (new?) Savannah ticket (which would require
more clicking so this is not my preferred variant).

 These patches basically do what you wrote, i.e. they use fesetround() when
available and not in x86 builds. I.e. even if fesetround() is available, 32
bit builds under x86 still continue to use x87-specific code to minimize
the chance of any breakage. I think that in the future we should switch to
using C99 functions everywhere but it's trivial to do it later as it's just
a simple change in config.hpp so for now I'd just like this patch to be
applied to make things work for 64 bit Linux builds and not change anything
for the existing 32 bit ones.

 So I'd like to help you with reviewing it but to be honest I don't have
much to say about it as most of the changes are pretty straightforward. I
finally decided to keep fenv_is_valid() and fenv_validate() functions
public but they just check for the rounding method when using C99 functions
so they're not very useful -- but this minimizes the amount of changes.
Speaking of which, there are a lot of trivial ones due to replacement of
LMI_X86 checks with LMI_FP_X87 ones, but this was unavoidable. I'd even
have liked to rename fenv_lmi_x86.hpp to fenv_lmi_x87.hpp as it's really
x87-specific but I didn't do it. Please let me know if anything seems
unclear of if you have any other questions.


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

 There are no errors for SSE and almost no speed difference neither:

        Min     Max     Avg     Median
387     0.1873  0.1956  0.1906  0.1894
SSE     0.1862  0.1995  0.1892  0.1875

 The numbers are suspiciously close in fact so I don't even know if the
difference is not just due to the measurement error. I may try to look
closer at the generate code in both cases later.

 Regards,
VZ