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.

Reply via email to