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
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
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
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
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
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
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
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
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
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. Mnch http://www.saphirion.com smarter | better | faster
Jun 09
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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