Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!servitude!rogerk
From: rogerk@mips.COM (Roger B.A. Klorese)
Newsgroups: comp.sys.dec
Subject: Re: Question regarding DS3100 Floating Point
Keywords: FP coprocessor
Message-ID: <36028@mips.mips.COM>
Date: 15 Feb 90 05:21:04 GMT
References: <Feb.12.10.17.01.1990.23389@paul.rutgers.edu> <119@hammer.UUCP> <9711@batcomputer.tn.cornell.edu> <3566@rti.UUCP>
Sender: news@mips.COM
Reply-To: rogerk@mips.COM (Roger B.A. Klorese)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 60

In article <3566@rti.UUCP> bcw@rti.UUCP (Bruce Wright) writes:
>In article <9711@batcomputer.tn.cornell.edu>, thompson@batcomputer.tn.cornell.edu (Steve Thompson) writes:
>> In article <119@hammer.UUCP> jockc@idsila.com (Jock Cooper) writes:
>> >I have this ray tracing toy that runs faster on our MicroVax 
>> >(has FP coprocessor) than on my DECstation 3100. Does the 3100 
>> >have a Floating Point chip or what? Or is it an option?

As far as I know, all DECstations are built with the Mips R2010 Floating
Point Accelerator built in.

>> Well, I have two main applications that I run on a VAXstation 3100 and
>> a DECstation 3100, using the SAME source code in both cases (it's
>> fortran). They are a Monte Carlo and a Molecular Dynamics simulation
>> of a fluid stucture. The MC code is 10% faster on the VAXstation than
>> on the DECstation, and the MD code is 4 times faster on the DECstation.
>
>Differences this great on programs whose style of computing is probably
>reasonably similar (compared to programs using lots of strings or packed
>decimal) suggest either machine memory differences (that one of the
>machines is running out of memory and either paging to death or not
>able to create a large enough temporary store to achieve the maximum
>effect) or compiler differences (at least one of the programs has a 
>code sequence that one or the other compiler isn't able to optimize).

Actually, these particular results suggest another more likely result:
non-portable floating-point code combined with IEEE floating-point
behavior compared to the VAX floating point algorithms.

Point one: there's a lot of bad code in the universe that mixes the use
of REAL*4 and REAL*8 variables (float and double, to you C-folk).  On a
VAX, this produces reasonable results, since the only difference in the
formats is 32 extra bits of precision.  On an IEEE floating point
machine, the formats are different, so that a mistaken use of a number
produces incorrect results (and, typically, non-convergence in iterative
programs).

Try this code on your VAX and on your RISC:

      REAL*8 FUNK
      PRINT *,FUNK()
      STOP
      END

      FUNCTION FUNK
      FUNK=1.0
      RETURN
      END

Point two: the default actions for handling underflow, overflow, imprecise
results, etc. are different in the two implementations.  A good hint would be
to time your program on the DECstation, and look at the "system time" 
components.  If system time is very high on the DECstation, your Digital
service folks should be able to help you find the routines which are
producing results which require handling by software floating point
interrupt handler code.
-- 
ROGER B.A. KLORESE      MIPS Computer Systems, Inc.      phone: +1 408 720-2939
MS 4-02    928 E. Arques Ave.  Sunnyvale, CA  94086             rogerk@mips.COM
{ames,decwrl,pyramid}!mips!rogerk
"Two guys, one cart, fresh pasta... *you* figure it out." -- Suzanne Sugarbaker