Speed of math function atan: comparison D and C++

J-S Caux js at gmail.com
Tue Mar 6 08:20:05 UTC 2018


On Tuesday, 6 March 2018 at 07:12:57 UTC, Robert M. Münch wrote:
> On 2018-03-05 20:11:06 +0000, H. S. Teoh said:
>
>> 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,
>
> Hi, do you have a reference for this? I can't believe this, as 
> the 80-bit are pretty important for a lot of optimization 
> algorithms. We use it all the time and it's absolutly necessary.
>
>> and pretty much nobody cares to improve their performance on 
>> newer CPUs,
>
> Really?
>
>> 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.
>
> IMO this is all driven by the GPU/AI hype that just (seems) to 
> be happy with rough precision.

Speaking for myself, the reason why I haven't made the switch 
from C++ to D many years ago for all my scientific work is that 
for many computations, 64 bit precision is certainly sufficient, 
and the performance I could get out of D (factor 4 to 6 slower in 
my tests) was simply insufficient.

Now, with Uknown's trick of using the C math functions, I can 
reconsider. It's a bit of a "patch" but at least it works.

In an ideal world, I'd like the language I use to:
- have double-precision arithmetic with equal performance to C/C++
- have all basic mathematical functions implemented, including 
for complex types
- *big bonus*: have the ability to do extended-precision 
arithmetic (integer, but most importantly (complex) 
floating-point) on-the-fly if I so wish, without having to rely 
on external libraries.

C++ was always fine, with external libraries for extended 
precision, but D is so much more pleasant to use. Many of my 
colleagues are switching to e.g. Julia despite the performance 
costs, because it is by design a very maths/science-friendly 
language. D is however much closer to a whole stack of existing 
codebases, so switching to it would involve much less extensive 
refactoring.


More information about the Digitalmars-d-learn mailing list