std.math performance (SSE vs. real)

Iain Buclaw via Digitalmars-d digitalmars-d at puremagic.com
Wed Jul 2 01:51:57 PDT 2014


On 1 July 2014 20:36, via Digitalmars-d <digitalmars-d at puremagic.com> wrote:
> On Tuesday, 1 July 2014 at 16:58:55 UTC, Walter Bright wrote:
>>
>> Click on "compiling for strict IEEE conformance"
>
>
> It also states that compliance affect performance.
>
>
>>> not IEEE754 compliant. VPF is almost compliant, but does not support
>>> subnormal
>>> numbers and flush them to zero. Which can be a disaster…
>>
>>
>> It wouldn't be any different if the D spec says "floating point is, ya
>> know, whatevah". You can't fix stuff like this in the spec.
>
>
> Well, the difference is that you can make VPF mostly compliant, but that
> means you trap subnormal numbers and fix it in software. Which affects
> performance.
>
> If the specs require IEEE754 compliance then you default to software
> emulation and have to turn it off through compiler switches.
>
> Here is another example: the parallella Coprocessor from Adapteva:
>
> «The CPU is compatible with the IEEE-754 single-precision format, with the
> following
> exceptions:
> - No support for inexact flags.
> - NAN inputs generate an invalid exception and return a quiet NAN. When one
> or both of the
> inputs are NANs, the sign bit of the operation is set as an XOR of the signs
> of the input sign
> bits.
> - Denormal operands are flushed to zero when input to a computation unit and
> do not generate
> an underflow exception. Any denormal or underflow result from an arithmetic
> operation is
> flushed to zero and an underflow exception is generated.
> - Round-to-±infinity is not supported.»
>

The crucial thing here is that the layout of float/double types are
IEEE 754 are compatible. :)

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

Regards
Iain



More information about the Digitalmars-d mailing list