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