std.math performance (SSE vs. real)

[Manu via Digitalmars-d]

On 30 June 2014 14:15, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> 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.
>
>
> 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.

x86_64 and x86 are different architectures, and they have very different ABI's.
Nobody is manufacturing x86 (exclusive) cpu's.
Current x86_64 cpu's maintain a backwards compatibility mode, but
that's not a part of the x86-64 spec, and may go away when x86_64 is
deemed sufficiently pervasive and x86 sufficiently redundant.

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

Well, it's not an fp type as implemented by the standard fp
architecture of any cpu except x86, which is becoming less relevant
with each passing day.


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

Correct, so they are deliberately treated separately.
I argued for strong separation between simd and float, and you agreed.


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

Not in windows. You say they are in linux? I don't know.

"Intel started discouraging the use of x87 with the introduction of
the P4 in late 2000. AMD deprecated x87 since the K8 in 2003, as
x86-64 is defined with SSE2 support; VIA’s C7 has supported SSE2 since
2005. In 64-bit versions of Windows, x87 is deprecated for user-mode,
and prohibited entirely in kernel-mode."

How do you distinguish x87 double and xmm double in C? The only way I
know to access x87 is with inline asm.

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

Huh? I think you misunderstood my point. I'm saying that fpu/simd
units are distinct, and they are distanced by the type system in order
to respect that separation.