CSvax:Pucc-H:Physics:suitti@pur-ee.UUCP (07/22/83)
#R:wjh12:-26100:pur-phy:12700015:000:1941 pur-phy!suitti Jul 22 10:44:00 1983 Beware the (byte) prime number benchmark. "Almost as fast as a 780" is VERY misleading. It turns out that coding the sieve using bytes for each cell is a loss (in speed) on the 780. In fact, I was unable to make an assembly code version run as fast on the 780 as (my own) assembly code for the PDP-11/70. The reason is simple: Though the VAX has a nice byte archetecture (instruction set, addressing modes) it is implemented as a 32 bit word machine. A byte write is done as a read-modify-write operation in microcode. Calling the array "int" rather than char should (but I haven't tried) speed up the VAX. Also, a very small number of differant instructions are executed (to 80% of the time) in such a benchmark. Even though this is typical of many long running programs, it will usually be a differant set of instructions than this benchmark. This particular benchmark is designed to compare microprocessors using something that they are all relatively good at - byte manipulations with one dimensional arrays. I run a PDP 11/44. For most things, the VAX is 4 times as fast. It isn't for that program. How does your processor do at a matrix multiply? How does it fair doing an "nroff" under similar conditions? We have two Fortran compilers for this machine. One of these produces code which runs twice as fast as the other. The UNIX VAX Fortran runs nearly half the speed of the VMS Fortran. Therefore, one should benchmark the whole system, rather than just the machine. My experience to date is: machine relative speed VAX 780 1.0 PDP 11/70 0.4 PDP 11/44 0.25 These are very approximate. Note that these are all "mini-computers", meaning multiuser machines. In this environment, the choice of a disk subsytem or the amount of RAM can make or break it's true performance. The are all hard disk systems with RAM to spare. Stephen Uitti (physics site manager) ...pur-ee!Physics:suitti ...purdue!Physics:suitti