std.math performance (SSE vs. real)

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Thu Jul 3 03:49:03 PDT 2014


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.

We already have aliases such as c_long to deal with C types. I don't think
that it would be all that big a deal to make it so that real was specifically
the largest supported hardware type and then have c_long_double for
interacting with C.

- Jonathan M Davis


More information about the Digitalmars-d mailing list