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