std.math performance (SSE vs. real)

[John Colvin via Digitalmars-d]

On Friday, 4 July 2014 at 17:05:16 UTC, Walter Bright wrote:
> On 7/4/2014 3:38 AM, Don wrote:
>> What is "the longest type supported by the native hardware"? I 
>> don't know what
>> that means, and I don't think it even makes sense.
>
> Most of the time, it is quite clear.
>
>
>> For example, Sparc has 128-bit quads, but they only have 
>> partial support.
>> Effectively. they are emulated. Why on earth would you want to 
>> use an emulated
>> type on some machines, but not on others?
>
> Emulation is not native support.
>
>
>> Perhaps the intention was "the largest precision you can get 
>> for free, without
>> sacrificing speed" then that's not clearly defined. On x86-32, 
>> that was indeed
>> 80 bits. But on other systems it doesn't have an obvious 
>> answer.
>> On x86-64 it's not that simple. Nor on PPC or Sparc.
>
> Yes, there is some degree of subjectivity on some platforms. I 
> don't see a good reason for hamstringing the compiler dev with 
> legalese for Platform X with legalese that isn't quite the 
> right thing to do for X.
>
> I think the intention of the spec is clear, and the compiler 
> implementor can be relied on to exercise good judgement.

Who are these "compiler implementers"? Are you actually 
suggesting that, for example, ldc and gdc would seperately decide