Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!im4u!ut-sally!ico!rcd From: rcd@ico.UUCP Newsgroups: comp.arch,comp.sys.misc Subject: Re: 01/31/87 Dhrystone Results and Source Message-ID: <589@ico.UUCP> Date: Sat, 14-Feb-87 03:11:11 EST Article-I.D.: ico.589 Posted: Sat Feb 14 03:11:11 1987 Date-Received: Sun, 15-Feb-87 00:11:29 EST References: <2348@homxb.UUCP> <15203@onfcanim.UUCP> <293@ames.UUCP> <319@ames.UUCP> Lines: 51 Keywords: Benchmark, C, performance measurement Xref: utgpu comp.arch:338 comp.sys.misc:358 (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 optimizing compiler cannot elide 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 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 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.