lu@blake.acs.washington.edu (Joseph Lu) (05/05/89)
We just got DN10000 recently and experienced only 5-6 times faster than DN4000 for our 5 different Fortran applications (mainly floating point calculations) with -OPT 3 or 4. That speed is far away from the Apollo official figures. The configuration of DN10000 is 1 CPU with 32 MK memory running SR10.01.P Anyone out there experienced the same thing? Or what the right speed enhance- ment should we expect? Thanks in advance. -- UU UU WW WW | Chemical Eng. @ University of Washingtom (UW), Seattle UU UU WW W WW | LU@Max.acs.Washington.edu (206)-543-5419 (o) UU UU WW WWW WW | LU@Max.Bitnet UUUUU WWWW WWWW | LU@Blake.acs.Washington.edu
seibel@cgl.ucsf.edu (George Seibel) (05/05/89)
In article <1894@blake.acs.washington.edu> lu@blake.acs.washington.edu (Joseph Lu) writes:
]We just got DN10000 recently and experienced only 5-6 times faster than DN4000
]for our 5 different Fortran applications (mainly floating point calculations)
]with -OPT 3 or 4. That speed is far away from the Apollo official figures.
]
]The configuration of DN10000 is 1 CPU with 32 MK memory running SR10.01.P
]
]Anyone out there experienced the same thing? Or what the right speed enhance-
]ment should we expect?
]
]Thanks in advance.
I'm not specifically familiar with the DN10000, but your complaint is
typical of many, so I'll offer a few general comments: (and these are
not aimed at Apollo, but *all* vendors)
- Welcome to the real world. It is the job of marketing types to present
their machine in the best possible light. This they will do, usually
without lying. It is the job of *Sales* people to sell the machine.
No comment on what they might say...
- How far away *is* this performance from the "official" figures? If
the numbers Apollo quotes are for 32 bit integer ops, and you're
doing 64 bit floating point, that might explain a lot.
- Are your applications appropriate for the architecture? Have you ever
profiled them? (try man prof) A simple profile may tell you a lot
about why your programs are slow.
- It's always a good idea to benchmark before you buy, using *your* code
and *your* data.
George Seibel, UCSF