Re: Making Lemonade (Floating-point format changes)

On Mon, 13 May 2024 19:01:37 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

Michael S <already5chosen@yahoo.com> schrieb:

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. 

 
I don't remember the exact timing, and it might be interesting to
revisit that (also considering that the

IIRC, you reported something like 200 (or 300?) MFLOPS for your matrix
multiplication benchmark running on a single POWER9 core.

I got ~150 MFLOPS running on EPYC3 at relatively low frequency (3.6
GHz) using my plug-in replacements for gcc __multf3/__addtf3 with the
level of support for FP exceptions and rounding modes that, according
to you, is sufficient for Fortran, but according to other gnu
maintainers is insufficient for C. For matrix multiplication
implemented with vector APIs ('multiply vector by scalar' and 'add
vectors') on the same EPYC3 I got approximately 200 MFLOPS.

gfortran code for matmul is
not optimized for 128-bit float and might have blown cache sizes,

That's possible, but unlikely to make a major impact.
At 200 MFLOPS even L3 cache is not a bottleneck. And it's actually hard
to code matrix multiplication so poorly that at least half of data
wouldn't come from L1D/L2. I took a look at GFortran sources for matmul
- they are not that bad.

plus it would be fair to compare compiler vs. compiler and assembler
vs. assembler).
>

My routines are implemented in 'C' and compiled with gcc

I just looked it up - on POWER9, xsaddqp has 12 cycles of latency,
with one result per cycle, POWER10 has 12 to 13 cycles with two
results per cycle.

So, a bottleneck is somewhere else. May be, multiplication?

 
What can your code get on x86_64?

Se above.