root@hammer.UUCP (System PRIVILEGED Account) (02/14/90)
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?
thompson@batcomputer.tn.cornell.edu (Steve Thompson) (02/14/90)
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? 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. For both programs, the VAXstation (VMS) compiles about 7 times faster than the DECstation (yes, 7). Steve
jet@karazm.math.uh.edu (J. Eric Townsend) (02/14/90)
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? Another question. Using a Fortran compiled executables in double precision are more than 5 times as slow as single precsion... Any ideas? This is for something that's definately out of cache, fyi. -- J. Eric Townsend University of Houston Dept. of Mathematics (713) 749-2120 jet@karazm.math.uh.edu Skate UNIX(tm).
bcw@rti.UUCP (Bruce Wright) (02/14/90)
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? > > 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). My guess (since the DECstation is generally considered to be faster) is that is that either the DECstation memory is underconfigured or the compiler isn't as intelligent as the VMS compiler. Comments? Bruce C. Wright
GEOMAGIC@kcgl1.eng.ohio-state.edu (Daniel OConnell) (02/14/90)
(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? > > 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). >My guess (since the DECstation is generally considered to be faster) >is that is that either the DECstation memory is underconfigured or >the compiler isn't as intelligent as the VMS compiler. >Comments? > Bruce C. Wright I have used both (VAX3100 and DEC3100) and a DEC5400. If you have enough memory (sometimes a big if) the DEC3100 is 4 times faster executing a number crunching program, period! Otherwise, which system swaps faster?! (Ugh). If you don't use full F77 optimization on the DEC3100 (-O2), it compiles faster than the VAX3100 fortran compiler. Such code runs ~50% slower however. When you use full optimization you had better have LOTS of memory. I had a 2000 line main program that sent F77 into swap oblivion on a 16M DEC3100 and barely cleared through the 32M 5400 without swapping. Took 10 minutes vs 13 seconds for default (-O1) optimization. Some crunching benchmarks for your info. Let a VAX8550 = 1.0 (higher numbers will indicated how much faster) DEC3100 = 2.0 DEC5400 = 2.5 CRAY-YMP = 5.0 (scalar) P.S. Ultrix sucks, but it sucks fast. Dan O'Connell geomagic@geo1s.mps.ohio-state.edu
willis@cs.AthabascaU.CA (Tony Willis) (02/15/90)
In article <1990Feb14.000213.6413@lavaca.uh.edu>, jet@karazm.math.uh.edu (J. Eric Townsend) 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? > > > Another question. Using a Fortran compiled executables in double precision > are more than 5 times as slow as single precsion... > > etc. Well, I've run the linpack benchmarks on my DECstation 3100; in single precision its about a 1.5 MFLOP machine and in double precision its about 1 MFLOP. Tony Willis BITNET: twillis@nrcdra.bitnet CDNNET: twillis@drao.nrc.ca, or willis@cs.athabasacau.ca
rogerk@mips.COM (Roger B.A. Klorese) (02/15/90)
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
lutmann@geocub.greco-prog.fr (02/16/90)
In article <9711@batcomputer.tn.cornell.edu> thompson@tcgould.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? >[...] >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. >[...] >Steve Hi! What's the MC code? What's the MD code? Thanks, Johan.