std.math performance (SSE vs. real)

[Don via Digitalmars-d]

On Monday, 30 June 2014 at 04:15:46 UTC, Walter Bright wrote:
> On 6/29/2014 8:22 PM, Manu via Digitalmars-d wrote:
>> Well, here's the thing then. Consider that 'real' is only 
>> actually
>> supported on only a single (long deprecated!) architecture.

>> In x64's case, it is deprecated for over a decade now, and may 
>> be
>> removed from the hardware at some unknown time. The moment 
>> that x64
>> processors decide to stop supporting 32bit code, the x87 will 
>> go away,
>> and those opcodes will likely be emulated or microcoded.
>> Interacting real<->float/double means register swapping through
>> memory. It should be treated the same as float<->simd; they are
>> distinct (on most arch's).
>
> Since they are part of the 64 bit C ABI, that would seem to be 
> in the category of "nevah hoppen".

What I think is highly likely is that it will only have legacy 
support, with such awful performance that it never makes sense to 
use them. For example, the speed of 80-bit and 64-bit 
calculations in x87 used to be identical. But on recent Intel 
CPUs, the 80-bit operations run at half the speed of the 64 bit 
operations. They are already partially microcoded.

For me, a stronger argument is that you can get *higher* 
precision using doubles, in many cases. The reason is that FMA 
gives you an intermediate value with 128 bits of precision; it's 
available in SIMD but not on x87.

So, if we want to use the highest precision supported by the 
hardware, that does *not* mean we should always use 80 bits.

I've experienced this in CTFE, where the calculations are 
currently done in 80 bits, I've seen cases where the 64-bit 
runtime results were more accurate, because of those 128 bit FMA 
temporaries. 80 bits are not enough!!