Why is std.math slower than the C baseline?

[Timon Gehr]

On 05.06.20 21:39, Andrei Alexandrescu wrote:
> On 6/4/20 10:39 AM, jmh530 wrote:
>> On Thursday, 4 June 2020 at 14:14:22 UTC, Andrei Alexandrescu wrote:
>>> D should just use the C functions when they offer better speed.
>>>
>>> https://www.reddit.com/r/programming/comments/gvuy59/a_look_at_chapel_d_and_julia_using_kernel_matrix/fsr4w5o/ 
>>>
>>
>> Below is a typical example of a std.math implementation for a trig 
>> function. It casts everything to real to improve accuracy. This 
>> doesn't explain everything, but it's a general strategy in std.math to 
>> prefer accuracy over speed.
>>
>> real cosh(real x) @safe pure nothrow @nogc
>> {
>>      //  cosh = (exp(x)+exp(-x))/2.
>>      // The naive implementation works correctly.
>>      const real y = exp(x);
>>      return (y + 1.0/y) * 0.5;
>> }
>>
>> /// ditto
>> double cosh(double x) @safe pure nothrow @nogc { return 
>> cosh(cast(real) x); }
>>
>> /// ditto
>> float cosh(float x) @safe pure nothrow @nogc  { return cosh(cast(real) 
>> x); }
> 
> This needs to change. It's one thing to offer more precision to the user 
> who consciously uses 80-bit reals, and it's an entirely different thing 
> to force that bias on the user who's okay with double precision.

Those implementations don't give you more than double precision. The 
issue is that they are slow, not that they are too precise.

Anyway, what you are saying is of course true, but it is a critique of 
language semantics, not Phobos:

https://dlang.org/spec/float.html
"It's possible that, due to greater use of temporaries and common 
subexpressions, optimized code may produce a more accurate answer than 
unoptimized code."

I'll decide which one (if any) of those results is "accurate", thank you 
very much.