Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!ames!lll-tis!ptsfa!hoptoad!academ!uhnix1!nuchat!steve From: steve@nuchat.UUCP (Steve Nuchia) Newsgroups: comp.arch Subject: Re: Fastest Kernel Make Message-ID: <307@nuchat.UUCP> Date: Fri, 4-Sep-87 10:12:13 EDT Article-I.D.: nuchat.307 Posted: Fri Sep 4 10:12:13 1987 Date-Received: Sun, 6-Sep-87 01:52:57 EDT References: <26853@sun.uucp> <8526@utzoo.UUCP> Organization: Public Access - Houston, Tx Lines: 72 Keywords: Making kernel = (or) != speed of machine Summary: why make is my favorite benchmark In article <8526@utzoo.UUCP>, henry@utzoo.UUCP (Henry Spencer) writes: [things kernel make times depend on...] > It also depends on the flavor of kernel. A V6 kernel compiled on, say, > a Sun 4 (assuming you could get the V6 kernel past a modern C compiler!) > would probably beat the Amdahl record, simply because the V6 kernel wasn't > very big. Being a software developer, the one benchmark that I pay a lot of attention to is the compiler. I once had the immence pleasure of developing serious code on a sun, and made extensive use of the graphical system performance monitoring facilities in support of that project. It is instructive to observe how very little of the elapsed time of a compile is spent at 100% cpu utilization and how much at maximum I/O bandwidth. The "make " benchmark will usually tell you more about the I/O performance of the machine than it does about the processor. That is a good thing, since I/O performance (including system call overhead, of course) is a pretty important system parameter. Using make as a benchmark we were able to quantify the braindamage of quite a few machines, some of which made claims of being high-performance. The specific benchmark we used at my former employer was to compile the product, which weighed in at about 30,000 lines of C and made four or five large programs and a couple of dozen smaller ones. We then ran a comprehensive set of automated tests on the resulting product. The whole job took 8 - 12 hours on the typical "super-micro" of 2 - 3 years ago. Interresting thing about it, as with most benchmarks, are the standout exceptions. We thought the pyramid was fast when it turned in a time of around three hours. Then we did an Amdahl, and the whole thing, including reading and writing the tapes, took 45 minutes on a heavily loaded system. The testing part would normally display the faked user interactions as it went along, so serial I/O was included in the timing. For most machines this didn't make much difference; they couldn't work fast enough to saturate a 9600 baud line. Then we got our first 68020 box, the convergent mightyframe (this was well over a year ago). It was so fast it could run the testing on two 9600 baud terminals in the same elapsed time as one. It was spending less than half the cpu and I/O keeping each 9600 baud line saturated. Then there were the losers. The old Radio Shack 16b's had a z80 handling all the I/O, including the hard disk. That thing took over 24 hours to run the whole cycle. And the Arete' box, which is supposed to have a lot of I/O power, failed. The master processor couldn't handle the system call overhead to keep the slave working. The box we looked at had 2 68010s, and they claim the '020s work better, but we didn't buy the box. The plexus uniprocessor machine with its intelligent I/O subsystems outperformed it on the software developer's benchmark. That evaluation cemented my conviction that multiprocessor architectures should avoid distinguishing among the processors. Now I want a sequent. I should point out that the compiler/linker system provided with most unix boxes is not well balanced in its resourse usage. If you look at what it's doing, it spends a lot of time in a large make (say, 2.11 news) forking and execing the myriad phases of the compiler, which then must read the data that the old phase just wrote. Engineering improvements in the compiler software could eliminate its sensitivity to I/O bandwidth. The benchmark is very sensitive to things like setting the sticky bit on the compiler phases, too. -- Steve Nuchia Of course I'm respectable! I'm old! {soma,academ}!uhnix1 Politicians, ugly buildings, and whores !nuchat!steve all get respectable if they last long enough. (713) 334 6720 - John Huston, Chinatown