Always false float comparisons

[Manu via Digitalmars-d]

On 17 May 2016 at 12:00, Manu <turkeyman at gmail.com> wrote:
> On 16 May 2016 at 21:35, Andrei Alexandrescu via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
>> On 5/16/16 7:33 AM, deadalnix wrote:
>>>
>>> Regardless of the compiler actually doing it or not, the argument that
>>> extra precision is a problem is self defeating.
>>
>>
>> I agree that this whole "we need less precision" argument would be difficult
>> to accept.
>>
>>> I don't think argument
>>> for speed have been raised so far.
>>
>> This may be the best angle in this discussion. For all I can tell 80 bit is
>> slow as molasses and on the road to getting slower. Isn't that enough of an
>> argument to move away from it?
>
> It really has though!
> At Remedy, the first thing we noticed when compiling code with DMD is
> that our float code produced x87 ops, and with the x64 calling
> convention (floats in SSE regs), this means pushing every function
> argument to the stack, loading them into x87 regs, doing the work
> (slowly), pushing them back, and popping them into a return reg. The
> codegen is insanely long and inefficient.
> The only reason it wasn't a critical blocker was because of the
> relative small level of use of D, and that it wasn't in any
> time-critical path.
> If Ethan and Remedy want to expand their use of D, the compiler CAN
> NOT emit x87 code. It's just a matter of time before a loop is in a
> hot path.

That said, I recall a conversation where Walter said this has been
addressed? I haven't worked on this in some time now, so I haven't
tested where it's at. Just saying that complaints about x87
performance have definitely been made.