🚀 go-pugleaf

[ Furio Ercolessi ]

| But if i remember correctly the original post (there is a bit of it above), the
| question was "can we have 128-bit float support in your compilers" ?

Thanks for getting the discussion back on track!  It had drifted somewhat:  At
one point, someone even started talking about 128-bit *integers*, which is of
no concern to me, and which hadn't been mentioned at all in my original article.
(Gee, I didn't think that my writing style was *that* ambiguous! :-)

[ John Mashey ]

| 4) IF you think you really need 128-bit FP, it would probably help us to
| post/email what you're doing.  Of course, if you were to post that you would
| buy $100Ms of computers because of this feature, more attention would
| be attracted :-)....  but seriously, we're interested in this area and willing
| to listen to people on it.

[ Furio Ercolessi ]

| I believe that having software support would still be very useful for
| development of numerical algorithms.  sometimes you need a 'reference run'
| to check the stability of differential equation solvers or whatever.
| you may not care if this reference run is slow.

Quite so.  Here's an excerpt from a message I've already sent John in reply,
discussing a local need for 128-bit FP; specifically, applications involving

 integrating simple ordinary differential equations for billions of timesteps.
 With the current IEEE double-precision standard, round-off error is a
 considerable problem in this field. Three or four years ago, for example, some
 Italian researchers wrote a long review article arguing that roundoff set a
 fundamental limitation on how far these integrations could be carried.  Since
 then, a reasonable workaround has been found: to carry out selected critical
 operations in quad precision by writing our own subroutines to do quad
 precision in fortran or c. This works because the critical operations are adds
 and subtracts, which take only 2 or 3 times longer in quad; multiplies and
 divides take at least a factor of 10 longer.  However, this workaround is not
 likely to work very well in the future, for two reasons:

 1. In the new, faster integration algorithms that are now being used we cannot
 isolate a few critical operations.

 2. As machines get faster, we do longer integrations and so the problem gets
 worse.

 128-bit FP would drive the roundoff problem down to an ignorable level; if
 128-bit were available within 2 or 3 times the speed of 64-bit most people
 would use it routinely. If it were 10 times slower most people would still use
 it to carry out short integrations as an accuracy check.

[ Furio Ercolessi ]

| so i would say, thanks hardware guys, don't worry about that,
| and perhaps it's now the time for compiler folks to jump on this thread :-)

Which, actually, was my original point.  Although an implementation of 128-bit
FP in silicon would be wonderful, all I'm hoping for at the moment is compiler
support:  Just because the R4xxx family doesn't (and perhaps never will?) have
128-bit FP support, this doesn't preclude the *compilers* from supporting it.
After all, UNIX supported 32-bit integers back in the late 1970s, on PDP-11s
which supported only 16-bit integers.  Now I'll grant that this would be a more
difficult problem than that was, but nonetheless I find it hard to believe that
it would be extraordinarily difficult, either.  And of course, the performance
might well be painfully slow compared to what we would have if the chip itself
supported 128-bit FP, but slow is better than nothing!

And, if you won't give us even *that*, could you at least make the (trivial?)
change to the C compiler so that sizeof(long double) is 16 rather than 8?  If
the low 64 bits are always zero, or always ignored, or whatever, at least this
would permit mixed-language {C,Fortran) applications to port a bit more easily.
(Of course one could argue that if one is porting an application that requires
128-bit FP, one shouldn't bother trying to run it on a platform that provides
only 64-bit FP support.  But that's an topic for a different newsgroup ...)

Mark Bartelt                                                     416/978-5619
Canadian Institute for                                  mark@cita.toronto.edu
Theoretical Astrophysics                                mark@cita.utoronto.ca

"Sheep not busy being shorn are busy frying"  -  Dylan, at a NZ lamb barbecue
             [ singing "It's all right, ma (I'm only bleating)" ]