Path: utzoo!attcan!uunet!pcrat!rick From: rick@pcrat.UUCP (Rick Richardson) Newsgroups: comp.arch Subject: Re: Dhrystone compilation times Message-ID: <507@pcrat.UUCP> Date: 29 May 88 13:58:19 GMT References: <5213@ico.ISC.COM> Reply-To: rick@pcrat.UUCP (Rick Richardson) Organization: PC Research, Inc., Tinton Falls, NJ Lines: 43 In article <5213@ico.ISC.COM> rcd@ico.ISC.COM (Dick Dunn) writes: > >I decided to run the Dhrystone 2 benchmark on some machines we have around > >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, it probably adds $.02 worth of >additional information. 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. That can of worms has too many sources of errors, so it is left an exercise for "the reader". 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. The controllers can overlap seek on two drives simultaneously. The controllers buffer an entire track. The busses can move 10 MB/sec. /tmp is mounted on its own filesystem. The compiler is on /, also its own filesystem, and the source/object went to a third filesystem. The three filesystems were on three different disks, but only two different controllers. UNIX was in single user mode, but with all necessary filesystems mounted. The model numbers of all the above were XXXX,YYYY,ZZZZ. UNIX had 2000 buffers for the disk cache. The filesystems hadn't been repacked for optimal ordering in 3 months; in the meantime, we'd been creating lots of little files and then deleting them in a completely random way. There's a large area of bad blocks right in the middle of /tmp, and it is quite likely the compiler temporaries were getting remapped to the spare blocks. The list goes on ... Gak! Half the time, the HZ parameter was incorrectly determined. And that's just (more or less) one independant variable. With the disk system involved there are maybe two dozen more independant variables! I suggest that these types of comparisons be made by the purchaser, on systems configured nearly identical to those being contemplated for purchase. Vendor balks? Take a walk. -- Rick Richardson, President, PC Research, Inc. (201) 542-3734 (voice, nights) OR (201) 834-1378 (voice, days) uunet!pcrat!rick (UUCP) rick%pcrat.uucp@uunet.uu.net (INTERNET)