std.math performance (SSE vs. real)

[Iain Buclaw via Digitalmars-d]

On 2 July 2014 21:37, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 7/2/2014 1:53 AM, Don wrote:
>>
>> Definitely, discarding excess precision is a crucial operation. C and C++
>> tried
>> to do it implicitly with "sequence points", but that kills optimisation
>> possibilities so much that compilers don't respect it. I think it's
>> actually
>> quite similar to write barriers in multithreaded programming. C got it
>> wrong,
>> but we're currently in an even worse situation because it doesn't
>> necessarily
>> happen at all.
>>
>> We need a builtin operation -- and not in std.math, this is as crucial as
>> addition, and it's purely a signal to the optimiser. It's very similar to
>> a
>> casting operation. I wonder if we can do it as an attribute?
>> .exact_float,
>> .restrict_float, .force_float, .spill_float or something similar?
>>
>> With D's current floating point semantics, it's actually impossible to
>> write
>> correct floating-point code. Everything that works right now, is
>> technically
>> only working by accident.
>>
>> But if we get this right, we can have very nice semantics for when things
>> like
>> FMA are allowed to happen -- essentially the optimiser would have free
>> reign
>> between these explicit discard_excess_precision sequence points.
>
>
> This is easily handled without language changes by putting a couple builtin
> functions in druntime - roundToFloat() and roundToDouble().
>
>
>
>> Ideally, I think we'd have a __real80 type. On x86 32 bit this would be
>> the same
>> as 'real', while on x86-64 __real80 would be available but probably 'real'
>> would
>> alias to double. But I'm a lot less certain about this.
>
>
> I'm afraid that would not only break most D programs, but also
> interoperability with C.

I think it could work with a very small selective list of operations.

ie:
- NegExp
- CmpExp
- CallExp to core.math intrinsics.


Regards
Iain.