gemini@homxb.UUCP (02/02/87)
#! /bin/sh
# This is a shell archive, meaning:
# 1. Remove everything above the #! /bin/sh line.
# 2. Save the resulting text in a file.
# 3. Execute the file with /bin/sh (not csh) to create:
# announce.doc
# report.doc
# submit.doc
# submit.frm
# clarify.doc
# dry.c
# database.doc
# dry.db
# This archive created: Mon Feb 2 07:10:28 1987
export PATH; PATH=/bin:/usr/bin:$PATH
if test -f 'announce.doc'
then
echo shar: "will not over-write existing file 'announce.doc'"
else
cat << \SHAR_EOF > 'announce.doc'
These files comprise the 01/31/87 distribution of the collected
Dhrystone Benchmarks.
Enjoy.
Rick Richardson
PC Research, Inc.
ihnp4!castor!pcrat!rick
attmail!rrichardson
(201) 834-1378, (201) 918-0432, (201) 922-1134
SHAR_EOF
fi
if test -f 'report.doc'
then
echo shar: "will not over-write existing file 'report.doc'"
else
cat << \SHAR_EOF > 'report.doc'
DHRYSTONE 1.1 BENCHMARK SUMMARY
Sat Jan 31 22:40:34 EST 1987
SORTED BY MANUFACTURER
MANUF MODEL PROC CLOCK NOREG REG OS,COMPILER,NOTES
----- ----- ---- ----- ----- --- -----------------
Gridcase 3 80C86 4.77 409 438 MS-DOS 2.11,Microsoft 3.01 ,
APOLLO DN330 68020/68 12.50 1934 1934 Domain/IX SR9.5.Bl12,CC 4.58 w/o 020,68881,(Beta OS and Compiler)
APOLLO DN330 68020/68 12.50 2046 2046 Domain/IX SR9.5.Bl12,CC 4.58 w/020,68881,(Beta OS and Compiler)
APOLLO DN3000 68020/68 12.50 2481 2481 Domain/IX SR9.5.Bl12,CC 4.58 w/o 020,68881,(Beta OS and Compiler)
APOLLO DN3000 68020/68 12.50 2643 2643 Domain/IX SR9.5.Bl12,CC 4.58 w/020,68881,(Beta OS and Compiler)
AT&T 3B2/300 32000 7.20 409 410 UNIX SVR2.0,cc ,
AT&T 3B5 WE32000 10.00 578 573 UNIX SVR2 5.2.0.1 V2,cc ? large,
AT&T 3B2/310 32100 0.00 668 671 UNIX SVR2.4,cc ,
AT&T 3B2/300 32000 7.20 685 688 UNIX SVR2.0.4,cc ,
AT&T 3B2/300 32000 7.70 699 697 UNIX SVR3.0,cc ,
AT&T UNIX PC 68010 10.00 973 1034 UNIX 5.0.3,cc ,
AT&T 3B2/400 32100 10.00 1108 1120 UNIX SVR2.0.4,cc ,
AT&T 6300 PLUS 80286 6.00 1225 1225 UNIX SVR2 vC3,cc ,
AT&T 3B15 32100 14.00 1797 1798 UNIX 5.2.1,cc ,
ATI 2000 80286 8.00 1440 1440 UNIX Microport SVR2,cc large,0 wait state AT clone
ATI 2000 80286 8.00 2145 2145 UNIX Microport SVR2,cc small,0 wait state AT clone
Altos Comp ACS 68000 68000 8.00 440 450 UNIX System III, Altos Release 2.0,cc --,
Amdahl 5860 0.00 28735 28846 UTS V,cc 1.22 ,
Amiga 1000 0.00 643 684 ,Manx C 2.30a ,32 bit int
Amiga 1000 0.00 880 915 ,Manx 2.30a ,16 bit int
Apollo DN330 68020 12.50 1504 1504 Domain/IX ,cc 4.08 w/o 020,
Apollo DN330 68020 12.50 1677 1677 Domain/IX ,cc 4.08 w/ 020,
Apple IIe 65C02 1.02 37 37 DOS 3.3,Aztec CII v1.05i ,
Apple Lisa 2/10 68000 5.00 505 533 XENIX 3.0 Priam,cc ,
Apple Macintosh 68000 8.00 510 549 Mac Finder 5.1, System 3.2,LightSpeed C 1.02 ,with new, 128K ROMs
Apple Lisa 68000 0.00 517 550 UniPlus Sys V,cc ,
Apple Macintosh 68000 7.70 625 625 Mac ROM ,DeSmet ,
Apple Mac+ 68000 7.80 714 769 Mac 3.2,Manx 1.06H ,16 bit int
Apricot portable 8086 5.00 375 400 MS-DOS 2.11,Microsoft 3.01 ,
Arete 1100/1200 68020 12.00 2741 2808 UNIX SVR2.2,Motorola pcc2 ,
Armstrong 68000 0.00 342 363 Root V,pcc ,
Atari 520/ST 68000 8.00 446 450 TOS ,Lattice 3.03.01 ,
Atari 520ST 68000 8.00 1063 1136 TOS ,Megamax 1.0 ,
CCI Power 5/32 68010 12.50 1135 1192 Unix BSD 4.2,cc ? ,
Celerity 1200 0.00 3921 3916 UNIX 4.2BSD r3.2, ,
Celerity 1260-D 1230 0.00 4010 4045 4.2 BSD 3.2.50,cc standard -O,A 1260-D is a dual-processor 1230
Celerity 1260-D 1230 0.00 4046 4061 4.2 BSD 3.2.50,cc beta test -O,A 1260-D is a dual-processor 1230
Celerity C-1230 NCR uP 10.00 4155 4360 UNIX 4.2BSD,cc ,
Celerity C1230 0.00 4702 4716 UNIX 4.2BSD r3.2, ,
Celerity 1260 0.00 8321 8384 UNIX 4.2BSD r3.2, ,
Commodore 64 6510 1.00 19 34 C64 ROM ,C Power 2.9 trim,
Commodore 128 8502 2.00 43 68 C128 ROM ,C Power 128 trim,
Compaq Compaq II 80286 8.00 1086 1140 MS-DOS 3.1,Microsoft 3.0 large,
Compaq Compaq II 80286 8.00 1190 1282 MS-DOS 3.1,Microsoft 3.0 medium,
Compaq Compaq II 80286 8.00 1351 1428 MS-DOS 3.1,Microsoft 3.0 small,
Compaq 386 80386 16.00 1724 1724 PCDOS 3.1,Lattice 3.00H large,
Compaq 386 80386 16.00 2000 2000 PCDOS 3.1,Lattice 3.00H large data,
Compaq 386 80386 16.00 2631 2631 PCDOS 3.1,Lattice 3.00H large data,
Compaq 386 80386 16.00 2941 2941 PCDOS 3.1,Lattice 3.00H small,
Convergent MiniFrame 68010 10.00 919 965 CTIX 3.2,cc ,
Convergent MiniFrame 68010 10.00 933 985 UNIX SVR2,cc ,
Counterpoi 68020 12.00 1702 1850 UNIX SV,cc ,
Counterpoi System 19 68020 16.67 2481 0 UNIX SVR2.2,Motorola pcc2 2270,11/12/86
Cromemco Z2 Z80 4.00 127 127 Cromix 11.26,ccc ,
DEC PDP-11/34A w/FP-11C 0.00 406 449 UNIX V7m,cc ,
DEC PDP-11/45 ? 0.00 454 506 UNIX V7M,cc ? 256KB,
DEC VAX 11/750 0.00 836 845 BRL Sys V on 4.2BSD ,5bin/cc ,
DEC VAX-11/750 w/FPA 0.00 831 852 UNIX 4.2BSD,cc ,
DEC VAX 11/750 0.00 835 859 Root 4.2,cc ,
DEC PDP-11/73 J-ll,w/F 0.00 772 875 UNIX 2.9BSD,cc ,
DEC PDP 11/44 0.00 884 951 UNIX Sys III,cc ,
DEC VAX 11/780 0.00 1243 1307 UNIX 4.2BSD,cc ,
DEC MicroVAX I 0.00 1361 1385 Mach 4.3,cc ,
DEC Micro VAX 0.00 1379 1394 Ultrix 1.1,cc ,
DEC MicroVAX I 0.00 1385 1399 Ultrix-32m 1.1,cc ,
DEC VAX 11/780 0.00 1417 1441 UNIX 4.2BSD,cc ,
DEC VAX 11/780 MA780 0.00 1428 1470 Mach 4.3,cc ,
DEC VAX 11/780 0.00 1650 1640 UNIX 5.0.1,cc 4.1.1.31 ,
DEC 2060 0.00 1677 1736 TOPS 20 ,pcc ,
DEC VAX 11/785 0.00 1783 1813 UNIX 4.2BSD,cc ,
DEC VAX 11/785 0.00 2063 2069 UNITY/VMS 5.2.2,pcc 4.3 ,
DEC VAX 11/784 0.00 5263 5555 Mach 4.3,cc ,1D on 4P
DEC VAX 8600 0.00 6329 6423 UNIX 4.3BSD,cc ,
DataMedia 932 68000 10.00 837 888 UNIX SYS V,cc ,
Encore Multimax 32032 10.00 1360 1360 Umax 4.2 R2.0 or V R1.0,Green Hills ,
Fortune 32:16 68000 6.00 346 360 UNIX V7,cc ,
GMX Micro-20 68020 12.50 1315 1250 OS-9 1.2,Microware 2.0 ,
Genisys AT 80286 10.00 0 2777 MSDOS ,MS 3.0 /Ot/AS/Gs/G2,
Gould PN6005 0.00 1732 1884 UTX 1.1c+,cc ,
Gould PN9080 0.00 4745 4992 UTX-32 1.1C,cc ,
Gould PN 9080 0.00 6024 6340 UTX 2.0 beta,cc ,
HP 9000-500 1 CPU, R 18.00 1599 1599 HP-UX 5.05,cc ,
HP 9000-320 68020 16.67 2464 2671 HP/UX 5.02 B 9000/320, ,
HP 9000-500 2 CPUs, 18.00 3020 3020 HP-UX 5.05,cc ,Two copies run and added
HP 9000-500 3 CPUs, 18.00 4140 4140 HP-UX 5.05,cc ,Three copies run and added
Hazelwood Uniquad 1 68008 8.00 243 259 OS-9 1.2,Microware 2.0 ,
Home Brew Z80 4.00 53 53 CPM-80 ,Hisoft C++ ,
Home Brew Z80 2.50 91 91 CPM-80 2.2,Aztec CII 1.05g ,
Home Brew 8086 8.00 197 203 iRMX-86 V6,Intel C-86 2.0 large,??
Home Brew 8086 8.00 287 304 iRMX 86 V6,Intel C-86 2.0 small,??
IBM PC/XT 8088 4.77 259 275 COHERENT 2.3.43,Mark Williams ,
IBM PC/XT 8088 4.77 326 347 MS-DOS 2.0,Microsoft 3.01 ,
IBM PC/AT 80286 6.00 531 531 MS-DOS 3.1,Lattice 3.00h -ml (large model),
IBM PC/AT 80286 9.05 696 692 XENIX SCO SVR2.1,cc large,
IBM PC/AT 80286 6.00 943 925 MS-DOS 3.1,Lattice 3.00h ,
IBM PC/AT 80286 7.50 1162 1256 Venix/286 SVR2.1,cc Venturcom 2.2 small,
IBM PC/AT 80286 9.05 1464 1484 XENIX SCO SVR2.1,cc small,
IBM PC/RT 0.00 1333 1510 UNIX 4.2BSD,cc ,
IBM PC/RT (6150)w/ 0.00 1537 1660 AIX SVR1,cc ,
IBM PC/AT 80286 8.00 1729 1796 PC-DOS 3.20,Microsoft 4.0 ,
IBM PC/AT 80286 9.00 1976 1976 UNIX Microport SVR2,cc small,
IBM PC/AT 80286 8.00 2176 2239 PC-DOS 3.20,Microsoft 4.0 small,w/Cheetah 0 ws memory
IBM 4341-12 0.00 3690 3690 Amdahl UTS V,cc 1.11 ,
IBM 4341-12 0.00 3910 3910 Amdahl UTS V,cc 1.11 ,Mike Newtons "optimzer"
IBM 4381-2 0.00 4504 4901 ,c/370 ,
IBM 4381-2 0.00 5681 5681 VM/SP 3.18,Waterloo 1.2 ,
IBM 4381-2 0.00 6440 6440 Amdahl UTS V,cc 1.11 ,
IBM 4381-2 0.00 6850 6850 Amdahl UTS V,cc 1.11 ,Mike Newtons "optimizer"
IBM 3090/200 0.00 31250 31250 , ,
IMP Mentor 68020 16.00 2632 2747 Root V.2,pcc-2 ,
ISI Optimum V 68020 16.00 3245 3391 UNIX 4.2BSD r3.05,ISI ,
ISI Optimum 68020 16.67 3074 3452 UNIX ISI 3.0.1,cc ,
ISI Optimum V 68020 16.00 3778 3977 UNIX 4.2BSD r3.05,Green Hills 1.8.0 ,
Intel 386/24 sys 80386 16.00 4725 5089 UNIX System V.3 beta,rcc 2.01 ,386 Multibus I w/64KB cache
Intel 386/24 sys 80386 16.00 6250 6250 UNIX System V.3 beta,greenhills cc v1.8.2C ,386 Multibus I w/64KB cache
Intel 386/24 sys 80386 20.00 5966 6394 UNIX System V.3 beta,rcc 2.01 ,386 Multibus I w/64KB cache
Intel 386/20 80386 16.00 6995 6677 UNIX SVR3,Green Hills C-386 1.8.2E none,-O means loop optimize, qed faster NOREG
Intel 386/24 sys 80386 20.00 7810 7810 UNIX System V.3 beta,greenhills cc v1.8.2C ,386 Multibus I w/64KB cache
MASSCOMP 5600; 1 CP 68020/68 16.67 4161 4155 RTU 3.0,cc 1.121 ,TOO LONG
MIPS M/500 R2000 8.00 8855 10309 UNIX 4.3BSD,cc ,
Motorola MVME121 68010 10.00 820 865 Uniflex ,cc 1.3:0 ,MVME320,050
Motorola System 113 MC68020 16.67 3246 3257 System V R2V2.2,pcc2 High level Optim and peep Optim ATT -O,
NCR Decision M 8088 4.77 166 166 MS-DOS 2.11,Lattice 2.14 small,
NCR PC4 8088 0.00 212 212 MS-DOS 2.11,Lattice 2.14 small,
NCR Decision M 8088 4.77 250 250 MS-DOS 2.11,Lattice 3.0g small,
NCR PC4 8088 4.77 322 322 MS-DOS 2.11,Lattice 3.0g small,
NCR PC6 8088 8.00 349 349 MS-DOS 2.11,Lattice 2.14 small,
NCR PC6 8088 8.00 512 512 MS-DOS 2.11,Lattice 3.0g small,
NCR PC-8 80286 8.00 653 649 XENIX SCO SVR2.0.4,cc large,
NCR PC-8 80286 8.00 981 983 XENIX SCO SVR2.0.4,cc middle,
NCR PC-8 80286 8.00 1283 1299 XENIX SCO SVR2.0.4,cc small,
National VR332 32332 15.00 2851 2851 UNIX SVR2.2,NSC GNX 2 -O,
National S ICM-3216 32016 10.00 0 2688 UNIX SVR2,cc ,Wouldn't run noreg
OPUS SYSTE Opus 32.16 32016 10.00 736 776 Opus5(UNIX) 2.0v2C2.1,cc SysV.2.0 Ver 1.5 ,hosted on IBM PC/AT
Olivetti m24 8086 8.00 0 847 MSDOS ,MS 3.0 /Ot/AS/Gs,
Olivetti m24 V30 8.00 0 1086 MSDOS ,MS 3.0 /Ot/AS/Gs/G0,
Olivetti m24 V30 8.00 0 1111 MSDOS ,MS 3.0 /Ot/AS/Gs/G1,
PRIME 9955 0.00 1633 1633 PRIMIX 1.2,CC 4.0-19.4 -OPTIMIZE -HIGH,Primix (Unix) on top of Primos 20.0.4
PRIME 9955 0.00 2859 2859 PRIMOS 20.0.4,CC 4.0-19.4 -OPTIMIZE -HIGH,V-mode compiler
PRIME 9955 0.00 3348 3348 PRIMOS 20.0.4,CI 4.0-19.4 -32IX,I-mode compiler
PRIME 9955 0.00 3492 3492 PRIMOS 20.0.4,CI 4.0-19.4 -32IX -INTRINSIC strcpy,
Phillips 68000 8.00 313 333 Root V.2,pcc-2 ,
Plessey system68 68000 8.00 408 436 Root V,pcc ,
Plessey Mantra 68010 12.00 1089 1157 Root V.2,pcc2 ,
Plexus P35 68000 12.50 835 894 UNIX SYS III,cc ,
Pyramid 90x XBIF 8.00 1779 1779 OSx 3.1,CLE 3.2.0 ,
Pyramid 90x DCU 8.00 2898 2898 OSx 3.1,CLE 3.2.0 ,
Pyramid 98xe DCU 10.00 3627 3627 OSx 3.1,CLE 3.2.0 ,
Pyramid Workcenter DCU 10.00 3627 3627 OSx 3.1,CLE 3.2.0 ,
Pyramid 98X DCU 10.00 3671 3671 OSx 3.1,CLE 3.2.0 ,
Pyramid 98xe DCU,FPA 10.00 3773 3773 OSx 3.1,CLE 3.2.0 ,
Pyramid 98X DCU,FPA 10.00 3856 3856 OSx ,CLE 3.2.0 ,
Racal Redac 68010 10.00 490 525 Root V.2,pcc-2 ,
Ridge 32C V1 0.00 1628 1695 ROS 3.3,Ridge (older) ,
Ridge Comp Ridge 3200 Propriet 12.00 6119 6240 ROS 3.4,rc 2.0 none,
SSB Chieftan 6809 2.00 210 249 OS/9 Level II 1.2,Microware ,
Sequent Balance 80 32032 10.00 1097 1137 Dynix ,cc ,
Sherry AT 80286 8.00 0 1724 MSDOS ,MS 3.0 /Ot/AS/Gs/G2,
Siemens PC-MX2 32016 10.00 717 745 Root V.2,cc ,
Stride 68010 10.00 1164 1252 UniStride SVR2,cc ,
Sun 1/100U 0.00 957 1029 UNIX Sun 2.0,cc ,
Sun 2/120 68010 10.00 950 1051 UNIX 4.2BSD,cc no -O,
Sun 1/100U 0.00 1039 1075 UNIX Sun 2.0,Greehills ,
Sun 2 0.00 1034 1110 UNIX 4.2BSD,cc ,
Sun 2/120 68010 10.00 1058 1142 UNIX Sun 2.2,cc ,
Sun 3/50 68020 15.00 2280 2540 UNIX Sun 3.0,cc ,
Sun 3/160 68020 16.67 2843 3134 UNIX Sun 3.0,cc ,
Sun 3/160 68020 16.67 2921 3229 UNIX Sun 3.0,cc -fsoft,
Sun 3/160 68020 16.67 2949 3236 UNIX Sun 3.0,cc -f68881,
Sun 3/160 68020 16.67 2946 3246 Sun 4.2 3.0A,cc ,
Tadpole Titan 68010 10.00 823 882 Root V,pcc ,
Torch Triple X 68010 0.00 578 625 Root V,pcc ,
VT 68000 8.00 422 451 Root V.2,pcc2 ,
Victor Sirius 8088 0.00 284 295 MSDOS 2.11,Microsoft 3.0 large,
Victor Sirius 8088 0.00 317 335 MSDOS 2.11,Microsoft 3.0 middle,
Victor Sirius 8088 0.00 357 381 MSDOS 2.11,Microsoft 3.0 small,
Whitechape MG1 32016 8.00 636 675 UNIX 4.2BSD,cc ,
Zilog 8000 model Z8001 6.00 727 758 Zeus 3.21,cc segmented,
Zilog 8000 model Z8001 6.00 831 878 Zeus 3.21,cc non-segment,
benchMark 32016 10.00 643 673 Root V.2,pcc2 ,
DHRYSTONE 1.1 BENCHMARK SUMMARY
Sat Jan 31 22:40:34 EST 1987
SORTED BY PERFORMANCE
MANUF MODEL PROC CLOCK NOREG REG OS,COMPILER,NOTES
----- ----- ---- ----- ----- --- -----------------
Counterpoi System 19 68020 16.67 2481 0 UNIX SVR2.2,Motorola pcc2 2270,11/12/86
Commodore 64 6510 1.00 19 34 C64 ROM ,C Power 2.9 trim,
Apple IIe 65C02 1.02 37 37 DOS 3.3,Aztec CII v1.05i ,
Home Brew Z80 4.00 53 53 CPM-80 ,Hisoft C++ ,
Commodore 128 8502 2.00 43 68 C128 ROM ,C Power 128 trim,
Home Brew Z80 2.50 91 91 CPM-80 2.2,Aztec CII 1.05g ,
Cromemco Z2 Z80 4.00 127 127 Cromix 11.26,ccc ,
NCR Decision M 8088 4.77 166 166 MS-DOS 2.11,Lattice 2.14 small,
Home Brew 8086 8.00 197 203 iRMX-86 V6,Intel C-86 2.0 large,??
NCR PC4 8088 0.00 212 212 MS-DOS 2.11,Lattice 2.14 small,
SSB Chieftan 6809 2.00 210 249 OS/9 Level II 1.2,Microware ,
NCR Decision M 8088 4.77 250 250 MS-DOS 2.11,Lattice 3.0g small,
Hazelwood Uniquad 1 68008 8.00 243 259 OS-9 1.2,Microware 2.0 ,
IBM PC/XT 8088 4.77 259 275 COHERENT 2.3.43,Mark Williams ,
Victor Sirius 8088 0.00 284 295 MSDOS 2.11,Microsoft 3.0 large,
Home Brew 8086 8.00 287 304 iRMX 86 V6,Intel C-86 2.0 small,??
NCR PC4 8088 4.77 322 322 MS-DOS 2.11,Lattice 3.0g small,
Phillips 68000 8.00 313 333 Root V.2,pcc-2 ,
Victor Sirius 8088 0.00 317 335 MSDOS 2.11,Microsoft 3.0 middle,
IBM PC/XT 8088 4.77 326 347 MS-DOS 2.0,Microsoft 3.01 ,
NCR PC6 8088 8.00 349 349 MS-DOS 2.11,Lattice 2.14 small,
Fortune 32:16 68000 6.00 346 360 UNIX V7,cc ,
Armstrong 68000 0.00 342 363 Root V,pcc ,
Victor Sirius 8088 0.00 357 381 MSDOS 2.11,Microsoft 3.0 small,
Apricot portable 8086 5.00 375 400 MS-DOS 2.11,Microsoft 3.01 ,
AT&T 3B2/300 32000 7.20 409 410 UNIX SVR2.0,cc ,
Plessey system68 68000 8.00 408 436 Root V,pcc ,
Gridcase 3 80C86 4.77 409 438 MS-DOS 2.11,Microsoft 3.01 ,
DEC PDP-11/34A w/FP-11C 0.00 406 449 UNIX V7m,cc ,
Altos Comp ACS 68000 68000 8.00 440 450 UNIX System III, Altos Release 2.0,cc --,
Atari 520/ST 68000 8.00 446 450 TOS ,Lattice 3.03.01 ,
VT 68000 8.00 422 451 Root V.2,pcc2 ,
DEC PDP-11/45 ? 0.00 454 506 UNIX V7M,cc ? 256KB,
NCR PC6 8088 8.00 512 512 MS-DOS 2.11,Lattice 3.0g small,
Racal Redac 68010 10.00 490 525 Root V.2,pcc-2 ,
IBM PC/AT 80286 6.00 531 531 MS-DOS 3.1,Lattice 3.00h -ml (large model),
Apple Lisa 2/10 68000 5.00 505 533 XENIX 3.0 Priam,cc ,
Apple Macintosh 68000 8.00 510 549 Mac Finder 5.1, System 3.2,LightSpeed C 1.02 ,with new, 128K ROMs
Apple Lisa 68000 0.00 517 550 UniPlus Sys V,cc ,
AT&T 3B5 WE32000 10.00 578 573 UNIX SVR2 5.2.0.1 V2,cc ? large,
Apple Macintosh 68000 7.70 625 625 Mac ROM ,DeSmet ,
Torch Triple X 68010 0.00 578 625 Root V,pcc ,
NCR PC-8 80286 8.00 653 649 XENIX SCO SVR2.0.4,cc large,
AT&T 3B2/310 32100 0.00 668 671 UNIX SVR2.4,cc ,
benchMark 32016 10.00 643 673 Root V.2,pcc2 ,
Whitechape MG1 32016 8.00 636 675 UNIX 4.2BSD,cc ,
Amiga 1000 0.00 643 684 ,Manx C 2.30a ,32 bit int
AT&T 3B2/300 32000 7.20 685 688 UNIX SVR2.0.4,cc ,
IBM PC/AT 80286 9.05 696 692 XENIX SCO SVR2.1,cc large,
AT&T 3B2/300 32000 7.70 699 697 UNIX SVR3.0,cc ,
Siemens PC-MX2 32016 10.00 717 745 Root V.2,cc ,
Zilog 8000 model Z8001 6.00 727 758 Zeus 3.21,cc segmented,
Apple Mac+ 68000 7.80 714 769 Mac 3.2,Manx 1.06H ,16 bit int
OPUS SYSTE Opus 32.16 32016 10.00 736 776 Opus5(UNIX) 2.0v2C2.1,cc SysV.2.0 Ver 1.5 ,hosted on IBM PC/AT
DEC VAX 11/750 0.00 836 845 BRL Sys V on 4.2BSD ,5bin/cc ,
Olivetti m24 8086 8.00 0 847 MSDOS ,MS 3.0 /Ot/AS/Gs,
DEC VAX-11/750 w/FPA 0.00 831 852 UNIX 4.2BSD,cc ,
DEC VAX 11/750 0.00 835 859 Root 4.2,cc ,
Motorola MVME121 68010 10.00 820 865 Uniflex ,cc 1.3:0 ,MVME320,050
DEC PDP-11/73 J-ll,w/F 0.00 772 875 UNIX 2.9BSD,cc ,
Zilog 8000 model Z8001 6.00 831 878 Zeus 3.21,cc non-segment,
Tadpole Titan 68010 10.00 823 882 Root V,pcc ,
DataMedia 932 68000 10.00 837 888 UNIX SYS V,cc ,
Plexus P35 68000 12.50 835 894 UNIX SYS III,cc ,
Amiga 1000 0.00 880 915 ,Manx 2.30a ,16 bit int
IBM PC/AT 80286 6.00 943 925 MS-DOS 3.1,Lattice 3.00h ,
DEC PDP 11/44 0.00 884 951 UNIX Sys III,cc ,
Convergent MiniFrame 68010 10.00 919 965 CTIX 3.2,cc ,
NCR PC-8 80286 8.00 981 983 XENIX SCO SVR2.0.4,cc middle,
Convergent MiniFrame 68010 10.00 933 985 UNIX SVR2,cc ,
Sun 1/100U 0.00 957 1029 UNIX Sun 2.0,cc ,
AT&T UNIX PC 68010 10.00 973 1034 UNIX 5.0.3,cc ,
Sun 2/120 68010 10.00 950 1051 UNIX 4.2BSD,cc no -O,
Sun 1/100U 0.00 1039 1075 UNIX Sun 2.0,Greehills ,
Olivetti m24 V30 8.00 0 1086 MSDOS ,MS 3.0 /Ot/AS/Gs/G0,
Sun 2 0.00 1034 1110 UNIX 4.2BSD,cc ,
Olivetti m24 V30 8.00 0 1111 MSDOS ,MS 3.0 /Ot/AS/Gs/G1,
AT&T 3B2/400 32100 10.00 1108 1120 UNIX SVR2.0.4,cc ,
Atari 520ST 68000 8.00 1063 1136 TOS ,Megamax 1.0 ,
Sequent Balance 80 32032 10.00 1097 1137 Dynix ,cc ,
Compaq Compaq II 80286 8.00 1086 1140 MS-DOS 3.1,Microsoft 3.0 large,
Sun 2/120 68010 10.00 1058 1142 UNIX Sun 2.2,cc ,
Plessey Mantra 68010 12.00 1089 1157 Root V.2,pcc2 ,
CCI Power 5/32 68010 12.50 1135 1192 Unix BSD 4.2,cc ? ,
AT&T 6300 PLUS 80286 6.00 1225 1225 UNIX SVR2 vC3,cc ,
GMX Micro-20 68020 12.50 1315 1250 OS-9 1.2,Microware 2.0 ,
Stride 68010 10.00 1164 1252 UniStride SVR2,cc ,
IBM PC/AT 80286 7.50 1162 1256 Venix/286 SVR2.1,cc Venturcom 2.2 small,
Compaq Compaq II 80286 8.00 1190 1282 MS-DOS 3.1,Microsoft 3.0 medium,
NCR PC-8 80286 8.00 1283 1299 XENIX SCO SVR2.0.4,cc small,
DEC VAX 11/780 0.00 1243 1307 UNIX 4.2BSD,cc ,
Encore Multimax 32032 10.00 1360 1360 Umax 4.2 R2.0 or V R1.0,Green Hills ,
DEC MicroVAX I 0.00 1361 1385 Mach 4.3,cc ,
DEC Micro VAX 0.00 1379 1394 Ultrix 1.1,cc ,
DEC MicroVAX I 0.00 1385 1399 Ultrix-32m 1.1,cc ,
Compaq Compaq II 80286 8.00 1351 1428 MS-DOS 3.1,Microsoft 3.0 small,
ATI 2000 80286 8.00 1440 1440 UNIX Microport SVR2,cc large,0 wait state AT clone
DEC VAX 11/780 0.00 1417 1441 UNIX 4.2BSD,cc ,
DEC VAX 11/780 MA780 0.00 1428 1470 Mach 4.3,cc ,
IBM PC/AT 80286 9.05 1464 1484 XENIX SCO SVR2.1,cc small,
Apollo DN330 68020 12.50 1504 1504 Domain/IX ,cc 4.08 w/o 020,
IBM PC/RT 0.00 1333 1510 UNIX 4.2BSD,cc ,
HP 9000-500 1 CPU, R 18.00 1599 1599 HP-UX 5.05,cc ,
PRIME 9955 0.00 1633 1633 PRIMIX 1.2,CC 4.0-19.4 -OPTIMIZE -HIGH,Primix (Unix) on top of Primos 20.0.4
DEC VAX 11/780 0.00 1650 1640 UNIX 5.0.1,cc 4.1.1.31 ,
IBM PC/RT (6150)w/ 0.00 1537 1660 AIX SVR1,cc ,
Apollo DN330 68020 12.50 1677 1677 Domain/IX ,cc 4.08 w/ 020,
Ridge 32C V1 0.00 1628 1695 ROS 3.3,Ridge (older) ,
Compaq 386 80386 16.00 1724 1724 PCDOS 3.1,Lattice 3.00H large,
Sherry AT 80286 8.00 0 1724 MSDOS ,MS 3.0 /Ot/AS/Gs/G2,
DEC 2060 0.00 1677 1736 TOPS 20 ,pcc ,
Pyramid 90x XBIF 8.00 1779 1779 OSx 3.1,CLE 3.2.0 ,
IBM PC/AT 80286 8.00 1729 1796 PC-DOS 3.20,Microsoft 4.0 ,
AT&T 3B15 32100 14.00 1797 1798 UNIX 5.2.1,cc ,
DEC VAX 11/785 0.00 1783 1813 UNIX 4.2BSD,cc ,
Counterpoi 68020 12.00 1702 1850 UNIX SV,cc ,
Gould PN6005 0.00 1732 1884 UTX 1.1c+,cc ,
APOLLO DN330 68020/68 12.50 1934 1934 Domain/IX SR9.5.Bl12,CC 4.58 w/o 020,68881,(Beta OS and Compiler)
IBM PC/AT 80286 9.00 1976 1976 UNIX Microport SVR2,cc small,
Compaq 386 80386 16.00 2000 2000 PCDOS 3.1,Lattice 3.00H large data,
APOLLO DN330 68020/68 12.50 2046 2046 Domain/IX SR9.5.Bl12,CC 4.58 w/020,68881,(Beta OS and Compiler)
DEC VAX 11/785 0.00 2063 2069 UNITY/VMS 5.2.2,pcc 4.3 ,
ATI 2000 80286 8.00 2145 2145 UNIX Microport SVR2,cc small,0 wait state AT clone
IBM PC/AT 80286 8.00 2176 2239 PC-DOS 3.20,Microsoft 4.0 small,w/Cheetah 0 ws memory
APOLLO DN3000 68020/68 12.50 2481 2481 Domain/IX SR9.5.Bl12,CC 4.58 w/o 020,68881,(Beta OS and Compiler)
Sun 3/50 68020 15.00 2280 2540 UNIX Sun 3.0,cc ,
Compaq 386 80386 16.00 2631 2631 PCDOS 3.1,Lattice 3.00H large data,
APOLLO DN3000 68020/68 12.50 2643 2643 Domain/IX SR9.5.Bl12,CC 4.58 w/020,68881,(Beta OS and Compiler)
HP 9000-320 68020 16.67 2464 2671 HP/UX 5.02 B 9000/320, ,
National S ICM-3216 32016 10.00 0 2688 UNIX SVR2,cc ,Wouldn't run noreg
IMP Mentor 68020 16.00 2632 2747 Root V.2,pcc-2 ,
Genisys AT 80286 10.00 0 2777 MSDOS ,MS 3.0 /Ot/AS/Gs/G2,
Arete 1100/1200 68020 12.00 2741 2808 UNIX SVR2.2,Motorola pcc2 ,
National VR332 32332 15.00 2851 2851 UNIX SVR2.2,NSC GNX 2 -O,
PRIME 9955 0.00 2859 2859 PRIMOS 20.0.4,CC 4.0-19.4 -OPTIMIZE -HIGH,V-mode compiler
Pyramid 90x DCU 8.00 2898 2898 OSx 3.1,CLE 3.2.0 ,
Compaq 386 80386 16.00 2941 2941 PCDOS 3.1,Lattice 3.00H small,
HP 9000-500 2 CPUs, 18.00 3020 3020 HP-UX 5.05,cc ,Two copies run and added
Sun 3/160 68020 16.67 2843 3134 UNIX Sun 3.0,cc ,
Sun 3/160 68020 16.67 2921 3229 UNIX Sun 3.0,cc -fsoft,
Sun 3/160 68020 16.67 2949 3236 UNIX Sun 3.0,cc -f68881,
Sun 3/160 68020 16.67 2946 3246 Sun 4.2 3.0A,cc ,
Motorola System 113 MC68020 16.67 3246 3257 System V R2V2.2,pcc2 High level Optim and peep Optim ATT -O,
PRIME 9955 0.00 3348 3348 PRIMOS 20.0.4,CI 4.0-19.4 -32IX,I-mode compiler
ISI Optimum V 68020 16.00 3245 3391 UNIX 4.2BSD r3.05,ISI ,
ISI Optimum 68020 16.67 3074 3452 UNIX ISI 3.0.1,cc ,
PRIME 9955 0.00 3492 3492 PRIMOS 20.0.4,CI 4.0-19.4 -32IX -INTRINSIC strcpy,
Pyramid 98xe DCU 10.00 3627 3627 OSx 3.1,CLE 3.2.0 ,
Pyramid Workcenter DCU 10.00 3627 3627 OSx 3.1,CLE 3.2.0 ,
Pyramid 98X DCU 10.00 3671 3671 OSx 3.1,CLE 3.2.0 ,
IBM 4341-12 0.00 3690 3690 Amdahl UTS V,cc 1.11 ,
Pyramid 98xe DCU,FPA 10.00 3773 3773 OSx 3.1,CLE 3.2.0 ,
Pyramid 98X DCU,FPA 10.00 3856 3856 OSx ,CLE 3.2.0 ,
IBM 4341-12 0.00 3910 3910 Amdahl UTS V,cc 1.11 ,Mike Newtons "optimzer"
Celerity 1200 0.00 3921 3916 UNIX 4.2BSD r3.2, ,
ISI Optimum V 68020 16.00 3778 3977 UNIX 4.2BSD r3.05,Green Hills 1.8.0 ,
Celerity 1260-D 1230 0.00 4010 4045 4.2 BSD 3.2.50,cc standard -O,A 1260-D is a dual-processor 1230
Celerity 1260-D 1230 0.00 4046 4061 4.2 BSD 3.2.50,cc beta test -O,A 1260-D is a dual-processor 1230
HP 9000-500 3 CPUs, 18.00 4140 4140 HP-UX 5.05,cc ,Three copies run and added
MASSCOMP 5600; 1 CP 68020/68 16.67 4161 4155 RTU 3.0,cc 1.121 ,TOO LONG
Celerity C-1230 NCR uP 10.00 4155 4360 UNIX 4.2BSD,cc ,
Celerity C1230 0.00 4702 4716 UNIX 4.2BSD r3.2, ,
IBM 4381-2 0.00 4504 4901 ,c/370 ,
Gould PN9080 0.00 4745 4992 UTX-32 1.1C,cc ,
Intel 386/24 sys 80386 16.00 4725 5089 UNIX System V.3 beta,rcc 2.01 ,386 Multibus I w/64KB cache
DEC VAX 11/784 0.00 5263 5555 Mach 4.3,cc ,1D on 4P
IBM 4381-2 0.00 5681 5681 VM/SP 3.18,Waterloo 1.2 ,
Ridge Comp Ridge 3200 Propriet 12.00 6119 6240 ROS 3.4,rc 2.0 none,
Intel 386/24 sys 80386 16.00 6250 6250 UNIX System V.3 beta,greenhills cc v1.8.2C ,386 Multibus I w/64KB cache
Gould PN 9080 0.00 6024 6340 UTX 2.0 beta,cc ,
Intel 386/24 sys 80386 20.00 5966 6394 UNIX System V.3 beta,rcc 2.01 ,386 Multibus I w/64KB cache
DEC VAX 8600 0.00 6329 6423 UNIX 4.3BSD,cc ,
IBM 4381-2 0.00 6440 6440 Amdahl UTS V,cc 1.11 ,
Intel 386/20 80386 16.00 6995 6677 UNIX SVR3,Green Hills C-386 1.8.2E none,-O means loop optimize, qed faster NOREG
IBM 4381-2 0.00 6850 6850 Amdahl UTS V,cc 1.11 ,Mike Newtons "optimizer"
Intel 386/24 sys 80386 20.00 7810 7810 UNIX System V.3 beta,greenhills cc v1.8.2C ,386 Multibus I w/64KB cache
Celerity 1260 0.00 8321 8384 UNIX 4.2BSD r3.2, ,
MIPS M/500 R2000 8.00 8855 10309 UNIX 4.3BSD,cc ,
Amdahl 5860 0.00 28735 28846 UTS V,cc 1.22 ,
IBM 3090/200 0.00 31250 31250 , ,
SHAR_EOF
fi
if test -f 'submit.doc'
then
echo shar: "will not over-write existing file 'submit.doc'"
else
cat << \SHAR_EOF > 'submit.doc'
SUBMISSION PROCEDURE
I'm no longer accepting or reporting results from the 1.0 version.
Remember, the "goofed" version? I am now keeping a real database of
all the reported results. To help me in automating this process,
I am requesting that all results sent to me are on a copy of the
form in "submit.frm", and mailed to:
ihnp4!castor!pcrat!dry
A sample filled out form looks like this:
DHRYSTONE 1.1 BENCHMARK REPORTING FORM
MANUF: AT&T
MODEL: 6300 PLUS
PROC: 80286
CLOCK: 6
OS: UNIX
OVERSION: SVR2
COMPILER: cc
CVERSION: 2.0
OPTIONS: large
NOREG: 99999
REG: 99999
NOTES: immersed unit in He
DATE: 8/15/86
SUBMITTER: ihnp4!frostbite (Abby Normal)
MAILTO: ihnp4!castor!pcrat!dry
The entire form must be sent for each entry. Do not split long notes
onto two or more lines. The mail scanner I use to pull this stuff
directly into the database isn't that smart. You can place
additional comments either before the "DHRYSTONE" line, or after the
"MAILTO" line.
The good news is that this new format allows reporting the information
in several ways. I have attached reports sorted by manufacturer and
by performance. I am also reporting all reasonable submissions, even
for identical configurations. I gave up trying to figure out which one
might be a better measure. These things aren't all that reliable a
measure of performance, anyhow, and anybody who quibbles over
say a 10% difference between machines is missing the point, as stated
below.
SHAR_EOF
fi
if test -f 'submit.frm'
then
echo shar: "will not over-write existing file 'submit.frm'"
else
cat << \SHAR_EOF > 'submit.frm'
DHRYSTONE 1.1 BENCHMARK REPORTING FORM [DO NOT DELE
MANUF:
MODEL:
PROC:
CLOCK:
OS:
OVERSION:
COMPILER:
CVERSION:
OPTIONS:
NOREG:
REG:
NOTES:
DATE:
SUBMITTER:
MAILTO: ihnp4!castor!pcrat!dry
SHAR_EOF
fi
if test -f 'clarify.doc'
then
echo shar: "will not over-write existing file 'clarify.doc'"
else
cat << \SHAR_EOF > 'clarify.doc'
CLARIFICATION
There seems to have been a great deal of confusion over what this
benchmark measures, and how to use these results. Let me try to clarify
this:
1) DHRYSTONE is a measure of processor+compiler efficiency in
executing a 'typical' program. The 'typical' program was
designed by measuring statistics on a great number of
'real' programs. The 'typical' program was then written
by Reinhold P. Weicker using these statistics. The
program is balanced according to statement type, as well
as data type.
2) DHRYSTONE does not use floating point. Typical programs don't.
3) DHRYSTONE does not do I/O. Typical programs do, but then
we'd have a whole can of worms opened up.
4) DHRYSTONE does not contain much code that can be optimized
by vector processors. That's why a CRAY doesn't look real
fast, they weren't built to do this sort of computing.
5) DHRYSTONE does not measure OS performance, as it avoids
calling the O.S. The O.S. is indicated in the results only
to help in identifying the compiler technology.
If somebody asked me to pick out the best machine for the money, I
wouldn't look at just the results of DHRYSTONE. I'd probably:
1) Run DHRYSTONE to get a feel for the compiler+processor
speed.
2) Run any number of benchmarks to check disk I/O bandwidth,
using both sequential and random read/writes.
3) Run a multitasking benchmark to check multi-user response
time. Typically, these benchmarks run several types of
programs such as editors, shell scripts, sorts, compiles,
and plot the results against the number of simulated users.
4) If appropriate for the intended use, run WHETSTONE, to determine
floating point performance.
5) If appropriate for intended use, run some programs which do
vector and matrix computations.
6) Figure out what the box will:
- cost to buy
- cost to operate and maintain
- be worth when it is sold
- be worth if the manufacturer goes out of business
7) Having done the above, I probably have a hand-full of
machines which meet my price/performance requirements.
Now, I find out if the applications programs I'd like
to use will run on any of these machines. I also find
out how much interest people have in writing new software
for the machine, and look carefully at the migration path
I will have to take when I reach the limits of the machine.
To summarize, DHRYSTONES by themselves are not anything more than
a way to win free beers when arguing 'Box-A versus Box-B' religion.
They do provide insight into Box-A/Compiler-A versus Box-A/Compiler-B
comparisons.
As usual, all comments and new results should be mailed directly
to me at ..ihnp4!castor!pcrat!dry. I will summarize
and post to the net. These results are also being sent to Rheinhold
Weicker for adding to his list of Pascal and Ada results.
A SPECIAL THANKS
I didn't write the DHRYSTONE benchmark. Rheinhold Weicker did. He has
certainly provided us with a useful tool for benchmarking, and is
to be congratulated.
Rick Richardson
PC Research, Inc.
(201) 834-1378 (9-17 EST)
(201) 922-1134 (7-9,17-24 EST)
..ihnp4!castor!pcrat!rick (normal mail)
..ihnp4!castor!pcrat!dry (results only)
SHAR_EOF
fi
if test -f 'dry.c'
then
echo shar: "will not over-write existing file 'dry.c'"
else
cat << \SHAR_EOF > 'dry.c'
/*
*
* "DHRYSTONE" Benchmark Program
*
* Version: C/1.1, 12/01/84
*
* Date: PROGRAM updated 01/06/86, COMMENTS changed 01/31/87
*
* Author: Reinhold P. Weicker, CACM Vol 27, No 10, 10/84 pg. 1013
* Translated from ADA by Rick Richardson
* Every method to preserve ADA-likeness has been used,
* at the expense of C-ness.
*
* Compile: cc -O dry.c -o drynr : No registers
* cc -O -DREG=register dry.c -o dryr : Registers
*
* Defines: Defines are provided for old C compiler's
* which don't have enums, and can't assign structures.
* The time(2) function is library dependant; Most
* return the time in seconds, but beware of some, like
* Aztec C, which return other units.
* The LOOPS define is initially set for 50000 loops.
* If you have a machine with large integers and is
* very fast, please change this number to 500000 to
* get better accuracy. Please select the way to
* measure the execution time using the TIME define.
* For single user machines, time(2) is adequate. For
* multi-user machines where you cannot get single-user
* access, use the times(2) function. If you have
* neither, use a stopwatch in the dead of night.
* Use a "printf" at the point marked "start timer"
* to begin your timings. DO NOT use the UNIX "time(1)"
* command, as this will measure the total time to
* run this program, which will (erroneously) include
* the time to malloc(3) storage and to compute the
* time it takes to do nothing.
*
* Run: drynr; dryr
*
* Results: If you get any new machine/OS results, please send to:
*
* ihnp4!castor!pcrat!rick
*
* and thanks to all that do.
*
* Note: I order the list in increasing performance of the
* "with registers" benchmark. If the compiler doesn't
* provide register variables, then the benchmark
* is the same for both REG and NOREG.
*
* PLEASE: Send complete information about the machine type,
* clock speed, OS and C manufacturer/version. If
* the machine is modified, tell me what was done.
* On UNIX, execute uname -a and cc -V to get this info.
*
* 80x8x NOTE: 80x8x benchers: please try to do all memory models
* for a particular compiler.
*
*
* The following program contains statements of a high-level programming
* language (C) in a distribution considered representative:
*
* assignments 53%
* control statements 32%
* procedure, function calls 15%
*
* 100 statements are dynamically executed. The program is balanced with
* respect to the three aspects:
* - statement type
* - operand type (for simple data types)
* - operand access
* operand global, local, parameter, or constant.
*
* The combination of these three aspects is balanced only approximately.
*
* The program does not compute anything meaningfull, but it is
* syntactically and semantically correct.
*
*/
/* Accuracy of timings and human fatigue controlled by next two lines */
#define LOOPS 50000 /* Use this for slow or 16 bit machines */
/*#define LOOPS 500000 /* Use this for faster machines */
/* Compiler dependent options */
#undef NOENUM /* Define if compiler has no enum's */
#undef NOSTRUCTASSIGN /* Define if compiler can't assign structures */
/* define only one of the next two defines */
#define TIMES /* Use times(2) time function */
/*#define TIME /* Use time(2) time function */
/* define the granularity of your times(2) function (when used) */
/*#define HZ 50 /* times(2) returns 1/50 second (europe?) */
#define HZ 60 /* times(2) returns 1/60 second (most) */
/*#define HZ 100 /* times(2) returns 1/100 second (WECo) */
/* for compatibility with goofed up version */
/*#undef GOOF /* Define if you want the goofed up version */
#ifdef GOOF
char Version[] = "1.0";
#else
char Version[] = "1.1";
#endif
#ifdef NOSTRUCTASSIGN
#define structassign(d, s) memcpy(&(d), &(s), sizeof(d))
#else
#define structassign(d, s) d = s
#endif
#ifdef NOENUM
#define Ident1 1
#define Ident2 2
#define Ident3 3
#define Ident4 4
#define Ident5 5
typedef int Enumeration;
#else
typedef enum {Ident1, Ident2, Ident3, Ident4, Ident5} Enumeration;
#endif
typedef int OneToThirty;
typedef int OneToFifty;
typedef char CapitalLetter;
typedef char String30[31];
typedef int Array1Dim[51];
typedef int Array2Dim[51][51];
struct Record
{
struct Record *PtrComp;
Enumeration Discr;
Enumeration EnumComp;
OneToFifty IntComp;
String30 StringComp;
};
typedef struct Record RecordType;
typedef RecordType * RecordPtr;
typedef int boolean;
#define NULL 0
#define TRUE 1
#define FALSE 0
#ifndef REG
#define REG
#endif
extern Enumeration Func1();
extern boolean Func2();
#ifdef TIMES
#include <sys/types.h>
#include <sys/times.h>
#endif
main()
{
Proc0();
exit(0);
}
/*
* Package 1
*/
int IntGlob;
boolean BoolGlob;
char Char1Glob;
char Char2Glob;
Array1Dim Array1Glob;
Array2Dim Array2Glob;
RecordPtr PtrGlb;
RecordPtr PtrGlbNext;
Proc0()
{
OneToFifty IntLoc1;
REG OneToFifty IntLoc2;
OneToFifty IntLoc3;
REG char CharLoc;
REG char CharIndex;
Enumeration EnumLoc;
String30 String1Loc;
String30 String2Loc;
extern char *malloc();
register unsigned int i;
#ifdef TIME
long time();
long starttime;
long benchtime;
long nulltime;
starttime = time( (long *) 0);
for (i = 0; i < LOOPS; ++i);
nulltime = time( (long *) 0) - starttime; /* Computes o'head of loop */
#endif
#ifdef TIMES
time_t starttime;
time_t benchtime;
time_t nulltime;
struct tms tms;
times(&tms); starttime = tms.tms_utime;
for (i = 0; i < LOOPS; ++i);
times(&tms);
nulltime = tms.tms_utime - starttime; /* Computes overhead of looping */
#endif
PtrGlbNext = (RecordPtr) malloc(sizeof(RecordType));
PtrGlb = (RecordPtr) malloc(sizeof(RecordType));
PtrGlb->PtrComp = PtrGlbNext;
PtrGlb->Discr = Ident1;
PtrGlb->EnumComp = Ident3;
PtrGlb->IntComp = 40;
strcpy(PtrGlb->StringComp, "DHRYSTONE PROGRAM, SOME STRING");
#ifndef GOOF
strcpy(String1Loc, "DHRYSTONE PROGRAM, 1'ST STRING"); /*GOOF*/
#endif
Array2Glob[8][7] = 10; /* Was missing in published program */
/*****************
-- Start Timer --
*****************/
#ifdef TIME
starttime = time( (long *) 0);
#endif
#ifdef TIMES
times(&tms); starttime = tms.tms_utime;
#endif
for (i = 0; i < LOOPS; ++i)
{
Proc5();
Proc4();
IntLoc1 = 2;
IntLoc2 = 3;
strcpy(String2Loc, "DHRYSTONE PROGRAM, 2'ND STRING");
EnumLoc = Ident2;
BoolGlob = ! Func2(String1Loc, String2Loc);
while (IntLoc1 < IntLoc2)
{
IntLoc3 = 5 * IntLoc1 - IntLoc2;
Proc7(IntLoc1, IntLoc2, &IntLoc3);
++IntLoc1;
}
Proc8(Array1Glob, Array2Glob, IntLoc1, IntLoc3);
Proc1(PtrGlb);
for (CharIndex = 'A'; CharIndex <= Char2Glob; ++CharIndex)
if (EnumLoc == Func1(CharIndex, 'C'))
Proc6(Ident1, &EnumLoc);
IntLoc3 = IntLoc2 * IntLoc1;
IntLoc2 = IntLoc3 / IntLoc1;
IntLoc2 = 7 * (IntLoc3 - IntLoc2) - IntLoc1;
Proc2(&IntLoc1);
}
/*****************
-- Stop Timer --
*****************/
#ifdef TIME
benchtime = time( (long *) 0) - starttime - nulltime;
printf("Dhrystone(%s) time for %ld passes = %ld\n",
Version,
(long) LOOPS, benchtime);
printf("This machine benchmarks at %ld dhrystones/second\n",
((long) LOOPS) / benchtime);
#endif
#ifdef TIMES
times(&tms);
benchtime = tms.tms_utime - starttime - nulltime;
printf("Dhrystone(%s) time for %ld passes = %ld\n",
Version,
(long) LOOPS, benchtime/HZ);
printf("This machine benchmarks at %ld dhrystones/second\n",
((long) LOOPS) * HZ / benchtime);
#endif
}
Proc1(PtrParIn)
REG RecordPtr PtrParIn;
{
#define NextRecord (*(PtrParIn->PtrComp))
structassign(NextRecord, *PtrGlb);
PtrParIn->IntComp = 5;
NextRecord.IntComp = PtrParIn->IntComp;
NextRecord.PtrComp = PtrParIn->PtrComp;
Proc3(NextRecord.PtrComp);
if (NextRecord.Discr == Ident1)
{
NextRecord.IntComp = 6;
Proc6(PtrParIn->EnumComp, &NextRecord.EnumComp);
NextRecord.PtrComp = PtrGlb->PtrComp;
Proc7(NextRecord.IntComp, 10, &NextRecord.IntComp);
}
else
structassign(*PtrParIn, NextRecord);
#undef NextRecord
}
Proc2(IntParIO)
OneToFifty *IntParIO;
{
REG OneToFifty IntLoc;
REG Enumeration EnumLoc;
IntLoc = *IntParIO + 10;
for(;;)
{
if (Char1Glob == 'A')
{
--IntLoc;
*IntParIO = IntLoc - IntGlob;
EnumLoc = Ident1;
}
if (EnumLoc == Ident1)
break;
}
}
Proc3(PtrParOut)
RecordPtr *PtrParOut;
{
if (PtrGlb != NULL)
*PtrParOut = PtrGlb->PtrComp;
else
IntGlob = 100;
Proc7(10, IntGlob, &PtrGlb->IntComp);
}
Proc4()
{
REG boolean BoolLoc;
BoolLoc = Char1Glob == 'A';
BoolLoc |= BoolGlob;
Char2Glob = 'B';
}
Proc5()
{
Char1Glob = 'A';
BoolGlob = FALSE;
}
extern boolean Func3();
Proc6(EnumParIn, EnumParOut)
REG Enumeration EnumParIn;
REG Enumeration *EnumParOut;
{
*EnumParOut = EnumParIn;
if (! Func3(EnumParIn) )
*EnumParOut = Ident4;
switch (EnumParIn)
{
case Ident1: *EnumParOut = Ident1; break;
case Ident2: if (IntGlob > 100) *EnumParOut = Ident1;
else *EnumParOut = Ident4;
break;
case Ident3: *EnumParOut = Ident2; break;
case Ident4: break;
case Ident5: *EnumParOut = Ident3;
}
}
Proc7(IntParI1, IntParI2, IntParOut)
OneToFifty IntParI1;
OneToFifty IntParI2;
OneToFifty *IntParOut;
{
REG OneToFifty IntLoc;
IntLoc = IntParI1 + 2;
*IntParOut = IntParI2 + IntLoc;
}
Proc8(Array1Par, Array2Par, IntParI1, IntParI2)
Array1Dim Array1Par;
Array2Dim Array2Par;
OneToFifty IntParI1;
OneToFifty IntParI2;
{
REG OneToFifty IntLoc;
REG OneToFifty IntIndex;
IntLoc = IntParI1 + 5;
Array1Par[IntLoc] = IntParI2;
Array1Par[IntLoc+1] = Array1Par[IntLoc];
Array1Par[IntLoc+30] = IntLoc;
for (IntIndex = IntLoc; IntIndex <= (IntLoc+1); ++IntIndex)
Array2Par[IntLoc][IntIndex] = IntLoc;
++Array2Par[IntLoc][IntLoc-1];
Array2Par[IntLoc+20][IntLoc] = Array1Par[IntLoc];
IntGlob = 5;
}
Enumeration Func1(CharPar1, CharPar2)
CapitalLetter CharPar1;
CapitalLetter CharPar2;
{
REG CapitalLetter CharLoc1;
REG CapitalLetter CharLoc2;
CharLoc1 = CharPar1;
CharLoc2 = CharLoc1;
if (CharLoc2 != CharPar2)
return (Ident1);
else
return (Ident2);
}
boolean Func2(StrParI1, StrParI2)
String30 StrParI1;
String30 StrParI2;
{
REG OneToThirty IntLoc;
REG CapitalLetter CharLoc;
IntLoc = 1;
while (IntLoc <= 1)
if (Func1(StrParI1[IntLoc], StrParI2[IntLoc+1]) == Ident1)
{
CharLoc = 'A';
++IntLoc;
}
if (CharLoc >= 'W' && CharLoc <= 'Z')
IntLoc = 7;
if (CharLoc == 'X')
return(TRUE);
else
{
if (strcmp(StrParI1, StrParI2) > 0)
{
IntLoc += 7;
return (TRUE);
}
else
return (FALSE);
}
}
boolean Func3(EnumParIn)
REG Enumeration EnumParIn;
{
REG Enumeration EnumLoc;
EnumLoc = EnumParIn;
if (EnumLoc == Ident3) return (TRUE);
return (FALSE);
}
#ifdef NOSTRUCTASSIGN
memcpy(d, s, l)
register char *d;
register char *s;
register int l;
{
while (l--) *d++ = *s++;
}
#endif
SHAR_EOF
fi
if test -f 'database.doc'
then
echo shar: "will not over-write existing file 'database.doc'"
else
cat << \SHAR_EOF > 'database.doc'
The file "dry.db" is the DHRYSTONE 1.1 benchmark results
in Venturcom's "Prelude" database format. This format can be
manipulated on UNIX systems which have the Prelude database
manager, or it can easily be manipulated by "awk" scripts.
The format consists of two lines of table header information,
followed by rows of table data. The header lines indicate the
column names. The column information is separated by a single
ASCII tab character.
I hope this format is more useful than the old hand editted format.
With this posting, I am no longer accepting or reporting DHRYSTONE
1.0 benchmark results. Only those results which are from DHRYSTONE
1.1 and mailed to me on the standard form (see the announcement in
net.arch or net.micro) will be accepted.
SHAR_EOF
fi
if test -f 'dry.db'
then
echo shar: "will not over-write existing file 'dry.db'"
else
cat << \SHAR_EOF > 'dry.db'
MANUF:t MODEL:t PROC:t CLOCK:f OS:t OVERSION:t COMPILER:t CVERSION:t OPTIONS:t NOREG:i REG:i NOTES:t DATE:t SUBMITTER:t
- - - - - - - - - - - - - -
Apple IIe 65C02 1.02 DOS 3.3 Aztec CII v1.05i 37 37 3/3/86 meccts!ahby (Shane McCarron)
Home Brew Z80 4 CPM-80 Hisoft C++ 53 53 4/10/86 blade.me.brunel.ac.uk!andrew (Andrew Findlay)
Home Brew Z80 2.5 CPM-80 2.2 Aztec CII 1.05g 91 91 2/24/86 faraday.ECE.CMU.EDU!dan (Dan Nydick)
Home Brew 8086 8 iRMX-86 V6 Intel C-86 2.0 large 197 203 ?? 3/14/86 mcvax!stc!pete (Peter Kendell)
SSB Chieftan 6809 2 OS/9 Level II 1.2 Microware 210 249 4/11/86 uokvax!emjej (James Jones)
IBM PC/XT 8088 4.77 COHERENT 2.3.43 Mark Williams 259 275 2/22/86 infopro!les (Les Hancock)
Home Brew 8086 8 iRMX 86 V6 Intel C-86 2.0 small 287 304 ??
Fortune 32:16 68000 6 UNIX V7 cc 346 360 2/20/86 tolerant!leach (Geoff Leach)
DEC PDP-11/34A w/FP-11C UNIX V7m cc 406 449 3/3/86 eplunix!ijs (Ishmael Stefanov-Wagner)
Apple Lisa 68000 UniPlus Sys V cc 517 550 4/6/86 darth!plooba!shannon (Marc Shannon)
Apple Macintosh 512 68000 7.7 Mac ROM DeSmet 625 625 cs.ubc.cdn!ludemann (Peter Ludemann)
IBM PC/AT 80286 9.05 XENIX SCO SVR2.1 cc large 696 692 4/11/86 reed!omen!caf (Chuck Forsberg)
DEC VAX-11/750 w/FPA UNIX 4.2BSD cc 831 852 3/3/86 eplunix!ijs (Ishmael Stefanov-Wagner)
DataMedia 932 68000 10 UNIX SYS V cc 837 888 3/5/86 csi!ggere (Gary Gere)
Plexus P35 68000 12.5 UNIX SYS III cc 835 894 3/3/86 meccts!ahby (Shane McCarron)
Convergent MiniFrame 68010 10 CTIX 3.2 cc 919 965 4/5/86 adelie!ora!tim (Tim O'Reilly)
Convergent MiniFrame 68010 10 UNIX SVR2 cc 933 985 4/5/86 pitt!darth!dehart (Ed DeHart)
AT&T UNIX PC 68010 10 UNIX 5.0.3 cc 973 1034
Atari 520ST 68000 8 TOS Megamax 1.0 1063 1136 4/7/86 megamax!eric (Eric Parker)
Compaq Compaq II 80286 8 MS-DOS 3.1 Microsoft 3.0 large 1086 1140 3/3/86 meccts!ahby (Shane McCarron)
AT&T 6300 PLUS 80286 6 UNIX SVR2 vC3 cc 1225 1225 4/1/86 cbuxc!cbgmv!gmv (Mike Vrbanac)
IBM PC/AT 80286 7.5 Venix/286 SVR2.1 cc Venturcom 2.2 small 1162 1256 8/11/86 Rick Richardson pcrat!rick
Compaq Compaq II 80286 8 MS-DOS 3.1 Microsoft 3.0 medium 1190 1282 3/3/86 meccts!ahby (Shane McCarron)
DEC MicroVAX II Mach 4.3 cc 1361 1385 2/23/86 wb1.cs.cmu.edu!avie (Avadis Tevanian)
DEC MicroVAX II Ultrix-32m 1.1 cc 1385 1399
Compaq Compaq II 80286 8 MS-DOS 3.1 Microsoft 3.0 small 1351 1428 3/3/86 meccts!ahby (Shane McCarron)
DEC VAX 11/780 UNIX 4.2BSD cc 1417 1441 3/25/86 rdlvax!carande (Richard Carande)
DEC VAX 11/780 MA780 Mach 4.3 cc 1428 1470 2/23/86 wb1.cs.cmu.edu!avie (Avadis Tevanian)
IBM PC/AT 80286 9.05 XENIX SCO SVR2.1 cc small 1464 1484 4/11/86 reed!omen!caf (Chuck Forsberg)
Apollo DN330 68020 12.5 Domain/IX cc 4.08 w/o 020 1504 1504 4/3/86 bambi!mike (Mike)
DEC VAX 11/780 UNIX 5.0.1 cc 4.1.1.31 1650 1640 2/20/86 solar!eds (E.D.Shultz)
Apollo DN330 68020 12.5 Domain/IX cc 4.08 w/ 020 1677 1677 4/3/86 bambi!mike (Mike)
Ridge 32C V1 ROS 3.3 Ridge (older) 1628 1695 3/5/86 jplgodo!steve (Steve Schlaifer)
Gould PN6005 UTX 1.1c+ cc 1732 1884 3/6/86 dukebar!ndd (Ned Danieley)
DEC VAX 11/785 UNITY/VMS 5.2.2 pcc 4.3 2063 2069 5/2/86 mcvax!enstvax!dax (Philippe Dax)
HP 9000-320 68020 16.67 HP/UX 5.02 B 9000/320 2464 2671
Sun 3/160 68020 16.67 Sun 4.2 3.0A cc 2946 3246 4/9/86 otto!carl (Carl Shapiro)
ISI Optimum V 68020 16 UNIX 4.2BSD r3.05 ISI 3245 3391 4/23/86 isieng!karen (Karen Murphy)
IBM 4341-12 Amdahl UTS V cc 1.11 3690 3690 5/1/86 cit-vax!newton (Mike Newton)
IBM 4341-12 Amdahl UTS V cc 1.11 3910 3910 Mike Newtons "optimzer" 5/1/86 cit-vax!newton (Mike Newton)
ISI Optimum V 68020 16 UNIX 4.2BSD r3.05 Green Hills 1.8.0 3778 3977 4/23/86 isieng!karen (Karen Murphy)
Celerity C-1230 NCR uP 10 UNIX 4.2BSD cc 4155 4360 5/5/86 glacier!mtu!pop (Dave Poplawski)
Gould PN9080 UTX-32 1.1C cc 4745 4992 2/22/86 bullwinkle!jqj (J.Q.Johnson)
DEC VAX 11/784 Mach 4.3 cc 5263 5555 1D on 4P 2/23/86 wb1.cs.cmu.edu!avie (Avadis Tevanian)
IBM 4381-2 VM/SP 3.18 Waterloo 1.2 5681 5681 4/7/86 UCF1VM!WOODRUFF (Mark Woodruff)
DEC VAX 8600 UNIX 4.3BSD cc 6329 6423 2/27/86 utah-cs!b-davis (Brad Davis)
IBM 4381-2 Amdahl UTS V cc 1.11 6440 6440 5/1/86 cit-vax!newton (Mike Newton)
IBM 4381-2 Amdahl UTS V cc 1.11 6850 6850 Mike Newtons "optimizer" 5/1/86 cit-vax!newton (Mike Newton)
Amdahl 5860 UTS V cc 1.22 28735 28846 2/23/86 attunix!mjs (Marty Shannon)
IBM 3090/200 31250 31250 2/19/86 bu-cs!bzs (Barry Shein)
Sun 2/120 68010 10 UNIX 4.2BSD cc no -O 950 1051 6/9/86 sdcrdcf!alex (Alex Hwang)
Encore Multimax 32032 10 Umax 4.2 R2.0 or V R1.0 Green Hills 1360 1360 6/13/86 encore!pinocchio!grier (Jim Grier)
Racal Redac 68010 10 Root V.2 pcc-2 490 525 6/12/86 mcvax!rootcl!njh (Nigel Horne)
Tadpole Titan 68010 10 Root V pcc 823 882 6/12/86 mcvax!rootcl!njh (Nigel Horne)
Phillips 68000 8 Root V.2 pcc-2 313 333 6/12/86 mcvax!rootcl!njh (Nigel Horne)
DEC VAX 11/750 Root 4.2 cc 835 859 6/12/86 mcvax!rootcl!njh (Nigel Horne)
DEC VAX 11/750 BRL Sys V on 4.2BSD 5bin/cc 836 845 6/12/86 mcvax!rootcl!njh (Nigel Horne)
DEC PDP 11/44 UNIX Sys III cc 884 951 6/12/86 mcvax!rootcl!njh (Nigel Horne)
Plessey system68 68000 8 Root V pcc 408 436 6/12/86 mcvax!rootcl!njh (Nigel Horne)
VT 68000 8 Root V.2 pcc2 422 451 6/12/86 mcvax!rootcl!njh (Nigel Horne)
IMP Mentor 68020 16 Root V.2 pcc-2 2632 2747 6/12/86 mcvax!rootcl!njh (Nigel Horne)
Armstrong 68000 Root V pcc 342 363 6/12/86 mcvax!rootcl!njh (Nigel Horne)
benchMark 32016 10 Root V.2 pcc2 643 673 6/12/86 mcvax!rootcl!njh (Nigel Horne)
Torch Triple X 68010 Root V pcc 578 625 6/12/86 mcvax!rootcl!njh (Nigel Horne)
Sequent Balance 8000 32032 10 Dynix cc 1097 1137 6/12/86 mcvax!rootcl!njh (Nigel Horne)
Atari 520/ST 68000 8 TOS Lattice 3.03.01 446 450 6/19/86 prle2!slavenbg (Gert Slavenburg)
Celerity 1260 UNIX 4.2BSD r3.2 8321 8384 6/27/86 celerity!celit!bobbyo (Bob Ollerton)
Celerity C1230 UNIX 4.2BSD r3.2 4702 4716 6/27/86 celerity!celit!bobbyo (Bob Ollerton)
Celerity 1200 UNIX 4.2BSD r3.2 3921 3916 6/27/86 celerity!celit!bobbyo (Bob Ollerton)
Siemens PC-MX2 32016 10 Root V.2 cc 717 745 7/1/86 mcvax!rootcl!njh (Nigel Horne)
Stride 68010 10 UniStride SVR2 cc 1164 1252 7/3/86 stride!bruce (Bruce Robertson)
IBM PC/AT 80286 9 UNIX Microport SVR2 cc small 1976 1976 7/12/86 umix!b-tech!zeeff (Jon Zeeff)
ATI 2000 80286 8 UNIX Microport SVR2 cc small 2145 2145 0 wait state AT clone 7/16/86 wb6rqn!brian (Brian Lloyd)
ATI 2000 80286 8 UNIX Microport SVR2 cc large 1440 1440 0 wait state AT clone 7/16/86 wb6rqn!brian (Brian Lloyd)
NCR PC-8 80286 8 XENIX SCO SVR2.0.4 cc small 1283 1299 7/30/86 unido!tub!net (Oliver Laumann)
NCR PC-8 80286 8 XENIX SCO SVR2.0.4 cc middle 981 983 7/30/86 unido!tub!net (Oliver Laumann)
NCR PC-8 80286 8 XENIX SCO SVR2.0.4 cc large 653 649 7/30/86 unido!tub!net (Oliver Laumann)
Cromemco Z2 Z80 4 Cromix 11.26 ccc 127 127 8/5/86 Requested Anonimity
AT&T 3B2/310 32100 UNIX SVR2.4 cc 668 671 8/5/86 Requested Anonimity
DEC PDP-11/73 J-ll,w/FPA UNIX 2.9BSD cc 772 875 8/5/86 Requested Anonimity
Sun 2/120 68010 10 UNIX Sun 2.2 cc 1058 1142 8/5/86 Requested Anonymity
Pyramid 90x XBIF 8 OSx 3.1 CLE 3.2.0 1779 1779 8/5/86 Requested Anonymity
Counterpoint 68020 12 UNIX SV cc 1702 1850 8/5/86 Requested Anonymity
Sun 3/50 68020 15 UNIX Sun 3.0 cc 2280 2540 8/5/86 Requested Anonymity
Pyramid 90x DCU 8 OSx 3.1 CLE 3.2.0 2898 2898 8/5/86 Requested Anonymity
Sun 3/160 68020 16.67 UNIX Sun 3.0 cc -fsoft 2921 3229 8/5/86 Requested Anonymity
Sun 3/160 68020 16.67 UNIX Sun 3.0 cc -f68881 2949 3236 8/5/86 Requested Anonymity
ISI Optimum 68020 16.67 UNIX ISI 3.0.1 cc 3074 3452 8/5/86 Requested Anonymity
Pyramid Workcenter DCU 10 OSx 3.1 CLE 3.2.0 3627 3627 8/5/86 Requested Anonymity
Pyramid 98xe DCU 10 OSx 3.1 CLE 3.2.0 3627 3627 8/5/86 Requested Anonymity
Pyramid 98X DCU 10 OSx 3.1 CLE 3.2.0 3671 3671 8/5/86 Requested Anonymity
Pyramid 98xe DCU,FPA 10 OSx 3.1 CLE 3.2.0 3773 3773 8/5/86 Requested Anonymity
Pyramid 98X DCU,FPA 10 OSx CLE 3.2.0 3856 3856 8/5/86 Requested Anonymity
AT&T 3B2/300 32000 7.2 UNIX SVR2.0.4 cc 685 688 8/5/86 unirot!halloran (Bob Halloran)
AT&T 3B2/400 32100 10 UNIX SVR2.0.4 cc 1108 1120 8/5/86 unirot!halloran (Bob Halloran)
AT&T 3B2/300 32000 7.2 UNIX SVR2.0 cc 409 410 8/5/86 mcvax!steven (Steven Pemberton)
IBM PC/XT 8088 4.77 MS-DOS 2.0 Microsoft 3.01 326 347 8/5/86 mcvax!steven (Steven Pemberton)
Gridcase 3 80C86 4.77 MS-DOS 2.11 Microsoft 3.01 409 438 8/5/86 mcvax!steven (Steven Pemberton)
Apricot portable 8086 5 MS-DOS 2.11 Microsoft 3.01 375 400 8/5/86 mcvax!steven (Steven Pemberton)
Whitechapel MG1 32016 8 UNIX 4.2BSD cc 636 675 8/5/86 mcvax!steven (Steven Pemberton)
DEC VAX 11/780 UNIX 4.2BSD cc 1243 1307 8/3/86 bgsuvax!gruber (John Gruber)
DEC VAX 11/785 UNIX 4.2BSD cc 1783 1813 8/3/86 bgsuvax!gruber (John Gruber)
DEC 2060 TOPS 20 pcc 1677 1736 8/3/86 bgsuvax!gruber (John Gruber)
IBM 4381-2 c/370 4504 4901 8/3/86 bgsuvax!gruber (John Gruber)
Arete 1100/1200 68020 12 UNIX SVR2.2 Motorola pcc2 2741 2808 5/4/86 arete!stone (David Stone)
Sun 3/160 68020 16.67 UNIX Sun 3.0 cc 2843 3134 4/7/86 hoptoad!gnu (John Gilmore)
Sun 1/100U UNIX Sun 2.0 cc 957 1029 4/6/86 lll-lcc!tflop!mac (Mike McNamara)
Sun 1/100U UNIX Sun 2.0 Greehills 1039 1075 4/6/86 lll-lcc!tflop!mac (Mike McNamara)
NCR Decision Mate 5 8088 4.77 MS-DOS 2.11 Lattice 2.14 small 166 166 4/18/86 ncr-sd!se-sd!cbk (Carl Kuck)
NCR PC4 8088 MS-DOS 2.11 Lattice 2.14 small 212 212 4/18/86 ncr-sd!se-sd!cbk (Carl Kuck)
NCR Decision Mate 5 8088 4.77 MS-DOS 2.11 Lattice 3.0g small 250 250 4/18/86 ncr-sd!se-sd!cbk (Carl Kuck)
NCR PC4 8088 4.77 MS-DOS 2.11 Lattice 3.0g small 322 322 4/18/86 ncr-sd!se-sd!cbk (Carl Kuck)
NCR PC6 8088 8 MS-DOS 2.11 Lattice 2.14 small 349 349 4/18/86 ncr-sd!se-sd!cbk (Carl Kuck)
NCR PC6 8088 8 MS-DOS 2.11 Lattice 3.0g small 512 512 4/18/86 ncr-sd!se-sd!cbk (Carl Kuck)
Amiga 1000 Manx C 2.30a 643 684 32 bit int 4/20/86 iuvax!jec (James Conley)
Amiga 1000 Manx 2.30a 880 915 16 bit int 4/20/86 iuvax!jec (James Conley)
Zilog 8000 model 31 Z8001 6 Zeus 3.21 cc non-segment 831 878 4/20/86 drilex!dricej (Craig Jackson)
Zilog 8000 model 31 Z8001 6 Zeus 3.21 cc segmented 727 758 4/20/86 drilex!dricej (Craig Jackson)
IBM PC/RT (6150)w/FPA AIX SVR1 cc 1537 1660 5/22/86 ukma!david (David Herron)
Sun 2 UNIX 4.2BSD cc 1034 1110 5/17/86 a.psy.cmu.edu!bader (Miles Bader)
DEC Micro VAX II Ultrix 1.1 cc 1379 1394 5/17/86 a.psy.cmu.edu!bader (Miles Bader)
IBM PC/RT UNIX 4.2BSD cc 1333 1510 5/17/86 a.psy.cmu.edu!bader (Miles Bader)
IBM PC/AT 80286 8 PC-DOS 3.20 Microsoft 4.0 1729 1796 8/11/86 microsof!stevesa
IBM PC/AT 80286 8 PC-DOS 3.20 Microsoft 4.0 small 2176 2239 w/Cheetah 0 ws memory 8/11/86 microsof!stevesa
HP 9000-500 1 CPU, Rev B 18 HP-UX 5.05 cc 1599 1599 5/11/86 hpfcla!bury (Robert Bury)
HP 9000-500 2 CPUs, Rev B 18 HP-UX 5.05 cc 3020 3020 Two copies run and added 5/11/86 hpfcla!bury (Robert Bury)
HP 9000-500 3 CPUs, Rev B 18 HP-UX 5.05 cc 4140 4140 Three copies run and added 5/11/86 hpfcla!bury (Robert Bury)
AT&T 3B15 32100 14 UNIX 5.2.1 cc 1797 1798 8/19/86 unirot!halloran (Bob Halloran)
AT&T 3B2/300 32000 7.7 UNIX SVR3.0 cc 699 697 8/20/86 unirot!halloran (Bob Halloran)
Compaq 386 80386 16 PCDOS 3.1 Lattice 3.00H small 2941 2941 9/16/86 3comvax!Marc_Lavine
Compaq 386 80386 16 PCDOS 3.1 Lattice 3.00H large 1724 1724 9/16/86 3comvax!Marc_Lavine
Compaq 386 80386 16 PCDOS 3.1 Lattice 3.00H large data 2000 2000 9/16/86 3comvax!Marc_Lavine
Compaq 386 80386 16 PCDOS 3.1 Lattice 3.00H large data 2631 2631 9/16/86 3comvax!Marc_Lavine
Victor Sirius 8088 MSDOS 2.11 Microsoft 3.0 small 357 381 9/26/86 unido!pbinfo!michael (Michael Schmidt)
Victor Sirius 8088 MSDOS 2.11 Microsoft 3.0 middle 317 335 9/26/86 unido!pbinfo!michael (Michael Schmidt)
Victor Sirius 8088 MSDOS 2.11 Microsoft 3.0 large 284 295 9/26/86 unido!pbinfo!michael (Michael Schmidt)
MIPS M/500 R2000 8 UNIX 4.3BSD cc 8855 10309 10/8/86 mips!mash (John Mashey)
Apple Mac+ 68000 7.8 Mac 3.2 Manx 1.06H 714 769 16 bit int 8/21/86 tekcbi!larryh
Motorola MVME121 68010 10 Uniflex cc 1.3:0 820 865 MVME320,050 8/21/86 tekcbi!larryh
GMX Micro-20 68020 12.5 OS-9 1.2 Microware 2.0 1315 1250 9/4/86 rochester!dibble
National VR332 32332 15 UNIX SVR2.2 NSC GNX 2 -O 2851 2851 10/2/86 nsc!curry (Ray Curry)
Celerity 1260-D 1230 4.2 BSD 3.2.50 cc standard -O 4010 4045 A 1260-D is a dual-processor 1230 10/15/86 seismo!rick (Rick Adams)
Celerity 1260-D 1230 4.2 BSD 3.2.50 cc beta test -O 4046 4061 A 1260-D is a dual-processor 1230 10/15/86 seismo!rick (Rick Adams)
IBM PC/AT 80286 6 MS-DOS 3.1 Lattice 3.00h 943 925 10/16/86 bnrmtv!blob (Brian Bechtel)
IBM PC/AT 80286 6 MS-DOS 3.1 Lattice 3.00h -ml (large model) 531 531 10/16/86 bnrmtv!blob (Brian Bechtel)
Gould PN 9080 UTX 2.0 beta cc 6024 6340 15 Oct. 1986 utah-cs!peter
National Semiconductor ICM-3216 32016 10 UNIX SVR2 cc 2688 Wouldn't run noreg 10-16-86 astroatc!crowley
Motorola System 1131 MC68020 16.67 System V R2V2.2 pcc2 High level Optim and peep Optim ATT -O 3246 3257 10/16/86 Brad Holtzinger hplabs!motsj1!bjh
MASSCOMP 5600; 1 CPU 68020/68881 16.67 RTU 3.0 cc 1.121 4161 4155 TOO LONG LOST BAD ENTRY
PRIME 9955 PRIMIX 1.2 CC 4.0-19.4 -OPTIMIZE -HIGH 1633 1633 Primix (Unix) on top of Primos 20.0.4 10/15/86 uw-atm!harry (Harry Edmon)
PRIME 9955 PRIMOS 20.0.4 CC 4.0-19.4 -OPTIMIZE -HIGH 2859 2859 V-mode compiler 10/15/86 uw-atm!harry (Harry Edmon)
PRIME 9955 PRIMOS 20.0.4 CI 4.0-19.4 -32IX 3348 3348 I-mode compiler 10/15/86 uw-atm!harry (Harry Edmon)
PRIME 9955 PRIMOS 20.0.4 CI 4.0-19.4 -32IX -INTRINSIC strcpy 3492 3492 10/15/86 uw-atm!harry (Harry Edmon)
Apple Macintosh 512E 68000 8 Mac Finder 5.1, System 3.2 LightSpeed C 1.02 510 549 with new, 128K ROMs 10/17/86 bnrmtv!blob (Brian Bechtel)
Ridge Computers Ridge 3200 Proprietary 12 ROS 3.4 rc 2.0 none 6119 6240 Oct 17, 1986 hplabs!ridge!dc (Dave Cornelius)
Apple Lisa 2/10 68000 5 XENIX 3.0 Priam cc 505 533 10/21/86 ihnp4!meccts!mecc!sewilco (Scot E. Wilcoxon)
AT&T 3B5 WE32000 10 UNIX SVR2 5.2.0.1 V2 cc ? large 578 573 10/22/86 isucs1!davis
DEC PDP-11/45 ? UNIX V7M cc ? 256KB 454 506 10/22/86 isucs1!davis
CCI Power 5/32 68010 12.5 Unix BSD 4.2 cc ? 1135 1192 10/21/86 ..!rochester!walden!jjg
OPUS SYSTEMS Opus 32.16 32016 10 Opus5(UNIX) 2.0v2C2.1 cc SysV.2.0 Ver 1.5 736 776 hosted on IBM PC/AT 10/26/1986 Greg Woodbury (ggw@ethos.UUCP)
APOLLO DN330 68020/68881 12.5 Domain/IX SR9.5.Bl12 CC 4.58 w/o 020,68881 1934 1934 (Beta OS and Compiler) 10/27/86 decvax!wanginst!apollo!swin (Stan Swiniarski)
APOLLO DN330 68020/68881 12.5 Domain/IX SR9.5.Bl12 CC 4.58 w/020,68881 2046 2046 (Beta OS and Compiler) 10/27/86 decvax!wanginst!apollo!swin (Stan Swiniarski)
APOLLO DN3000 68020/68881 12.5 Domain/IX SR9.5.Bl12 CC 4.58 w/o 020,68881 2481 2481 (Beta OS and Compiler) 10/27/86 decvax!wanginst!apollo!swin (Stan Swiniarski)
APOLLO DN3000 68020/68881 12.5 Domain/IX SR9.5.Bl12 CC 4.58 w/020,68881 2643 2643 (Beta OS and Compiler) 10/27/86 decvax!wanginst!apollo!swin (Stan Swiniarski)
Counterpoint Computers System 19 68020 16.67 UNIX SVR2.2 Motorola pcc2 2270 2481 Single uP; 1-8 possible 11/12/86 castor!ihnp4!hplabs!oblio!kent (Kent Peacock - Counterpoint)
Altos Computer Systems ACS 68000 68000 8 UNIX System III, Altos Release 2.0 cc -- 440 450 10/17/86 pyramid!ntc!olaf (Olaf Kaestner)
Intel 386/24 system 310 80386 16 UNIX System V.3 beta rcc 2.01 4725 5089 386 Multibus I w/64KB cache 12/5/86 tomk@intsc.uucp (Tom Kohrs)
Intel 386/24 system 310 80386 16 UNIX System V.3 beta greenhills cc v1.8.2C 6250 6250 386 Multibus I w/64KB cache 12/5/86 tomk@intsc.uucp (Tom Kohrs)
Intel 386/24 system 310 80386 20 UNIX System V.3 beta rcc 2.01 5966 6394 386 Multibus I w/64KB cache Dec 5, 1986 tomk@intsc.uucp (Tom Kohrs)
Intel 386/24 system 310 80386 20 UNIX System V.3 beta greenhills cc v1.8.2C 7810 7810 386 Multibus I w/64KB cache Dec 5, 1986 tomk@intsc (Tom Kohrs)
Intel 386/20 80386 16 UNIX SVR3 Green Hills C-386 1.8.2E none 6995 6677 -O means loop optimize, qed faster NOREG Sun Dec 7 13:42:36 PST 1986 ihnp4!ghsvax!carl (Carl Rosenberg)
Plessey Mantra 68010 12 Root V.2 pcc2 1089 1157 10/21/86 mcvax!root44!root (Nigel Horne)
Hazelwood Uniquad 1 68008 8 OS-9 1.2 Microware 2.0 243 259 11/05/86 uw-vlsi!eldec!swifty (Steve Swifty)
Commodore 64 6510 1 C64 ROM C Power 2.9 trim 19 34 12/01/86 prindle@NADC.arpa (Frank Prindle)
Commodore 128 8502 2 C128 ROM C Power 128 trim 43 68 12/01/86 prindle@NADC.arpa (Frank Prindle)
Sherry AT 80286 8 MSDOS MS 3.0 /Ot/AS/Gs/G2 1724 12/03/86 mcvax!uva!schilder (Marius Schilder)
Genisys AT 80286 10 MSDOS MS 3.0 /Ot/AS/Gs/G2 2777 12/03/86 mcvax!uva!schilder (Marius Schilder)
Olivetti m24 8086 8 MSDOS MS 3.0 /Ot/AS/Gs 847 12/03/86 mcvax!uva!schilder (Marius Schilder)
Olivetti m24 V30 8 MSDOS MS 3.0 /Ot/AS/Gs/G0 1086 12/03/86 mcvax!uva!schilder (Marius Schilder)
Olivetti m24 V30 8 MSDOS MS 3.0 /Ot/AS/Gs/G1 1111 12/03/86 mcvax!uva!schilder (Marius Schilder)
SHAR_EOF
fi
exit 0
# End of shell archivedave@onfcanim.UUCP (02/05/87)
Does it bother anyone else that the dhrystone benchmark is
sometimes (if TIME instead of TIMES is used) based on execution
time of a small number of seconds, measured to the nearest second?
Many of the faster machines execute the benchmark in 10 seconds or less,
giving a result that may have +- 10% error. Doesn't it then seem silly
to quote "dhrystones" as 4-figure numbers?
If TIME is defined, longer execution times (by a factor of 10 at least)
should be used.
And when TIMES is being used, although much better resolution is
available, we can't tell this by looking at the fractional part
of the elapsed time, since it is always truncated to the nearest
integer. How about changing the code:
printf("Dhrystone(%s) time for %ld passes = %ld\n",
Version,
(long) LOOPS, benchtime/HZ);
to:
long hundredths;
hundredths = (benchtime*100 + HZ/2)/HZ;
printf("Dhrystone(%s) time for %ld passes = %ld.%02ld\n",
Version,
(long) LOOPS, hundredths/100, hundredths%100);eugene@pioneer.UUCP (02/06/87)
>From: dave@onfcanim.UUCP (Dave Martindale) >Subject: Re: 01/31/87 Dhrystone Results and Source > >Does it bother anyone else that the dhrystone benchmark is >sometimes (if TIME instead of TIMES is used) based on execution >time of a small number of seconds, measured to the nearest second? > >Many of the faster machines execute the benchmark in 10 seconds or less, >giving a result that may have +- 10% error. Doesn't it then seem silly >to quote "dhrystones" as 4-figure numbers? This is a problem with any "improving" single-figure of merit. You can certainly bring in all the statistical tools you want (you did not use the word variance or SD), but it won't solve the problem, statistics won't solve the problem. We have to go back to a time when it was believed that measurement was not a statistical issue [I've had rocks thrown at me when I've said this in the past, and I know their read this]. So, no, it no longer bothers me. From the Rock of Ages Home for Retired Hackers: --eugene miya NASA Ames Research Center eugene@ames-aurora.ARPA "You trust the `reply' command with all those different mailers out there?" "Send mail, avoid follow-ups. If enough, I'll summarize." {hplabs,hao,nike,ihnp4,decwrl,allegra,tektronix,menlo70}!ames!aurora!eugene P.S. Are there any fishermen (fisherhumans) on comp.arch? Does anybody know where I can get one of those gag fishing rules to measure your fish longer than they really are?
gemini@homxb.UUCP (02/07/87)
>From: dave@onfcanim.UUCP (Dave Martindale) >Subject: Re: 01/31/87 Dhrystone Results and Source > >Does it bother anyone else that the dhrystone benchmark is >sometimes (if TIME instead of TIMES is used) based on execution >time of a small number of seconds, measured to the nearest second? > >Many of the faster machines execute the benchmark in 10 seconds or less, >giving a result that may have +- 10% error. Doesn't it then seem silly >to quote "dhrystones" as 4-figure numbers? The TIME define is only for use when a machine doesn't have TIMES, which isn't many machines (mostly non-UNIX ones). The instructions say to use 500000 loops (instead of 50000) for fast machines. And the report of the elapsed time, in whole seconds, is just for the purpose of determining when you have a 'fast' machine on your hands. The actual calculation of the figure of merit is done using the granularity of the TIMES (or TIME) system call. If this program didn't have to run on so many different OS's, I'd consider rummaging around and configuring it for the environment. But since it has to run on DOS, UNIX, VMS, ad nauseum, it'll just have to be up to the intelligence of the benchmarker to follow the instructions. Besides, anybody who quibbles over a 10% difference isn't looking at the whole picture when selecting a machine. Dhrystones just get you looking at the right performance arena. Other factors (software, support, migration path, etc.) will get you to the final decision. Hypothetical discussion: Mgr: "the VAX 8600 and IBM 4381-2 turn about 6000 'stones, which should we buy?" MISmgr: "Well, i've got IBM stock, get the IBM" Engin: "Well, we have 4 zillion lines of code for the 11/780, lets get the 8600". Rick Richardson, PC Research, Inc. (201) 922-1134, (201) 834-1378 @ AT&T-CP ..!ihnp4!castor!{rer,pcrat!rer} <--Replies to here, not to homxb!gemini, please.
jbs@mit-eddie.UUCP (02/08/87)
In article <2366@homxb.UUCP> gemini@homxb.UUCP (Rick Richardson) writes: >Hypothetical discussion: >Mgr: "the VAX 8600 and IBM 4381-2 turn about 6000 'stones, > which should we buy?" >MISmgr: "Well, i've got IBM stock, get the IBM" >Engin: "Well, we have 4 zillion lines of code for the 11/780, lets > get the 8600". And which one do you think they bought? :-) Jeff Siegal
mash@mips.UUCP (02/09/87)
In article <2366@homxb.UUCP> gemini@homxb.UUCP (Rick Richardson) writes: ...TIME, TIMES, Dhrystone accuracy, etc.... > >Besides, anybody who quibbles over a 10% difference isn't looking >at the whole picture when selecting a machine. Dhrystones just >get you looking at the right performance arena. Other factors >(software, support, migration path, etc.) will get you to the >final decision. 1) This seems like a reasonable answer, which is in agreement with Gene Miya's adverse comments on ANY single figure of merit. [That's why we end up publishing a Performance Brief that's pretty large, to include enough different benchmarks and explanations to have even a chance of meaning anything.] 2) I'd generally consider Dhrystone to have about a single digit of accuracy. In particular, there are all sorts of anomalies with regard to heavily-cached machines, and the rules regarding allowable optimizations. For example, on "realistic" integer benchmarks, our "5MIPS" M/500s are about 20% faster than a "4MIPS" VAX 8600, and many hours of working on both says this is consistent, although the Dhrystone numbers would claim the M/500 (somewhere in the 10-12,000 range, depending on exactly what optimizations are/aren't allowed for consistency) is 1.7X to 1.9X the 8600's 6000-7000. I'd strongly expect that Dhrystone often overstates the performance of some micros relative to superminis: for example, Intergraph's recently published numbers for it's 30Mhz Clipper box include about 8300 Dhrystones, making it look faster than the 8600, even though it was somewhat/substantially slower on any of the more realistic benchmarks that they showed. 3) As Rick has always maintained, things like Dhrystone [or Whetstone, or Linpack, or...] are just a starting point. However, as it stands, Dhrystone is the only integer benchmark of any size whatsoever [since things like Ackerman's function, sieve, etc are way too small to be good predictors of anything] that is commonly cited and collected. Maybe it's time to either create a Dhrystone 2.0, or some other integer benchmark to get at least 1 figure of merit that's a bit better, although there is still no substitute for running the real applications. 4) How about some suggestions for ways to improve Dhrystone? (This is not necessarily an attempt to make it "perfect" (no such thing) or even necessarily a good model for operations statistics, but at least to make some obvious improvements.) Here are a few suggestions for starters: a) Eliminate the problems that stop one from using real optimizers. As it stands, it is very hard to compare any numbers, since you don't know what sorts of optimizations are done. This is particularly handicapping to those of us who have real optimizers, but can't use them for the test. In some cases, if you eliminate the global optimizer, you also eliminate optimizations which are included in other people's compilers [that don't have separate optimizers], so they get the benefit of the techniques. Note that real optimizers are much more prevalent than they were when Dhrystone was proposed. As Rick says in his Dhrystone notes: "To summarize, DHRYSTONES by themselves are not anything more than a way to win free beers when arguing 'Box-A versus Box-B' religion. They do provide insight into Box-A/Compiler-A versus Box-A/Compiler-B comparisons." Right now, the best compilers are penalized [10-20%, from our numbers]. b) STRCPY: we've seen strcpy take up to 30% of the execution time. Does anybody have any real nubmers of real programs on the real usage patterns for the str* and mem* routines? [Call frequency, distribution of string sizes, etc] We suspect that there's more strcpy time than most real programs. c) Other areas [much more work]: 1) Make program bigger to avoid small-cache effects. 2) Rework overall program behavior to be more like substantial programs [we do a lot of statistics-gathering on references, instructions frequency, branch counts, function calls, etc, and Dhrystone as it sits isn't excpetionally representative.] Enough: again, no 1 figure-of-merit does it, but let's at least keep this one in proper perspective [which I think Rick does]. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
news@cit-vax.UUCP (02/09/87)
Organization : California Institute of Technology Keywords: Benchmark, C, performance measurement, strcpy From: jon@oddhack.Caltech.Edu (Jon Leech) Path: oddhack!jon In article <112@winchester.mips.UUCP> mash@winchester.UUCP (John Mashey) writes: >b) STRCPY: we've seen strcpy take up to 30% of the execution time. >Does anybody have any real nubmers of real programs on the real usage >patterns for the str* and mem* routines? The text editor I maintain (which bears no relationship to any variant of EMACS, incidentally), runs ~5-10% strcpy on a 4.2 BSD Vax 780, in average use (according to gprof). Said usage could be reduced by perhaps 2x if I spent the time to clean up the code. -- Jon Leech (jon@csvax.caltech.edu || ...seismo!cit-vax!jon) Caltech Computer Science Graphics Group __@/
bright@dataio.UUCP (02/10/87)
In article <112@winchester.mips.UUCP> mash@winchester.UUCP (John Mashey) writes: >4) How about some suggestions for ways to improve Dhrystone? Make the computations 'do something', so that an optimizing compiler won't simply delete them. The Datalight optimizing C compiler deletes (correctly) much of Dhrystone, because it determines that many of the statements cannot serve any useful purpose. Test the results of the computations so that not only do you know how fast the benchmark ran, but if the correct result was obtained. For an example of this, in the Feb 87 Computer Language benchmark program, they test out the compiler's qsort() function. Unfortunately, the code to the benchmark program had a bug in it which caused the results to be rather random. It's simple enough to see if qsort() worked. Computer Language did its readers a disservice by publishing such stuff. For instance, with sieve, if you don't get 1899 out, your compiler blew it.
jgp@moscom.UUCP (02/12/87)
In article <15203@onfcanim.UUCP> dave@onfcanim.UUCP (Dave Martindale) writes: >Does it bother anyone else that the dhrystone benchmark is >sometimes (if TIME instead of TIMES is used) based on execution >time of a small number of seconds, measured to the nearest second? > >Many of the faster machines execute the benchmark in 10 seconds or less, >giving a result that may have +- 10% error. Doesn't it then seem silly >to quote "dhrystones" as 4-figure numbers? > >If TIME is defined, longer execution times (by a factor of 10 at least) >should be used. > >And when TIMES is being used, although much better resolution is >available, we can't tell this by looking at the fractional part >of the elapsed time, since it is always truncated to the nearest >integer. The trucated elapsed time is printed but the full time is used for the dhrystones/second calculation. There is still a problem on fast machines (esp when TIME is used). Why not instist that LOOPS be adjusted to force the benchmark to take about 60 seconds to run. This could even be done automatically by having the program time a single loop and then decide what LOOPS needs to be. Another problem is that the variable used to count to LOOPS is declared as an unsigned int. This really should be a long so that fast machines with 16 bit int's (small model 80?86) can have a hope of being able to run long enough to get accurate times. The looping time itself is factored out of the benchmark so changing it shouldn't affect the actual dhyrstone/sec measurement. -- Jim Prescott rochester!moscom!jgp
phr@mit-hermes.UUCP (02/12/87)
Can someone tell me how to get a copy of the Dhrystone benchmarks, preferably by ftp? I don't mean the RESULTS of the benchmarks that are posted here periodically; I mean the program suite itself. I'd like to test out a new compiler with it. Thanks.
eugene@pioneer.UUCP (02/13/87)
Walter Bright says >(John Mashey) writes: >>4) How about some suggestions for ways to improve Dhrystone? >Make the computations 'do something', so that an optimizing compiler >won't simply delete them. The Datalight optimizing C compiler deletes >(correctly) much of Dhrystone, because it determines that many of the >statements cannot serve any useful purpose. Do something? Sure This is called EXPERIMENT CONTROL. It's really lacking in computer science (some say sic). You need to learn about (as well as Weicker, author of DSTONES), what's called the "Pre-test Condition," the "Post-Test" Condition, and also during the test. You want to set something up called a CONTROL or CONTROL condition for comparison purposes. Pre-test conditions include flushing caches or page tables before hand. During test: avoid repetition, especially on machines which page. Repeating a section of code just because the clock is poor is not representative of the true running time of a machine, after the first repetition, your page tables are pre-filled and are not representative of the real running conditions of the machine. Another thing: take a chuck of code (we can control it later), throw the test section inside this chunk compare the two conditions. >QSORT example. Good example but consider how pattern of data access can effect the performance of a sort. My suggestion is perform at least three cases (if not more) in data sorting. 1) Random case, 2) case of already sorted arrays [minimum comparison and fetching], and 3) inversely ordered arrays. You might also have separate worst case data patterns depending on algorithm type (QSORT in this case). Don't be surpised at what you get. I have references to some good simple books on experiment control (not computer science texts] as well as several papers [surprise: some of the best are from IBM]. From the Rock of Ages Home for Retired Hackers: --eugene miya NASA Ames Research Center eugene@ames-aurora.ARPA "You trust the `reply' command with all those different mailers out there?" "Send mail, avoid follow-ups. If enough, I'll summarize." {hplabs,hao,nike,ihnp4,decwrl,allegra,tektronix,menlo70}!ames!aurora!eugene
reiter@endor.UUCP (02/13/87)
Has anyone actually tried to evaluate the Dhrystone (and other benchmarks) by seeing how well it predicts performance on real applications? It would seem straightforward to take ten random applications running on specific test data, measure their performance on some target machine/compiler combinations, and statistically analyze how much of the peformance differences had been predicted by the Dhrystone figures. The debate on flaws of the Dhrystone is quite interesting, but it would be nice to have some real data on how good or bad the Dhrystone was. I'm not even sure that a good benchmark is possible in principle - that is, I wonder whether it is possible to come up with a single number which can predict (with any reasonable accuracy) performance on a range of different applications. Ehud Reiter reiter@harvard (ARPA,UUCP,BITNET)
rcd@ico.UUCP (02/14/87)
(into the nest of replies we go...) In article <319@ames.UUCP>, eugene@pioneer.arpa (Eugene Miya N.) writes: > Walter Bright says > >(John Mashey) writes: > >>4) How about some suggestions for ways to improve Dhrystone? > >Make the computations 'do something', so that an optimizing compiler... Fair 'nuff...but how do you achieve that? You're not particularly likely to feel that you've got any control over which code the compiler will keep or throw out until you introduce some external data files. After all, if the program doesn't do any operations dependent on the world outside itself, the ultimate optimization is going to be just to figure out the whole program at compile time and produce, as object code, the calls to printf. [Digression intended for software philosophers: If the program contains calls to routines like time() or times(), doesn't that imply that the entire program is being executed for a side effect (of passing time) and hence that a <correct> optimizing compiler cannot elide <any> statements? But where does one draw the line between "necessary" and "unnecessary" statements? I suspect that with increasingly clever optimizers, if they were to come into existence, one would simply have to stop attempting to reduce the performance of an entire computer system to a single number and, instead, think about evaluating the system. But, as I said, I digress...] Miya continues, about testing methodology and controls: > ...During test: avoid repetition, especially on machines > which page. Repeating a section of code just because the clock is poor > is not representative of the true running time of a machine, after the > first repetition, your page tables are pre-filled and are not > representative of the real running conditions of the machine. This is at once astute and perverse! Of course, machines which must page during the execution of a program will show poorer performance than those which need not. But are we measuring the performance of the memory-manage- ment system as well? (I suggest strongly that <some> measure need be made, but I don't see that it can be realistically incorporated into Dhrystone.) There's another side to trying to fault (sic) the paging machine--it may do <less> disk activity in bringing in its code, since it need not bring it all in...and yes, programs which don't use all of their code in any given execution are quite common. But the perversity of the recommendation to avoid repetition is this: Paging systems are built, and work for many problems, based on the correct observation that most code spends most of its time in a few small locales withing the total code space. If a benchmark were to "avoid repetition", it would in fact be a very poor benchmark since it would fail to be a use- ful abstraction of real programs. -- Dick Dunn {hao,nbires,cbosgd}!ico!rcd (303)449-2870 ...If you plant ice, you're gonna harvest wind.
gemini@homxb.UUCP (02/15/87)
In article <1224@husc6.UUCP>, reiter@endor.harvard.edu (Ehud Reiter) writes: > Has anyone actually tried to evaluate the Dhrystone (and other benchmarks) > by seeing how well it predicts performance on real applications? It would > seem straightforward to take ten random applications running on specific test > data, measure their performance on some target machine/compiler combinations, > and statistically analyze how much of the peformance differences had been > predicted by the Dhrystone figures. Since Dhrystone does no I/O during the benchmark, I doubt that Dhrystone predicts performance of *ANY* application. Except perhaps other integer benchmarks! It's probably useful in predicting the performance of, say, qsort(3), UNIX's in core sort routine, and stuff like that. We've found it most useful in evaluating compiler code generation technology. Rick Richardson, PC Research, Inc. (201) 922-1134, (201) 834-1378 @ AT&T-CP ..!ihnp4!castor!{rer,pcrat!rer} <--Replies to here, not to homxb!gemini, please.
mash@mips.UUCP (02/16/87)
In article <1224@husc6.UUCP> reiter@harvard.UUCP (Ehud Reiter) writes: >Has anyone actually tried to evaluate the Dhrystone (and other benchmarks) >by seeing how well it predicts performance on real applications? It would >seem straightforward to take ten random applications running on specific test >data, measure their performance on some target machine/compiler combinations, >and statistically analyze how much of the peformance differences had been >predicted by the Dhrystone figures. 1) There's probably an interesting M.S. thesis in here somewhere. > >The debate on flaws of the Dhrystone is quite interesting, but it would be nice >to have some real data on how good or bad the Dhrystone was. I'm not even sure >that a good benchmark is possible in principle - that is, I wonder whether >it is possible to come up with a single number which can predict >(with any reasonable accuracy) performance on a range of different >applications. 2) Most people I know don't believe very much in single-number performance metrics. 3) Althought I raised this issue in the first place, there do appear to be a few applications that grossly correlate [and I mean grossly] with Dhrystone, i.e., if you saw the Performance Brief I posted here a few months ago, there was actually a reasonable correlation of it with things like grep/diff/yacc/nroff, i.e., integer user-level programs of moderate [but not huge] size, although it sometimes overstated the performance of small-cached micros versus superminis. This effect is typical of small benchmarks: if it fits into the cache, you get something that correlates a bit better with raw CPU/cache speed; the more it doesn't fit, the more you're measuring cache-main-memory performance. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
sbanner1@uvicctr.UUCP (02/16/87)
In article <589@ico.UUCP> rcd@ico.UUCP (Dick Dunn) writes: >(into the nest of replies we go...) >In article <319@ames.UUCP>, eugene@pioneer.arpa (Eugene Miya N.) writes: >> Walter Bright says >> >(John Mashey) writes: >> >>4) How about some suggestions for ways to improve Dhrystone? > one would simply have to stop attempting to >reduce the performance of an entire computer system to a single number and, >instead, think about evaluating the system. But, as I said, I digress...] I have been reading this series of articles with great intrest, as one of my pet projects is to write a program that will run a whole series of benchmarks on the given machine, and then compare the results with similar runs on whatever machines you have data for, then give some sort of "estimate" of the "power" of the machine relative to the others (or some sort of absolute measure, though I don't see how that is really possible), in various areas (a Cray1 is 1000000 times better than an IBM PC for numerical work, etc... :-). So, does anyone have any suggestions? Do you have benchmarks that you use (I have Dhrystone, Whetstone, and the Sieve (though I understand that there is some sort of standard for the Sieve, and mine is just what I whipped up; so if there is a standard for that I would verry much hearing about it, though by mail would be best I am sure)), that you would be willing to share? What do you think are the major requirements for benchmark (requirements in general, or with respect to your given field)? I would like to hear everyones comments on this, but I don't know just how interested everyone else is, so if you have comment that you don't want to post to the net (because you don't think people will be interested, or whatever), feel free to mail direct to me. Depending on the type of response I get, I will summarise what people have to say. Thanks, S. John Banner PS. When I say I am interested in benchmarks of all types, I do mean exactly that. My interest started as an interest in comparing various IBM PC clones, and hardware, and I would be interested in stuff which would demonstrate differences between the BIOS in one machine vs. another, or things that are specific to other machines, even though I might not be able to use them directly. Thanks, sjb. ...!{uw-beaver,ubc-vision}!uvicctr!sbanner1 ccsjb@uvvm sbanner1@uvunix.UVIC.CDN #1 1121 Fort St. Victoria BC. Canada V8V 3K9
bcase@amdcad.UUCP (02/16/87)
In article <2387@homxb.UUCP> gemini@homxb.UUCP (Rick Richardson) writes: >In article <1224@husc6.UUCP>, reiter@endor.harvard.edu (Ehud Reiter) writes: >> Has anyone actually tried to evaluate the Dhrystone (and other benchmarks) >> by seeing how well it predicts performance on real applications? It would >> seem straightforward to take ten random applications running on specific test >> data, measure their performance on some target machine/compiler combinations, >> and statistically analyze how much of the peformance differences had been >> predicted by the Dhrystone figures. > >Since Dhrystone does no I/O during the benchmark, I doubt that Dhrystone >predicts performance of *ANY* application. Except perhaps other integer >benchmarks! It's probably useful in predicting the performance of, >say, qsort(3), UNIX's in core sort routine, and stuff like that. We've >found it most useful in evaluating compiler code generation technology. Ahhh, now you're talking. This is one good use of the Dhrystone benchmark. I (we) have found it tremendously useful in evaluating the effects of little compiler tweeks. It is a short program, but it has most of the constructs that will occur commonly in real programs; thus, an optimization that affects the run time of dhrystone will probably affect the run time of a real program in a similar way. This does not mean that dhrystone will predict the absolute performance of that real program, but it can predict the relative performance of the two versions (one with the tweek one without) of that real program. bcase ----------- Watch this space!
johnw@astroatc.UUCP (02/18/87)
No, it is not possible to get a single figure of merit benchmark!
IBM has realized this for years and almost always quotes separate
comparison figures for "scientific" and "business" code. Floating
point a side, the IBM-business benchmarks have a higher density of
tests and branches. (Like Dhrystone, the IBM b-marks are tuned to
try to match sets of real applications) Given the two IBM-figures,
one can usually make a good guess as to how much performace boost
was achived from a faster clock, and how much was from increased
pipelining.
A Second comment:
I think there's nothing wrong with a "compiler" that "figures out"
what the program does and generates a direct call to "printf" but
if this is used, them it all fairness, I would insist that the
compile time also be included in its timing!!!
--> Are there any times of **COMPILE** time used to compile
d-stones for each of the machies?!
(I saw a comparison of Mac compilers, and the slowest produced
the fastest running code, but I'd still rather have the
fastest compiler, which happened to produce fairly reasonable
code too! -- I know it wasn't the slowest code!!!)
Anyway, how important is a 2:3 (or 9:10) ratio anyway?????
John W
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Name: John F. Wardale
UUCP: ... {seismo | harvard | ihnp4} !uwvax!astroatc!johnw
arpa: astroatc!johnw@rsch.wisc.edu
snail: 5800 Cottage Gr. Rd. ;;; Madison WI 53716
audio: 608-221-9001 eXt 110
To err is human, to really foul up world news requires the net!stubbs@ncr-sd.UUCP (02/19/87)
Another "problem" with Dhrystone which is also present in Dhampstone is that since they are single file programs they are subject to certain optimizations possible for machines with large numbers of registers such as allocating blocks of registers to procedures, and a different block of registers to the procedure it calls. The Stanford MIPS guys are looking at this. But this technique doesn't work too well on large real programs which either recurse or are multiple program files compiled separately and then linked together. Jan Stubbs ....sdcsvax!ncr-sd!stubbs 619 485-3052 NCR Corporation 16550 W. Bernardo Drive MS4010 San Diego, CA. 92127
pauls@mips.UUCP (02/20/87)
This is a request that the sender of the original Dhrystone Results article mail a copy to the following address: decwrl!mips!sheryls Sorry, but the original has already been deleted from our machines. pauls
bzs@bu-cs.UUCP (03/01/87)
Eugene Miya writes >You want to set something up called a CONTROL or CONTROL condition for >comparison purposes. Pre-test conditions include flushing caches or >page tables before hand. During test: avoid repetition, especially on >machines which page. Nothing wrong with this, but what's most important is that you agree on what are the intended methodology and hypotheses. Yours seems to be that the machines be compared with factors like caches, page tables and paging performance eliminated. There's nothing wrong with that. But there's nothing wrong in just plunking it down in a (reasonably zero-loaded, oops, another assumption) machine and just seeing how it runs. For example, I don't often 'ls' a directory twice in succession because I know the second one will be faster. Some of this may not be as problematic to the result as it first appears to one accustomed to purity in controls. It might be reality creeping in. -Barry Shein, Boston University