root@cca.ucsf.edu (Systems Staff) (10/07/89)
Since the output of Dhrystone 2.1 is considerably different from the
old version, here is a sample run.
The bulk of the output consists of pairs of lines. Most of these pairs
should contain two lines exactly alike. You should check this the
first time you run the program to verify its operation.
Note that the number at the end of the line:
Please give the number of runs through the benchmark: 10000
was typed in. With this value the run required about 15 seconds
of user CPU time on a VAX 750. Larger values are more appropriate
to reduce anomalies from timer quantization etc.
====================================================================
Dhrystone Benchmark, Version 2.1 (Language: C)
Program compiled without 'register' attribute
Please give the number of runs through the benchmark: 10000
Execution starts, 10000 runs through Dhrystone
Execution ends
Final values of the variables used in the benchmark:
Int_Glob: 5
should be: 5
Bool_Glob: 1
should be: 1
Ch_1_Glob: A
should be: A
Ch_2_Glob: B
should be: B
Arr_1_Glob[8]: 7
should be: 7
Arr_2_Glob[8][7]: 10010
should be: Number_Of_Runs + 10
Ptr_Glob->
Ptr_Comp: 24576
should be: (implementation-dependent)
Discr: 0
should be: 0
Enum_Comp: 2
should be: 2
Int_Comp: 17
should be: 17
Str_Comp: DHRYSTONE PROGRAM, SOME STRING
should be: DHRYSTONE PROGRAM, SOME STRING
Next_Ptr_Glob->
Ptr_Comp: 24576
should be: (implementation-dependent), same as above
Discr: 0
should be: 0
Enum_Comp: 1
should be: 1
Int_Comp: 18
should be: 18
Str_Comp: DHRYSTONE PROGRAM, SOME STRING
should be: DHRYSTONE PROGRAM, SOME STRING
Int_1_Loc: 5
should be: 5
Int_2_Loc: 13
should be: 13
Int_3_Loc: 7
should be: 7
Enum_Loc: 1
should be: 1
Str_1_Loc: DHRYSTONE PROGRAM, 1'ST STRING
should be: DHRYSTONE PROGRAM, 1'ST STRING
Str_2_Loc: DHRYSTONE PROGRAM, 2'ND STRING
should be: DHRYSTONE PROGRAM, 2'ND STRING
Microseconds for one run through Dhrystone: 1468.3
Dhrystones per Second: 681.0
=====================================================================
Thos Sumner Internet: thos@cca.ucsf.edu
(The I.G.) UUCP: ...ucbvax!ucsfcgl!cca.ucsf!thos
BITNET: thos@ucsfcca
U.S. Mail: Thos Sumner, Computer Center, Rm U-76, UCSF
San Francisco, CA 94143-0704 USA
I hear nothing in life is certain but death and taxes -- and they're
working on death.
#include <disclaimer.std>ast@cs.vu.nl (Andy Tanenbaum) (10/07/89)
In article <2472@ucsfcca.ucsf.edu> root@cca.ucsf.edu (Systems Staff) writes: > >Since the output of Dhrystone 2.1 is considerably different from the >old version, here is a sample run. Thanks for posting it. I tried it and it seemed to work on the Sun at least. I'll try MINIX later. However, I consider it extremely poor human engineering to print out a ton of lines that are the same (pairwise), apparently with the idea that the user is to compare them. Why can't the computer do that? I think the interface of the first dhrystone version that simply printed the answer is much nicer. Any objections if I delete all the garbage in the MINIX version? Andy Tanenbaum (ast@cs.vu.nl)
rwa@cs.AthabascaU.CA (Ross Alexander) (10/09/89)
ast@cs.vu.nl (Andy Tanenbaum) writes: [...] >>Since the output of Dhrystone 2.1 is considerably different from the >>old version, here is a sample run. >I tried it and it seemed to work on the Sun at least. I'll try MINIX >later. [...] >I think the interface of the first dhrystone version that simply printed >the answer is much nicer. Any objections if I delete all the garbage in >the MINIX version? Well, at least do exception checking (I know, that's obvious, but worth mentioning not for your edification but others'). But I agree most of the stuff coming out of Dhry 2.1 is noise. The number, however, is quite a bit better as a test of compiler+hardware performance. You need a fairly clever optimizer to defeat some of the deliberate obstructionism of the code ;-). Ross ps, and on a _completely_ different subject: The fs switch is a fine idea but not for supporting lazy 1.x --> 2.x minix conversions. This weekend I and 2 other staff converted a 1,300 MByte Vax from Ultrix 1.2 to 2.3, in the process changing the partitions around and entirely rebuilding all the filesystems. The I/O time was as nothing compared to the thinking time required. And this was using dinky little 2400 foot 6250 bpi tapes - we needed a dozen plus some for scratch. I have limited sympathy for the "it'll take too much effort to dump/restore" crowd. r
root@cca.ucsf.edu (Systems Staff) (10/10/89)
In article <3593@ast.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes: > > However, I consider it extremely poor human engineering to print out > a ton of lines that are the same (pairwise), apparently with the > idea that the user is to compare them. Why can't the computer do that? > > I think the interface of the first dhrystone version that simply printed > the answer is much nicer. Any objections if I delete all the garbage in > the MINIX version? > Under no circumstances make such deletions! This code is needed to make sure that compilers don't perform sleight-of- hand and make a lot of the computation vanish. They consider anything that's computed but not used as irrelevant and subject to deletion. It was the spread of such compilers that made release 1 Dhrystone obsolete. Printing the results makes sure that everything is being left in the computation. If you don't want to see it all after the first run, you can pipe the output through "tail" and just get the part you want. The idiot compiler writers who think they have license to second guess the program author ought to be disbarred but instead they get promoted because their product generates nice benchmark results. There was at least one commercial compiler which was reputed to have had special code to detect the release 1 Dhrystone and give, uh -- shall we say extraordinary, results. Don't ask. Thos Sumner Internet: thos@cca.ucsf.edu (The I.G.) UUCP: ...ucbvax!ucsfcgl!cca.ucsf!thos BITNET: thos@ucsfcca U.S. Mail: Thos Sumner, Computer Center, Rm U-76, UCSF San Francisco, CA 94143-0704 USA I hear nothing in life is certain but death and taxes -- and they're working on death. #include <disclaimer.std>
mboen@nixpbe.UUCP (Martin Boening) (10/10/89)
As far as running this on MINIX is concerned, there may be some problems. At
least I encountered them on MINIX/ST. Namely, floating point artihmetic is
used in the computation of the dhrystones, which is not available under the
distributed ACK Version. You may have more luck using th fp library posted
some time ago, since you're running MINIX/PC. For MINIX/ST, the best bet would
probably be using Gnu CC.
When I replaced fp by integer arithmetic, I got some 570 Dhrystones out of
an ACK compiled version of 2.1 Dhrystone on a Mega ST 2, running the standard
V1.1 MINIX-ST. This varied very little.
As to the human interface: I think dhrystone doesn't have one. I would call
it debugging output,because if the strings etc. don't match, the results
of the run are probably worthless.
Just my opinions, of course.
Martin
--
Email: in the USA -> ...!uunet!philabs!linus!nixbur!mboening.pad
outside USA -> {...!mcvax}!unido!nixpbe!mboening.pad
Paper Mail: Martin Boening, Nixdorf Computer AG, DS-CC22,
Pontanusstr. 55, 4790 Paderborn, W.-Germanynfs@notecnirp.Princeton.EDU (Norbert Schlenker) (10/10/89)
In article <2482@ucsfcca.ucsf.edu> root@cca.ucsf.edu (Systems Staff) writes: >In article <3593@ast.cs.vu.nl>, ast@cs.vu.nl (Andy Tanenbaum) writes: >> ... >> I think the interface of the first dhrystone version that simply printed >> the answer is much nicer. Any objections if I delete all the garbage in >> the MINIX version? > >Under no circumstances make such deletions! > >This code is needed to make sure that compilers don't perform sleight-of- >hand and make a lot of the computation vanish. They consider anything >that's computed but not used as irrelevant and subject to deletion. > ... > Thos Sumner Internet: thos@cca.ucsf.edu Before this goes any further, I'd like to point out that a lot of Minix users use the ACK compilers. The changes from Dhrystone 1.1 to 2.1 were made solely to defeat optimizations by clever compilers, a category into which the ACK compilers do not fall. The difference on my machine between the two versions is minor, since ACK is not good at detecting or removing dead code. Those who run gcc on ST's might see a difference. I actually prefer 1.1, since it doesn't produce 50 lines of output, it runs for more than 32767 iterations, and it DOESN'T USE FLOATING POINT to calculate its results. Norbert i n e w s f o d d e r ACK
mwe@majestix.ida.liu.se (Mikael Wedlin) (10/13/89)
In article <2482@ucsfcca.ucsf.edu> root@cca.ucsf.edu (Systems Staff) writes: >> >> However, I consider it extremely poor human engineering to print out >> a ton of lines that are the same (pairwise), apparently with the >> idea that the user is to compare them. Why can't the computer do that? >> > >Under no circumstances make such deletions! > How about 'noice = fopen("/dev/null", "w");' ? /Mikael
root@cca.ucsf.edu (Systems Staff) (10/14/89)
In article <1377@majestix.ida.liu.se>, mwe@majestix.ida.liu.se (Mikael Wedlin) writes: > In article <2482@ucsfcca.ucsf.edu> root@cca.ucsf.edu (Systems Staff) writes: > >> > >> However, I consider it extremely poor human engineering to print out > >> a ton of lines that are the same (pairwise), apparently with the > >> idea that the user is to compare them. Why can't the computer do that? For the computer to do that would require writing the data produced to a file then processing the file to determine its correctness. Remember compiler analysis of the program must not be able to decide that any of its timed computations are redundant. Now we would have portability problems (Dhrystone is not just for Unix systems) so there would be twiddling to define the file to be used etc. Then we would have to read the file back in to check it (complicating the program and raising I/O compatibility issues). It wouldn't avoid these problems to create a separate program to do the checking and we can't depend on the presence of such utilities as "diff" which is absent from many systems. > >Under no circumstances make such deletions! > > > How about 'noice = fopen("/dev/null", "w");' ? > /Mikael A change that keeps it neat is to change the printf('s that produce the desired results to fprintf(stderr,'s then you can redirect stdout to /dev/null (on systems that support this) _after_you_have_verified_ the_test_output_. Doing it this way rather than the other way around is again for portability to shells that don't allow independent redirection of stderr. And, of course, you can just follow my previous suggestion and select the output with tail, e.g. echo 10000 | dry2 | tail -3 without changing the program at all. The obvious one line script echo $1 | dry2 | tail -3 makes it straightforward to use. But you must still check the verification output the first time after recompiling. The other problem is that Dhrystone 2.1 uses floating point to compute its results. I think this should be changed and am pursuing the point. Thos Sumner Internet: thos@cca.ucsf.edu (The I.G.) UUCP: ...ucbvax!ucsfcgl!cca.ucsf!thos BITNET: thos@ucsfcca U.S. Mail: Thos Sumner, Computer Center, Rm U-76, UCSF San Francisco, CA 94143-0704 USA I hear nothing in life is certain but death and taxes -- and they're working on death. #include <disclaimer.std>