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/

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/

Don won't like that.
IIRC he spent some time making them behave properly.
Wheres the C ones are a bit more liberal ....

But he'll have to comment on that.

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); }

On 04.06.20 16:14, 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/ 
> 

In one of my projects I had to manually re-implement all functions that currently forward to libc, because libc is not portable.

On 04.06.20 16:40, Timon Gehr wrote:
> On 04.06.20 16:14, 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/ 
>>
> 
> In one of my projects I had to manually re-implement all functions that currently forward to libc, because libc is not portable.

(Note that this also means if you need portability you have to fork all your dependencies that use Phobos math functions.)

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.

They don't, or at least, not always, and can be beaten (e.g., by inlinable D implementations). The culprit is Phobos, apparently originating from the pre-SSE world and hence mostly focused on reals, many times not even offering single and double precision overloads (and if offered, many times casting and using the real version).

See https://github.com/dlang/phobos/pull/6272#issuecomment-373967109 for some results with proper Cephes ports to Phobos. I hoped others would take care of the rest, but as most of the time, if you don't do it yourself...

The latest LDC beta also comes with a significantly improved core.math.ldexp, easily beating the C version on my system (inlinable, no errno handling...).

On Thu, Jun 04, 2020 at 04:49:38PM +0000, kinke via Digitalmars-d 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.
> 
> They don't, or at least, not always, and can be beaten (e.g., by inlinable D implementations). The culprit is Phobos, apparently originating from the pre-SSE world and hence mostly focused on reals, many times not even offering single and double precision overloads (and if offered, many times casting and using the real version).

Yes, std.math seriously needs to offer single/double precision overloads that do NOT cast to real. This is a significant performance degrader in compute intensive software, and makes D look antiquated.  Leave the real overload there for when people are obsessed with the extra precision, but if the caller passes in a double, please oh please don't just forward it to the real overload!


[...]
> The latest LDC beta also comes with a significantly improved core.math.ldexp, easily beating the C version on my system (inlinable, no errno handling...).

Would LDC consider providing float/double overloads for std.math functions?  Ideally this would be merged upstream, but sometimes if there's no other way to get things done...


T

-- 
EMACS = Extremely Massive And Cumbersome System

On Thursday, 4 June 2020 at 17:04:54 UTC, H. S. Teoh wrote:
> Would LDC consider providing float/double overloads for std.math functions?  Ideally this would be merged upstream, but sometimes if there's no other way to get things done...

We are mostly just waiting for the *overloads* to finally make it upstream (e.g., blocked https://github.com/dlang/phobos/pull/7463), so that we can finally enable the commented-out LLVM intrinsics (e.g., https://github.com/ldc-developers/phobos/blob/26fac3b399c62ead78bedce7ccba9290a2cbbbf3/std/math.d#L4304-L4307). - Enabling them already would lead to a different Phobos API for LDC (e.g., log(0.1f) returning a float, not a real), that's why we've been waiting (for years).

Once the overloads are there (even by just casting and forwarding to the `real`-implementation for now), the remaining transcendental functions can be ported from e.g. Cephes as 2nd step, to have proper implementations for all floating-point types.

On Thursday, 4 June 2020 at 17:04:54 UTC, H. S. Teoh wrote:
> On Thu, Jun 04, 2020 at 04:49:38PM +0000, kinke via Digitalmars-d 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.
>> 
>> They don't, or at least, not always, and can be beaten (e.g., by inlinable D implementations). The culprit is Phobos, apparently originating from the pre-SSE world and hence mostly focused on reals, many times not even offering single and double precision overloads (and if offered, many times casting and using the real version).
>
> Yes, std.math seriously needs to offer single/double precision overloads that do NOT cast to real. This is a significant performance degrader in compute intensive software, and makes D look antiquated.  Leave the real overload there for when people are obsessed with the extra precision, but if the caller passes in a double, please oh please don't just forward it to the real overload!
>

mir.math.common [1] calls ldc/gcc intrinsics on LDC/GDC. On DMD, std.math function are primarily called. There are some DMD std.math functions that don't have overloads for float/double. In those cases, it calls std.math for CTFE, for types larger than double, or for impure C functions. Otherwise it calls the C function.

>
> [...]
>> The latest LDC beta also comes with a significantly improved core.math.ldexp, easily beating the C version on my system (inlinable, no errno handling...).
>
> Would LDC consider providing float/double overloads for std.math functions?  Ideally this would be merged upstream, but sometimes if there's no other way to get things done...
>
>
> T

LDC has intrinsics that I mentioned above that mir.math.common uses. However, I'm not sure how they are implemented...

[1] https://github.com/libmir/mir-core/blob/7b896e5b1a2ce1e78d672889bb8bbb649f1d748c/source/mir/math/common.d#L293

On Thu, Jun 04, 2020 at 05:16:04PM +0000, kinke via Digitalmars-d wrote:
> On Thursday, 4 June 2020 at 17:04:54 UTC, H. S. Teoh wrote:
> > Would LDC consider providing float/double overloads for std.math functions?  Ideally this would be merged upstream, but sometimes if there's no other way to get things done...
> 
> We are mostly just waiting for the *overloads* to finally make it
> upstream (e.g., blocked https://github.com/dlang/phobos/pull/7463), so
> that we can finally enable the commented-out LLVM intrinsics (e.g.,
> https://github.com/ldc-developers/phobos/blob/26fac3b399c62ead78bedce7ccba9290a2cbbbf3/std/math.d#L4304-L4307).
[...]

What's blocking the Phobos PR?  Actual issues, or just inertia like much of the Phobos PR queue?  I think we should push this through somehow. Like you said, it has been years, and prolonging this is only hurting rather than helping things.


T

-- 
What do you mean the Internet isn't filled with subliminal messages? What about all those buttons marked "submit"??