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.