Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!ucbvax!apollo
From: JW-Peterson@UTAH-20.ARPA (John W Peterson)
Newsgroups: mod.computers.apollo
Subject: Re: Apollo vs. Sun:  A short comparison
Message-ID: <12165332067.7.JW-PETERSON@UTAH-20.ARPA>
Date: Sat, 7-Dec-85 20:24:55 EST
Article-I.D.: UTAH-20.12165332067.7.JW-PETERSON
Posted: Sat Dec  7 20:24:55 1985
Date-Received: Sun, 8-Dec-85 03:42:09 EST
References: <8512071818.AA18181@mouton.ARPA>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 61
Approved: apollo@yale-comix.arpa

In general, Mr. Caplinger's review is a fair evaluation from the point
of view of the hard-core Unix user.   However (since it's clear which
side of the fence I'm on), there are a few things in Mr. Caplinger's
review I feel need further comment.  I've been using Aegis since SR2 
(and Unix since V6...)

> Because the C compiler is a native Apollo compiler and not the Portable C
> compiler, there are subtle C language incompatibilities....
My response to the difference in compilers is "viva la difference!".  I
have frequently moved C programs from our vaxen to the Apollos just to find
out what the vax PCC meant when it said "syntax error".  I've ported around
30K lines of C to the Apollo, and have found few problems with the C
compiler.  Most of the problems I did find were related to sloppy code.

> To make a sweeping comparison, the Apollo (with a 68010) is slower than the
> equivalent Sun...
Let's compare Apples and Apples.  Using 10 transister SPICE benchmark, we
found a DN320 (with FPA) was 1.8 times -faster- than a Sun with SKY board.

> In addition, an Apollo with 3 meg, diskless, "feels" slower than a diskless
> Sun....[this is because of] the (presumably) extra overhead of running
> Domain/IX programs as opposed to native Aegis commands.
You guessed it right.  Compare the /com/sh (which is designed to take 
advantage of the shared virtual libraries) to the /bin/csh (which isn't)

$ ld -a /com/sh /bin/csh

sys   type       blocks	  current   
type  uid	   used   length    attr  rights   name

file  obj             1      594    P     pgndwrx  /com/sh
file  obj           247   251018    P     pgndwrx  /bin/csh

As you can see from the numbers above, there's a very large overhead for 
running csh on the Apollo.  Also, because fork() is relativly expensive on 
the apollo, this can cause the csh to feel slow (do you run with "inprocess"
set?).  Quite frankly, time spent learning /com/sh commands could be
easily paid back in terms of a workstation with nice snappy performance.

> The standard Unix debuggers (adb, dbx) are not supported on the Apollo.
WHO WANTS THEM???  Apollo supports a fantastic window/source debugger for use
with their high level languages.  This is far better than dbx.

> I like the Sun ... optical mouse much better than the Apollo mechanical 
> ball mouse...
SummaMouse optical mice work on the Apollo's, if you have a serial port
to spare (they're also $100 cheaper than Apollo's mice...)

> In general we're happy, but we're also
> scared that the CS research community is moving to Suns exclusively.  
I disagree with this.  Utah has a large number of Apollos (33 + more on order)
Some universities (e.g. Yale, Michigan, Brown) have made huge (> 100 node)
investments in them.

> It seems clear that Sun's commitment to full native Unix is stronger than
> Apollo's.
I disagree with this also.  Witness that unlike Sun, Apollo supports -both-
System V and 4.2 BSD.  They have made a very strong commitment to
improving Domain/IX.  Witness the changes at SR9.

-------