Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: Making Lemonade (Floating-point format changes)
Date: Mon, 13 May 2024 15:16:47 +0300
Organization: A noiseless patient Spider
Lines: 48
Message-ID: <20240513151647.0000403f@yahoo.com>
References: <abe04jhkngt2uun1e7ict8vmf1fq8p7rnm@4ax.com>
	<memo.20240512203459.16164W@jgd.cix.co.uk>
	<v1rab7$2vt3u$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 13 May 2024 14:16:53 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="7197117e8777d671747ea2f1d15c6790";
	logging-data="3637781"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18x+8qTQmme1xcoRLnAfLVy0VS0l8W4uJY="
Cancel-Lock: sha1:YAgrKt/s7fZrBMkPel9OLs2wrFk=
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
Bytes: 2995

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.

> >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.