std.math performance (SSE vs. real)

[Iain Buclaw via Digitalmars-d]

On 2 July 2014 12:42, via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
> On Wednesday, 2 July 2014 at 08:52:25 UTC, Iain Buclaw via Digitalmars-d
> wrote:
>>
>> The crucial thing here is that the layout of float/double types are
>> IEEE 754 are compatible. :)
>
>
> That's nice of course, if you import/export, but hardly the only crucial
> thing.
>
> Implied correctness and warnings when assumptions break is also important…
>
>
>> These behaviours you describe only affect the FP control functions in
>> std.math, which are the only thing platform specific, and can only be
>> written in inline assembly anyway...
>
>
> It affects the backend.

Only matters if you have to implement it in your backend

> It affects vectorization. (NEON is not IEEE754 AFAIK)

Vectors are treated differently from floats

> It affects what a conforming D compiler is allowed to do.

That depends what you mean be 'conforming'.

> It affects versioning.
>
> E.g. you can have a flags IEEE754_STRICT or IEE754_HAS_NAN etc and use
> versioning that dectects the wrong compiler-mode.

Affects only library maintainers, but I haven't looked too much into
what gcc offers as a platform regarding this.

The ARM market is terrible, and it will certainly be the case that we
*can't* have a one size fits all solution.  But in the standard
libraries we can certainly keep strictly in line with the most
conforming chips, so if you wish to support X you may do so in a
platform-specific fork.

This is certainly not unusual for druntime (eg: minilibd)

Regards
Iain