std.math performance (SSE vs. real)

[Iain Buclaw via Digitalmars-d]

On 3 July 2014 11:49, Jonathan M Davis via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Wed, 02 Jul 2014 23:56:21 -0700
> Walter Bright via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
>
>> On 7/2/2014 8:48 PM, Sean Kelly wrote:
>> > I'm still unclear whether we're aiming for C interoperability or
>> > hardware support though, based on Walter's remark about SPARC and
>> > PPC.  There, 'long double' is represented differently but is not
>> > backed by specialized hardware, so I'm guessing D would make 'real'
>> > 64-bits on these platforms and break compatibility with C.  So... I
>> > guess we really do need a special alias for C compatibility, and
>> > this can map to whatever intrinsic type the applicable compiler
>> > supports for that platform.
>>
>> What is unclear about being able to call a C function declared as:
>>
>>      int foo(long double r);
>>
>> from D?
>
> I don't think that there's anything unclear about that. The problem is that if
> real is supposed to be the largest hardware supported floating point type,
> then that doesn't necessarily match long double. It happens to on x86 and
> x86_64, but it doesn't on other architectures.
>
> So, is real the same as C's long double, or is it the same as the largest
> floating point type supported by the hardware? We have erroneously treated
> them as the same thing, because they happen to be the same thing on x86
> hardware. But D needs to work on more than just x86 and x86_64, even if dmd
> doesn't.
>

The spec should be clearer on that.  The language should respect the
long double ABI of the platform it is targeting - so if the compiler
is targeting a real=96bit system, but the max supported on the chip is
128bit, the compiler should *still* map real to the 96bit long
doubles, unless explicitly told otherwise on the command-line.

The same goes to other ABI aspects of real, for instance, if you are
targeting an ABI where scalar 64bit operations are done in Neon, then
the compiler adheres to that (though I'd hope that people stick to
defaults and not do this, because the cost of moving data from core
registers to neon is high).

Regards
Iain