www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why is std.math slower than the C baseline?

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
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/
Jun 04 2020
next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
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.
Jun 04 2020
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
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); }
Jun 04 2020
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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_ke
nel_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.
Jun 05 2020
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jun 05, 2020 at 03:39:26PM -0400, Andrei Alexandrescu via Digitalmars-d
wrote:

 On 6/4/20 10:39 AM, jmh530 wrote:


[...]

 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
 {




[...]

 }
 
 /// 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.


+100!  std.math has been pessimal for all these years for no good
reason, let's get this fixed by making sure this gets pushed through:

	https://github.com/dlang/phobos/pull/7463

AIUI, it's currently only held up by a single 3rd party package awaiting
a new release. Once that's done, we need to rectify this pessimal state
of affairs.


T

-- 
All men are mortal. Socrates is mortal. Therefore all men are Socrates.
Jun 05 2020
parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Friday, 5 June 2020 at 19:48:55 UTC, H. S. Teoh wrote:

 On Fri, Jun 05, 2020 at 03:39:26PM -0400, Andrei Alexandrescu 
 via Digitalmars-d wrote:

 On 6/4/20 10:39 AM, jmh530 wrote:


 [...]

 [...]




 [...]

 [...]


 
 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.


 +100!  std.math has been pessimal for all these years for no 
 good reason, let's get this fixed by making sure this gets 
 pushed through:

 	https://github.com/dlang/phobos/pull/7463

 AIUI, it's currently only held up by a single 3rd party package 
 awaiting a new release. Once that's done, we need to rectify 
 this pessimal state of affairs.


What I don't understand is why the overloads are not implemented 
with templates. Isn't this exactly the use case they were 
invented for?
Jun 05 2020
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Friday, 5 June 2020 at 19:39:26 UTC, Andrei Alexandrescu wrote:

 [snip]

 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.


I agree with you that more precision should be opt-in.

However, I have always been sympathetic to Walter's argument in 
favor doing intermediates at the highest precision. There are 
many good reasons why critical calculations need to be done at 
the highest precision possible.

In addition, the current PR to remove this behavior will make 
opt-ing in more difficult. Users will need to either put their 
own casts everwhere, or basically re-implement what is currently 
in std.math. It may be a good idea to release std.math in its 
current state as a separate module, similar to stdx.allocator, 
(the real versions can just call the real versions in phobos to 
reduce the maintenance cost). Shame to just get rid of it if 
there are some people who might use it as is.
Jun 05 2020
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/5/20 4:05 PM, jmh530 wrote:

 However, I have always been sympathetic to Walter's argument in favor 
 doing intermediates at the highest precision.


I have, too. But times have changed. That has aged poorly.
Jun 05 2020
prev sibling parent reply Nathan S. <no.public.email example.com> writes:
On Friday, 5 June 2020 at 20:05:56 UTC, jmh530 wrote:

 On Friday, 5 June 2020 at 19:39:26 UTC, Andrei Alexandrescu 
 wrote:

 [snip]

 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.


 I agree with you that more precision should be opt-in.

 However, I have always been sympathetic to Walter's argument in 
 favor doing intermediates at the highest precision. There are 
 many good reasons why critical calculations need to be done at 
 the highest precision possible.


I believe that decision was based on a time when floating point 
math on common computers was done in higher precision anyway so 
explicit `real` didn't cost anything and avoided needless 
rounding.

https://en.wikipedia.org/wiki/X87#Description


By default, the x87 processors all use 80-bit double-extended 
precision
internally (to allow sustained precision over many calculations, 
see IEEE
754 design rationale).
Jun 05 2020
parent =?iso-8859-1?Q?Robert_M._M=FCnch?= <robert.muench saphirion.com> writes:
On 2020-06-06 05:58:37 +0000, Nathan S. said:


 On Friday, 5 June 2020 at 20:05:56 UTC, jmh530 wrote:

 On Friday, 5 June 2020 at 19:39:26 UTC, Andrei Alexandrescu wrote:

 [snip]
 
 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.


 
 I agree with you that more precision should be opt-in.
 
 However, I have always been sympathetic to Walter's argument in favor 
 doing intermediates at the highest precision. There are many good 
 reasons why critical calculations need to be done at the highest 
 precision possible.


 
 I believe that decision was based on a time when floating point math on 
 common computers was done in higher precision anyway


It's still this way today, your statement reads as x87 is gone. It's not.


  so explicit `real` didn't cost anything and avoided needless rounding.


It's still the way today.

And one feature I like a lot about D is, that I have simple access to 
the 80-Bit FP precision. I would even like to have a 128-Bit FP, but 
Intel won't do it.

All the GPU, AI/ML hype is focusing on 64-Bit FP or less. There is no 
glory in giving up additional precision.

As already stated in this threa: Why not implement the code as 
templates and provide some pre-instantiated wrappers?

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster
Jun 09 2020
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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_ke
nel_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.
Jun 05 2020
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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_ke
nel_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.
Jun 04 2020
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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_ke
nel_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.)
Jun 04 2020
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/4/20 10:43 AM, Timon Gehr wrote:

 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_ke
nel_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.)


I think it means make Phobos be portable transparently.
Jun 05 2020
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/4/2020 7:40 AM, Timon Gehr wrote:

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


How about adding these as PRs to Phobos?
Jun 04 2020
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 05.06.20 05:37, Walter Bright wrote:

 On 6/4/2020 7:40 AM, Timon Gehr wrote:

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


 
 How about adding these as PRs to Phobos?


