karl@sugar.UUCP (Karl Lehenbauer) (07/12/88)
Readers of the report summarizing Dhrystone benchmark performance of many
computers in comp.arch may notice that many machines based on the Intel
80286 performed extraordinarily well in the tests, exceeding the performance
of low-end Vaxes, 68000s, etc, and approaching the peformance of 386 machines.
This runs strongly counter to my personal experience with these machines.
So, why does the 286 perform so well on this "typical C program" benchmark?
I think it's because the Microsoft C compiler is getting really good and
because the Dhrystone fails to cause any sort of segment thrashing.
Readers are directed to the June 1988 issue of (gack) Byte magazine, Table
3 on page 220. In it, the deservedly much-maligned Sieve benchmark is run
with varying array sizes. As the array passes the 32K boundary,
performance for the 8086 and 80286 declines sharply, while the others
continue to increase at a steady rate. An excerpt follows:
Array size 20000 40000
Machine (bytes) time (secs)
Turbo-Amiga 1.14 2.32
VAX 8600 1.19 2.64
VAX-11/780 3.04 6.38
Amiga 5.68 11.50
VAX-11/750 6.11 13.13
IBM PC AT 8.13 99.71
^^^^^
I'd like to see a future version of Dhrystone include a something like this,
whereby a certain amount of processing of an array is performed for different
array sizes, so that the thrashing nature small segmented architectures
exhibit when running large programs will be demonstrated. (While the
Dhrystone rating for the Mylex 16-Mhz 386/AT replacement motherboard running
native-mode 386 Unix is only about three times faster than an 8-Mhz Everex 286
running 286 Unix, timing things such as makes of news and smail have shown the
386 to be nine to ten times faster according to CPU statistics as reported by
"time" and by wall time.)
--
-- uunet!sugar!karl
-- These may be the official opinions of Hackercorp -- I'll have to ask Peter.lamaster@ames.arc.nasa.gov (Hugh LaMaster) (07/14/88)
In article <2294@sugar.UUCP> karl@sugar.UUCP (Karl Lehenbauer) writes: >computers in comp.arch may notice that many machines based on the Intel >80286 performed extraordinarily well in the tests, exceeding the performance >of low-end Vaxes, 68000s, etc, and approaching the peformance of 386 machines. >This runs strongly counter to my personal experience with these machines. > VAX-11/750 6.11 13.13 > IBM PC AT 8.13 99.71 >I'd like to see a future version of Dhrystone include a something like this, >whereby a certain amount of processing of an array is performed for different >array sizes, so that the thrashing nature small segmented architectures Rather than try to make Dhrystone the all inclusive benchmark, why not simply treat it for what it is: a simple test of CPU (as opposed to system) speed on simple branch, procedure call, and character intensive code. A much more serious criticism of Dhrystone, and many old and/or simple benchmarks, is that because there is no appearance to a smart compiler of output which depends on execution time calcutions, many smart optimizing compilers may start optimizing all the work away. This used to be a problem even on earlier compilers, such as the FTN compiler on the CDC 7600, in basic blocks inside loops. Globally optimizing compilers make the problem worse. You really need to compute something to print out which depends on all previous calculations in order to solve the problem completely. -- Hugh LaMaster, m/s 233-9, UUCP ames!lamaster NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 Phone: (415)694-6117
davidsen@steinmetz.ge.com (William E. Davidsen Jr) (07/15/88)
There is a common belief that something bad happens on a 286 when the
size of an array becomes greater than 64k. This is not true; it happens
when you use large or huge model. Therefore, rather than ask the
Dhrystone but modified to use other array sizes, you can just compile in
the model to be tested and get the info you want, making the 286 look as
bad as you please.
Here are some runs I made using Dhrystone 1.0 on a 286:
value flags
1220 none
1724 -Ox
877 -Ox -M2l
As you can see the use of large model cuts the performance in half. Why
change the benchmark when you can get the info in another way?
--
bill davidsen (wedu@ge-crd.arpa)
{uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me