(j3.2006) Liaison to IFIP WG 2.5
Tue Aug 21 16:14:15 EDT 2007
On Tue, 2007-08-21 at 10:43 -0500, Bill Long wrote:
> > Van wrote
> > Doing it in software at the source level, with Intel 80x86
> > processors and the Fortran IEEE support, imposes about 100x
> > (not %) penalty.
> SUN has a software implementation, and I can't imagine the performance
> is that bad. I suspect this 100X estimate is way off base. I'd
> guess more like 2X.
Don't overlook "in software at the source level, with Intel 80x86
processors and the Fortran IEEE support." By "source level" I mean in
Fortran, not by hand-optimized code tailored to an intrinsic type. Even
with the more aggressive optimizations Sun has at their disposal by
using an intrinsic type, I suspect the penalty would be substantially
more than 2X on Intel hardware, since changing the rounding mode flushes
the pipeline. Sun may be getting close to 2X on their own hardware if
they can change the rounding mode without flushing the pipeline. For
array operations, one might approach 2X even on Intel hardware by doing
the "round to -infinity" on a bunch of elements, then change the
rounding mode to "round to +infinity" and do it again on the same
elements. Assembling the results also takes some time, since there are
nine cases for multiply and 14 for divide.
Ulrich claims 100X is not an estimate, but a measurement.
Van Snyder | What fraction of Americans believe
Van.Snyder at jpl.nasa.gov | Wrestling is real and NASA is fake?
Any alleged opinions are my own and have not been approved or
disapproved by JPL, CalTech, NASA, the President, or anybody else.
More information about the J3