std.math performance (SSE vs. real)

[Walter Bright via Digitalmars-d]

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.

It's news to me that x86, x86-64, etc., are deprecated, despite being used to 
run pretty much all desktops and laptops and even servers. The 80 bit reals are 
also part of the C ABI for Linux, OSX, and FreeBSD, 32 and 64 bit.


> I think it's reasonable to see that 'real' is not actually an fp type.

I find that a bizarre statement.


> It's more like an auxiliary type, which just happens to be supported
> via a completely different (legacy) set of registers on x64 (most
> arch's don't support it at all).

The SIMD registers are also a "completely different set of registers".


> 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".


> It's the same situation with SIMD; on x64, the SIMD unit and the FPU
> are the same unit, but I don't think it's reasonable to design all the
> API's around that assumption. Most processors separate the SIMD unit
> from the FPU, and the language decisions reflect that. We can't make
> the language treat SIMD just like an FPU extensions on account of just
> one single architecture... although in that case, the argument would
> be even more compelling since x64 is actually current and active.

Intel has yet to remove any SIMD instructions.