Their main feature is portability and I hacked them together quickly. 
They are unlikely to beat any given libc on other metrics. (e.g., sin 
and cos are based on cubic interpolation of large lookup tables, good 
enough to get somewhat close to full float precision.)

Ideally, the standard math functions in Phobos would be portable 
_because they give correct results_, like the basic arithmetic operators 
and the square root function in C99.

This seems promising, but I'm not sure what it's current state is: 
https://hal-ens-lyon.archives-ouvertes.fr/ensl-01529804/file/crlibm.pdf

Also, it's GPL, so we can't port it to Phobos directly:
https://gforge.inria.fr/scm/browser.php?group_id=5929&extra=crlibm
Jun 05 2020
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/4/20 10:40 AM, 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_ke
nel_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.


It's totally fine to version() things appropriately. In fact it's the 
best way - you get to version() in specific libc implementations known 
to be adequate.
Jun 05 2020
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 05.06.20 21:40, Andrei Alexandrescu wrote:

 On 6/4/20 10:40 AM, 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_ke
nel_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.


 
 It's totally fine to version() things appropriately. In fact it's the 
 best way - you get to version() in specific libc implementations known 
 to be adequate.


I think the issue was that different implementations were inadequate in 
different ways.
Jun 05 2020
prev sibling next sibling parent reply kinke <kinke gmx.net> writes:
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...).
Jun 04 2020
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Jun 04 2020
next sibling parent reply kinke <kinke gmx.net> writes:
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/
ath.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.
Jun 04 2020
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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"??
Jun 04 2020
parent reply kinke <kinke gmx.net> writes:
On Thursday, 4 June 2020 at 17:41:06 UTC, H. S. Teoh wrote:

 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?


The reason is one click away, in the PR description. ;) - A 
3rd-party project tested by BuildKite needs a new release 
(already adapted).
Jun 04 2020
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Jun 04, 2020 at 05:45:01PM +0000, kinke via Digitalmars-d wrote:

 On Thursday, 4 June 2020 at 17:41:06 UTC, H. S. Teoh wrote:

 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?


 
 The reason is one click away, in the PR description. ;) - A 3rd-party
 project tested by BuildKite needs a new release (already adapted).


[...]

So that means this is landing as soon as the 3rd party new release is
out?  Finally?


T

-- 
Democracy: The triumph of popularity over principle. -- C.Bond
Jun 04 2020
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 6/4/20 1:16 PM, kinke 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/
ath.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.


Excellent, I see Walter has approved these yesterday. What's the next step?
Jun 05 2020
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
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
Jun 04 2020
parent Guillaume Piolat <first.last gmail.com> writes:
On Thursday, 4 June 2020 at 17:25:51 UTC, jmh530 wrote:

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


Things like llvm_pow and llvm_exp actually defers to libc IIRC.
So the results varies a bit from libc to libc. And is also 
slightly different from phobos. ^^

Complicated stuff if one want to be perfectly backwards 
compatible.

Example:

     // Gives considerable speed improvement over `std.math.exp`.
     // Exhaustive testing for 32-bit `float` shows
     // Relative accuracy is within < 0.0002% of std.math.exp
     // for every possible input.
     // So a -120 dB inaccuracy max, and -140dB the vast majority 
of the time.
     alias fast_exp = llvm_exp;

This is with the Microsoft C runtime, haven't tested others.
So, this one looks relatively safe to use, -140dB is as good as 
you can go with float, but for other transcendental is might be a 
bit more shakey.

The ideal transcendental would be
    - faster than libc
    - same precision on all platforms
    - specialized by float/double size
    - within a given margin of the truth (in ulp)
Jun 06 2020
prev sibling parent reply data pulverizer <data.pulverizer gmail.com> writes:
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/


If it's any help or informative I explicitly benchmark a 
selection of mathematics functions from `std.math`, 
`core.stdc.math`, and `LDC_intrinsic` here: 
https://github.com/dataPulverizer/DMathBench/blob/master/report.md
Jun 07 2020
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08.06.20 05:05, data pulverizer 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_ke
nel_matrix/fsr4w5o/ 


 
 If it's any help or informative I explicitly benchmark a selection of 
 mathematics functions from `std.math`, `core.stdc.math`, and 
 `LDC_intrinsic` here: 
 https://github.com/dataPulverizer/DMathBench/blob/master/report.md



 many important processes rely on their performance and accuracy.


This is true, but you only measured performance, not accuracy.
Jun 08 2020
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jun 08, 2020 at 08:13:20PM +0200, Timon Gehr via Digitalmars-d wrote:

 On 08.06.20 05:05, data pulverizer 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/
 


 
 If it's any help or informative I explicitly benchmark a selection
 of mathematics functions from `std.math`, `core.stdc.math`, and
 `LDC_intrinsic` here:
 https://github.com/dataPulverizer/DMathBench/blob/master/report.md


 

 many important processes rely on their performance and accuracy.


 
 This is true, but you only measured performance, not accuracy.


Case in point: the `sin` intrinsic in dmd is broken, because it uses the
x87 fsin instruction, which is buggy:

	https://issues.dlang.org/show_bug.cgi?id=15854

Certainly, using fsin is faster than a software implementation of
sin(x), but at the cost of a pretty badly-off result.


T

-- 
Do not reason with the unreasonable; you lose by definition.
Jun 08 2020