std.math performance (SSE vs. real)

[Iain Buclaw via Digitalmars-d]

On 3 Jul 2014 04:50, "Sean Kelly via Digitalmars-d" <
digitalmars-d at puremagic.com> wrote:
>
> On Thursday, 3 July 2014 at 01:13:13 UTC, H. S. Teoh via Digitalmars-d
wrote:
>>
>>
>> I'm not sure I understand how removing support 80-bit floats hurts
interoperability with C? I thought none of the standard C float types map
to the x87 80-bit float?
>
>
> The C spec never says anything specific about representation because it's
meant to target anything, but the x86 and AMD64 ABIs basically say that
"long double" is 80-bit for calculations.  The x86 spec says that the type
is stored in 96 bits though, and the AMD64 spec says they're stored in 128
bits for alignment purposes.
>
> 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.

I take the spec to mean that I can map float, double, and real to the
native C types for float, double, and long double - or in jargon terms, the
native single, double, and extended (or quad if the user or backend
requests it) types.

Certainly I have implemented my bits of std.math with real == double and
real == quad in mind.  PPC will have to wait, but it is easy enough to
identify doubledouble reals in CTFE.

Iain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140703/87a5ae4a/attachment-0001.html>