Path: utzoo!attcan!uunet!husc6!mailrus!ames!ncar!ico!rcd
From: rcd@ico.ISC.COM (Dick Dunn)
Newsgroups: comp.arch
Subject: Re: Dhrystone compilation times
Summary: I/O system mostly irrelevant  (CPU times!)
Message-ID: <5566@ico.ISC.COM>
Date: 31 May 88 19:06:21 GMT
References: <5213@ico.ISC.COM> <507@pcrat.UUCP>
Organization: Interactive Systems Corp, Boulder, CO
Lines: 29

In regard to Dhrystone times, I said:
> >It would be interesting if people made notes of compilation times.  I'm not
> >suggesting adding this as some "formal measure" because I don't think it's
> >a particularly accurate measure.  However,...

...to which Rick Richardson replied:
> This has been suggested before.  In order for those results to have any
> meaning,  the disk system (bus, controllers, drives) would have to be
> indicated in the results...
> ...E.G. we have
> 8 drives, 4 controllers, and 2 busses; the drives spin at 3600, have
> 8 heads apiece, 36 sectors/track, 15 msec track-track seek time...

My original article suggested looking at CPU times to re-make the programs.
In particular, I said that I had measured, on UNIX systems, the *user CPU*
time.  I see no reason to think that the I/O subsystem characteristics
should have any more than a minor effect on this measure--which is why I
suggested it!

For a uniprocessor system--or, for that matter, with a single-thread
compiler--the compilation time puts a lower bound on the real time to
compile.  That is, I/O latency can make the real time for compilation
longer than the CPU time but not shorter.

Moreover, in the cases of the bad compilers I found, the total CPU time
(user+sys) was more than 95% of the total elapsed time.
-- 
Dick Dunn      UUCP: {ncar,cbosgd,nbires}!ico!rcd       (303)449-2870
   ...If you get confused just listen to the music play...