On Mon, Mar 05, 2018 at 06:39:21PM +0000, J-S Caux via Digitalmars-d-learn wrote: [...] > I've tested these two very basic representative codes: > https://www.dropbox.com/s/b5o4i8h43qh1saf/test.cc?dl=0 > https://www.dropbox.com/s/zsaikhdoyun3olk/test.d?dl=0 > > Results: > > C++: > g++ (Apple LLVM version 7.3.0): 9.5 secs > g++ (GCC 7.1.0): 10.7 secs > > D: > dmd : 35.5 secs > dmd -release -inline -O : 29.5 secs > ldc2 : 34.4 secs > ldc2 -release -O : 31.5 secs > > But now: using the core.stdc.math atan as per Uknown's suggestion: > D: > dmd: 9 secs > dmd -release -inline -O : 6.8 secs > ldc2 : 10 secs > ldc2 -release -O : 6.5 secs <- best > > So indeed the difference is between the `std.math atan` versus the > `core.stdc.math atan`. Thanks Uknown! Just knowing this trick could > make the difference between me and other scientists switching over to > D... > > But now comes the question: can the D fundamental maths functions be > propped up to be as fast as the C ones?
Walter has been adamant that we should always compute std.math.* functions with the `real` type, which on x86 maps to the non-IEEE 80-bit floats. However, 80-bit floats have been deprecated for a while now, and pretty much nobody cares to improve their performance on newer CPUs, focusing instead on SSE/MMX performance with 64-bit doubles. People have been clamoring for using 64-bit doubles by default rather than 80-bit floats, but so far Walter has refused to budge. But perhaps this time, we might have a strong case for pushing this into D. IMO, it has been long overdue. I filed an issue for this: https://issues.dlang.org/show_bug.cgi?id=18559 If you have any additional relevant information, please post it there so that we can build a strong case to convince Walter about this issue. T -- Heuristics are bug-ridden by definition. If they didn't have bugs, they'd be algorithms.