std.math performance (SSE vs. real)

Don via Digitalmars-d digitalmars-d at puremagic.com
Tue Jul 8 00:35:23 PDT 2014


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.

I think the only difference it makes is performance. But there is 
not very much difference in performance between double-double, 
and implementations using microcode. Eg PowerPC double-doubles 
operations require fewer clock cycles than x87 operations on 286.


>> 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 agree. But I think we can achieve the same outcome while 
providing more semantic guarantees to the programmer.


> I think the intention of the spec is clear, and the compiler 
> implementor can be relied on to exercise good judgement.

The problem is that the developer cannot write code without 
knowing the semantics.
For example, one of the original motivations for having 80-bit 
floats on the x87 was that for many functions, they give you 
correctly-rounded results for 'double' precision. If you don't 
have 80-bit reals, then you need to use far more complicated 
algorithms.
If your code needs to work on a system with only 64 bit reals, 
then you have to do the hard work.

Something I've come to realize, was that William Kahan's work was 
done in a world before generic programming. He had constraints 
that we don't have.
Our metaprogramming system gives us great tools to get the 
highest accuracy and performance out of any processor. We can 
easily cope with the messy reality of real-world systems, we 
don't need to follow Java in pretending they are all the same. 
This is something we're good at!

A 'real' type that has system-dependent semantics is a poor-man's 
generics.
Take a look at std.math, and see all the instances of 'static if 
(real.mant_dig == '. Pretty clearly, 'real' is acting as if it 
were a template parameter.

And my experience is that any code which doesn't treat 'real' as 
a template parameter, is probably incorrect. I think we should 
acknowledge this.




More information about the Digitalmars-d mailing list