Re: Making Lemonade (Floating-point format changes)

On 5/13/2024 7:16 AM, Michael S wrote:

On Sun, 12 May 2024 20:55:03 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:
 

John Dallman <jgd@cix.co.uk> schrieb:

In article <abe04jhkngt2uun1e7ict8vmf1fq8p7rnm@4ax.com>,
quadibloc@servername.invalid (John Savard) wrote:
 

I'm not really sure such floating-pont precision is useful, but I
do remember some people telling me that higher float precision is
indeed something to be desired.

>

I would be in favour of 128-bit being available.

>
Me, too.  Solving tricky linear systems, or obtaining derivatives
numerically (for example for Jacobians) eats up a _lot_ of precision
bits, and double precision can sometimes run into trouble.
>
At least gcc and gfortran now support POWER's native 128-bit format
in hardware.  On other systems, software emulation is used, which
is of course much slower.
>

 Much slower?
I think, at least for matrix multiplication, my emulation on modern x86
was within factor of 1.5x from your measurements on POWER9. And that
despite rather poorly chosen ABI for support routines. With better ABI
(pure integer, with no copies from/to XMM slowing things down, esp. on
Zen3) I would expect it to be a wash.
With slightly higher-level API, (qaxpy instead of individual mul/add)
a software can actually pull ahead.
 

IME, the cost of doing floating point in software isn't so bad so long as one has integer types larger than the mantissa (and an OK way to perform a widening multiply and take the high-order results).
So, for Binary64, one needs 64-bit integers, and for Binary128, 128-bit can somewhat help (though, AFAIK, x86-64 still doesn't have any 128-bit integer ops; and is a little awkward in some ways).
Emulation via traps is very slow, but typical for many ISA's is to just quietly turn the soft-float operations into runtime calls.
...

I'm not sure my field
has need for 256- or 512-bit, but that doesn't mean that nobody
has.

>
I've finally found the time to play around with Julia in the last
few weeks.  One of the nice things does is that you can just use
the same packages with different numerical types, for example for
ODE integration.  Just set up the problem as you would normally
and supply an starting vector with a different precision.
>
So, for doing some experiments on numerical data types, Julia
is quite nice.

 It's a pity that something like that is not available in GNU Octave.