Re: FWD: FLOATING-POINT CONSISTENCY, -FFLOAT-STORE, AND X86

[Edward Jason Riedy <ejr at CS dot Berkeley dot EDU>]

Oh well.  And Toon Moene writes:
 - 
 - Am I the only one - apart from Harvey J. Stein and Tim Prince - who
 - finds this whole discussion unreal ?  Surely, 80 bit temporaries might
 - seem a neat hack to a numerical analyst like Dr. Kahan, but the ordinary
 - computational physicist or chemist knows better than to choose "poorly
 - conditioned" algorithms.

In my experience, that is not true.  I've seen many computational
chemists never check the condition numbers of their matrices, toss
them into pre-packaged routines (EISPACK, even), and then present 
eigenvalues as being more precise than they are.  It's not done 
intentionally; they just don't know better.  (Which is perfectly 
reasonable.  Ask me about equivalent difficulties in chemistry and 
I'll be clueless.)

Also, you can use genuinely _better_ algorithms when you can rely on 
something very close to IEEE, and that is currently pretty hard on 
x86 with gcc.  And a touch of extended precision can really lead to 
algorithms that give huge performance improvements (factors of 20-40
for normal eqns. v. QR for least squares), although those examples
are beyond the current discussion.

And Mr. Buck's example does happen in real code.

 - My main concern is that there is a grid spacing that will render the
 - basic equation of geostrophy badly approximated in 32-bit arithmetic:

And at the moment, that entirely depends on which variables happen
to be spilled and which don't.  Spilling 80-bit units won't hurt
your app in accuracy.  Take the fact that you've never run into the
problem as evidence that your current discretization is fine.

 - The last thing I need is to have egcs slowed down to a crawl by having
 - it spill unaligned 80-bit temporaries for something that shouldn't be
 - larger than 32 bits in the first place.

If they're aligned, it won't slow down much (I think) on real machines.
The extra alignment will cause it to eat 128 bits in cache rather than
32 bits, but I've been told most differential equation solvers aren't
as picky about cache as linear solvers (my area).  Yours may be 
different.  And I believe Mr. Buck is only looking at spills _within
single expressions_.  It's quite possible your app doesn't have any,
in which case you won't be bothered at all.

Anyways, I'll shut up until I at least know what would need modified
to implement 80-bit spills.  I think they're a good start and probably
just what most people need.

Jason