Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site hcrvax.UUCP Path: utzoo!hcrvax!mike From: mike@hcrvax.UUCP (Mike Tilson) Newsgroups: net.micro.16k Subject: Re: 16k benchmarks ? - (nf) Message-ID: <908@hcrvax.UUCP> Date: Wed, 1-Aug-84 21:06:27 EDT Article-I.D.: hcrvax.908 Posted: Wed Aug 1 21:06:27 1984 Date-Received: Thu, 2-Aug-84 00:25:53 EDT References: <271@rna.UUCP> <25800010@uiucuxc.UUCP> Organization: Human Computing Resources, Toronto Lines: 81 Some recent articles have benchmarked the UNITY system on the LMC hardware. In the light of those benchmarks, I thought that readers of this newsgroup would be interested in knowing what work will be completed on UNITY in the near future. (One should also keep in mind that LMC will be making hardware upgrades in the near future, for example the upgrading of the clock rate on the processor card.) The current UNITY system works well on the National 32000 series hardware, and it has been adapted to quite a number of boxes (over a dozen of them). Our focus to date has been to make the system reliable and configurable to a wide variety of hardware. We now plan certain performance improvements by Q4 of this year, if not earlier. The improvements are running internally. The current release of UNITY on the 32000 is based upon Berkeley 4.1BSD. This was chosen because at the time we did not want to reinvent a paging algorithm. As most readers know, National will be supplying UNIX System V to AT&T. In turn, HCR has been contracted by National Semiconductor to perform the conversion of UNIX System V to allow it to run on the NSC Sys 16 System (which is based on the NS32000 microprocessor family). We will be using our System V Rel. 2 implementation to immediately provide the initial basis of the next version of UNITY. (This will occur even before an official AT&T release of 32000 System V.) From a feature point of view, this release will provide the functionality now enjoyed by the 4.1BSD based version, as we have already ported most of the UCB utilities to System V. (You'll have to use shell layers rather than job control...) From a peformance point of view, there will be a number of good results: 1. A new implementation of C and Fortran 77. Better code is generated, and a number of Fortran problems will be resolved. In particular, the "module" linking used in the current version of UNITY will be changed to a more Vax-like convention. This will speed up execution, but it will also significantly improve the performance of the compilation process. The current linkage editor is slower than it needs to be, mostly due to module table processing. This is what accounts for an unexpectedly slow showing on "compile" benchmarks. When compiling `printf("hello world\n")', the compile-assemble-ld process is around a factor of 2.5 better with the new compiler/assembler/loader. 2. The System V Rel 2 implementation is generally faster. All of the steps taken on the Vax (e.g. implementation of critical library routines in assembly language, command hashing in /bin/sh, etc.) are used on the 32000. 3. The overhead of interrupt processing will be significantly reduced. 4. Virtual memory will be implemented by our own proprietary paging algorithm. This algorithm is designed to approximate swapping performance when running small jobs, and yet provide good performance on large jobs. It is the only UNIX paging algorithm that we know of that uses a working set algorithm. Prior to any significant performance tuning, it already benchmarks better than any algorithm now available on the 32000 hardware. (Note: if and when AT&T releases its own algorithm to the "public", we will evaluate its performance and use whatever is best. Both the AT&T and HCR algorithms are transparent to user code, so a change should be possible without modification of any user programs.) In summary, the current UNITY 32000 release has performance which is comparable to other systems. However, on compile-bound benchmarks, particularly benchmarks which emphasize small programs, the linkage editing time predominates. Our main development thrust has been to ensure the completeness and configurability of the system, so extensive performance tuning has in the past not been emphasized. The next major release will incorporate above performance and functionality improvements. Final note: It has been said before, but one must use great caution when attempting to draw general conclusions from benchmarks on specific hardware. If attempting to benchmark only the software, one must take into account variations in memory speed, processor clock rate, disk speed, etc. Also, it is very important to benchmark at more than one point. For example, the current release of GENIX outperforms the current release of UNITY when compiling a single small program; UNITY far outperforms GENIX when heavy memory demands cause paging activity to occur. I can flat out state that, comparing current version to current version, a switch to GENIX will *not* double performance, and in some cases could degrade performance. / Michael Tilson Human Computing Resources Corp., 10 St Mary Street, Toronto, Canada (416) 922-1937 {decvax,utzoo,utcsrgv}!hcr!hcrvax!mike