🚀 go-pugleaf

(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.