32bit vs 64bit

[Anders Melander 1783]

8 hours ago, pcoder said:

Also, not to forget the existing large number of functions with extended precision, most notably amath.pas

Sorry to hijack the topic but:

1. Wow! I had completely forgotten about that gem of a library.
2. There's a Double version to ease the transition: damath.pas
3. Can someone explain the following from the readme for me:

   Quote

   Note for FreePascal users: The 3.x versions support a new optimization level -O4 (-O3 + optimizations which might have unexpected side effects).
   For AMath/DAmath the so-called FASTMATH optimization is relevant:
   Among others floating point division by constants may be replaced by multiplication with the inverse, leading to quotients which are sometimes not correctly rounded!
   This obviously conflicts with the design goal of accurate computing and I recommend to turn off this feature using {$OPTIMIZATION NOFASTMATH} or with command line option -OoNOFASTMATH!

   Why aren't they correctly rounded? I ask because it's an optimization technique I use a lot.

[David Heffernan 2345]

1 hour ago, Anders Melander said:

1. Why aren't they correctly rounded? I ask because it's an optimization technique I use a lot.

Well, because a/b is not necessarily equal to (1/b)*a. This is because a/b is defined by IEEE754 to be the closest representable value to the true value of a/b. Then (1/b) is the closest representable value to the true value. And then (1/b)*a is closest representable etc etc. So (1/b)*a has two roundings a/b has just one. 

 

In many applications these fastmath approximations are perfectly acceptable, but of course there are applications where this is a problem.

Edited September 13, 2022 by David Heffernan

[pcoder 4]

On 9/13/2022 at 1:33 PM, David Heffernan said:

I believe that the bulk of numerical computing doesn't need more than double. Is that not the case?

The bulk of business apps probably, but academic fields should not be neglected.
The general trend is that standard C-runtimes (see libc) implement float80, float128 to be cross-platform (hardware- and software-based).
And C standard recommends "long double" to be the largest of float128, float80, float64.
A useful overview of current accuracy state is here. (GNU libc and Intel Math Library (libmmd.dll) support float128)

Edited September 21, 2022 by pcoder

[David Heffernan 2345]

1 hour ago, pcoder said:

The bulk of business apps probably, but academic fields should not be neglected.
The general trend is that standard C-runtimes (see libc) implement float80, float128 to be cross-platform (hardware- and software-based).
And C standard recommends "long double" to be the largest of float128, float80, float64.
A useful overview of current accuracy state is here. (GNU libc and Intel Math Library (libmmd.dll) support float128)

How are you going to implement a BLAS efficiently on today's hardware? What processors do you know of with efficient FPUs that handle more than float64? Forgive me if I am ignorant. 

 

I'm not talking about business apps. I develop a structural FEA code for engineers. Double precision is all that is required. 

Edited September 21, 2022 by David Heffernan

[pcoder 4]

For mainstream computers only legacy FPUs exist (co-exist) for more precision. But the point is, speed per operation only matters if the number of operations is large. This is similar to the existence of int64 on cpu32.  And many math operations (including BLAS) can have use-cases for more than double-precision.

 

The conclusion remains: libraries can be used if Delphi does not support float80. Some compilers (gcc, icc, fortran compilers) have this built-in and Delphi could follow. The main trend (without pure GPU solutions) is that floating point operations use SIMD instructions for all precisions.
Additionally, complex operations on float128 values can much profit from specific algorithms (eg. matrix multiplication from Ozaki scheme).

[David Heffernan 2345]

1 hour ago, pcoder said:

For mainstream computers only legacy FPUs exist (co-exist) for more precision. But the point is, speed per operation only matters if the number of operations is large. This is similar to the existence of int64 on cpu32.  And many math operations (including BLAS) can have use-cases for more than double-precision.

 

The conclusion remains: libraries can be used if Delphi does not support float80. Some compilers (gcc, icc, fortran compilers) have this built-in and Delphi could follow. The main trend (without pure GPU solutions) is that floating point operations use SIMD instructions for all precisions.
Additionally, complex operations on float128 values can much profit from specific algorithms (eg. matrix multiplication from Ozaki scheme).

 

From what I can see, for the hardware that Delphi runs on, float64 is the largest float that can be operated on efficiently with CPU hardware instructions.  float80 is available in the x87 unit, but x87 is very inefficient on modern processors.

 

Do you know how float128 is implemented by compilers like gcc on x64 hardware?  It's done in software.  Presumably therefore it is slow.

 

What real-world applications do you know of that require float128?

[Joseph MItzen 251]

Why does this seem to just be a Delphi thing, insisting we still use 32bit even though it's been about 19 years since the first 64bit x86 chip was announced? Why is embracing modernity a bad idea to you? You can't buy 32bit CPUs anymore, 32bit OSes are disappearing - even with Linux, etc. Just recompile your code and move on I say.

[Joseph MItzen 251]

On 9/12/2022 at 12:30 PM, Stefan Glienke said:

Carriages also once were the fastest way to travel - yet nobody today complains that he can't go onto the highway with one.

Except the Amish.

[Fr0sT.Brutal 900]

On 9/27/2022 at 12:13 AM, Joseph MItzen said:

Why is embracing modernity a bad idea to you?

Maybe because many software just doesn't need to switch when things are working fine already?