Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!gatech!prism!loligo!mccalpin From: mccalpin@loligo.cc.fsu.edu (John McCalpin) Newsgroups: comp.arch Subject: Re: Query about miserable M68882 performance [really 80-bit notes] Message-ID: <572@loligo.cc.fsu.edu> Date: 8 Apr 89 17:28:42 GMT References: <7829@pyr.gatech.EDU> <16543@winchester.mips.COM> <81@radix> Reply-To: mccalpin@loligo.cc.fsu.edu (John McCalpin) Organization: Supercomputer Computations Research Institute Lines: 31 In article <81@radix> jimv@radix.UUCP (Jim Valerio) writes: >The LINPACK benchmark reports on the error of the arithmetic operations. >Here are the results when run on the 80960KB > norm. resid resid machep >Double precision (extended) 1.50 6.66e-14 2.22e-16 >Double precision (double) 1.67 7.46e-14 2.22e-16 I assume that "extended precision" refers to the 80-bit format commonly used in the 80x87 family - is this correct? >Some months ago, John McCalpin (mccalpin@loligo.fsu.edu) reported in ><350@loligo.fsu.edu> some results from the 1000x1000 LINPACK benchmark >that might confirm the same observation using results from the Sun 3/280. >I say might because I am just presuming the results were run with an 68881, >and may or may not have been compiled using an extended-precision evaluation >model. Jim Valerio jimv%radix@omepd.intel.com The original test was run with the Weitek FPA, since that is what people are going to use for number-crunching. I did verify that the Sun passed the Paranoia test suite with all three floating-point options (Wietek, 68881, and software). I actually forgot about the extended-precision stack of the 68881 when I ran the tests. I am re-running the 32-bit case now to see how much the extended precision changes the RMS error of the solution. -- ---------------------- John D. McCalpin ------------------------ Dept of Oceanography & Supercomputer Computations Research Institute mccalpin@masig1.ocean.fsu.edu mccalpin@nu.cs.fsu.edu --------------------------------------------------------------------