C performance

[Tim Prince]

It its probably worth noting that the hardware architecture with
which most people are familiar -- the Intel IA32 -- is one of
these. All of its calculations use "long double" internally
(assuming, of course, that your C compiler maps "long double"
onto this 80-bit internal format!).

The IA32 does have a "precision" field in its FPU control word,
but this does not work in quite the same way as actually converting
the final result down to the 32 or 64 bit "memory format" for float
and double. In particular, setting the precision to "float" causes
mantissa rounding, but leaves the exponent range +/- 16383 instead
of +/- 127. In other words, the internal format is as if you had
39 bits to work with, instead of the "expected" 32. This means
that infinities and NaNs do not occur when one might expect them.

These "problems" go away when switching to SSE[12] for FP, right?

My understanding is that the SSE unit only has 32-bit floats and 64-bit
doubles, and the x87 unit is still used for long doubles (but nothing else).
This is why I was curious about promotion of floats to doubles and back to
floats -- that seems like it would seriously mess up the SSE registers.

In SSE/SSE2 code, there's no implicit promotion of float to double.
"Vector" parallel code requires going through memory to cast between float
and double. In Windows, there's no support for long double wider than
double. The Windows-64 ABI doesn't even support use of the x87
instructions, although the influence of Kahan may live on in the linux ABI.

 

[Jack Klein]

It its probably worth noting that the hardware architecture with
which most people are familiar -- the Intel IA32 -- is one of
these. All of its calculations use "long double" internally
(assuming, of course, that your C compiler maps "long double"
onto this 80-bit internal format!).

The IA32 does have a "precision" field in its FPU control word,
but this does not work in quite the same way as actually converting
the final result down to the 32 or 64 bit "memory format" for float
and double. In particular, setting the precision to "float" causes
mantissa rounding, but leaves the exponent range +/- 16383 instead
of +/- 127. In other words, the internal format is as if you had
39 bits to work with, instead of the "expected" 32. This means
that infinities and NaNs do not occur when one might expect them.

These "problems" go away when switching to SSE[12] for FP, right?

My understanding is that the SSE unit only has 32-bit floats and 64-bit
doubles, and the x87 unit is still used for long doubles (but nothing else).
This is why I was curious about promotion of floats to doubles and back to
floats -- that seems like it would seriously mess up the SSE registers.

In SSE/SSE2 code, there's no implicit promotion of float to double.
"Vector" parallel code requires going through memory to cast between float
and double. In Windows, there's no support for long double wider than
double. The Windows-64 ABI doesn't even support use of the x87
instructions, although the influence of Kahan may live on in the linux ABI.

It is quite inaccurate to say that there is no support in Windows for
long double wider than double. Microsoft made a marketing decision to
deprive programmers using their compiler of the full potential of the
x86 coprocessor/FPU. This has the effect of seriously reducing the
accuracy of many types of scientific and engineering programs
developed with their compiler.

On the other hand, GCC, lcc-win32, Borland, and probably others,
support 80 bit long doubles very will in Windows.

 

[Richard Delorme]

Richard Tobin a écrit :

That depends. For a single operation, it won't make much difference.
But if you're doing (say) a big matrix operation, the time loading and
storing the data may dominate, so using floats may well be faster.

If you really want to know, measure it.

This is a problem of memory bandwidth which, nowadays, is not related to
the CPU being 32 or 64 bits. Modern memories (SDRAM, DDR RAM, ...) send
64 bit words of memory, whatever they run on a 64 bit Opteron or a 32
bit Pentium IV.

 

[Nick Keighley]

news:[email protected]...

please don't top post. I have re-arranged your post.
please trim sigs. I have removed the previous post's sig.

No, but the result of the addition will be after adding.

why will the result be converted after the addition?

 

[Tim Prince]

It is quite inaccurate to say that there is no support in Windows for
long double wider than double. Microsoft made a marketing decision to
deprive programmers using their compiler of the full potential of the
x86 coprocessor/FPU. This has the effect of seriously reducing the
accuracy of many types of scientific and engineering programs
developed with their compiler.

On the other hand, GCC, lcc-win32, Borland, and probably others,
support 80 bit long doubles very will in Windows.

Thanks for standing up for the compilers which do support wide long double.
Although gcc supports long double the same under Windows as under other OS,
header and run-time library support aren't consistent. It will break any
program which depends on long double working in accord with <float.h>.
Newlib just added printf() support, but that hasn't made it into cygwin yet.
mingw uses the Microsoft library support, so there is even a possibility of
breaking the library by running with a different precision mode from the one
for which it is designed. I thought I was alone in using my own
<mathinline.h> for gcc Windows, to support long double math functions. I
like gcc, but I'm not blind to long double support being substandard on
Windows.