std.math performance (SSE vs. real)

[via Digitalmars-d]

On Wednesday, 2 July 2014 at 16:03:47 UTC, Iain Buclaw via 
Digitalmars-d wrote:
>
> Only matters if you have to implement it in your backend

You have to implement it in the backend if D requires strict 
IEEE754 conformance?

> Vectors are treated differently from floats

How can you then let the compiler vectorize? You can't. Meaning, 
your code will run very slow.

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

I don't agree. If your code produce denormal numbers then it 
matters a lot if they are forced to zero or not. Just think about 
divison by zero traps. Why would this only be a library issue?

If you write portable code you shouldn't have to second guess 
what the compiler does. It either guarantees that denormal 
numbers are not flushed to zero, or it does not. If it does not 
then D does not require IEEE754 and you will have to think about 
this when you write your code.

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

I don't really understand the reasoning here. Is D Intel x86 
specific? Meaning, it is a system level programming language on 
x86 only and something arbitrary on other platforms?

Either D requires IEEE754 strict mode, or it does not. It matters 
what the default is.