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