mike%bambi@MOUTON.ARPA (12/07/85)
I recently posted this message to Sun-Spots (the Sun mailing list), and I thought people on this list might be interested. Note that it is definitely biased towards people who are deciding between Apollo and Sun as Unix-based workstations - there is almost nothing here about the merits of Aegis in its own right. Nor does this take many shots at the Sun - it's more intended for people who understand the 4.2 environment already and want to know whether to buy one or the other workstation. (Before I get flamed too badly, it has been described by one of my co-workers as "remarkably even-handed" :-) ---------- I used Suns at Rice for several years, since the original Sun-1 and Unisoft V7 Unix. (In fact, I used to moderate this list.) I've been using Apollos for about 6 months here at Bellcore. These are a few comments about the merits and problems of the Apollo relative to the Sun. (Note that my Sun experience goes up to Sun 1.3, not 2.0, and my Apollo experience goes to SR9.) First, I have to confess that even on the Apollos, we use Unix exclusively. (For those who don't know, the Apollo runs a kernel operating system called Aegis. Libraries and server processes sit on top of that kernel. The "Domain/IX" product is a Unix emulator for both 4.2 and System V, simultaneously if you like, and provides most of the Unix system utilities, libraries, and system calls.) We use Unix mostly for reasons of portability and familiarity. Regardless of the merits of the native Apollo operating system, there's no way a program written with it will run on another machine, while with Unix, there's at least a fighting chance of writing portable code. APOLLO MINUSES: Because the native operating system is not Unix, there are an entirely new set of system management problems. You have to learn a whole new set of commands, remember where different configuration files are, and so forth, to be an effective system manager. This took me about a month or so. The problem was greatly complicated because most of the Aegis commands have almost exact Unix equivalents, but the names have been changed. For example, "list directory" is "ld", not "ls". "Move file" is "mvf", not "mv". It's an annoyance. Once Domain/IX is in place, these problems almost, but not quite, go away. All of 4.2 BSD is not supported. For example, the syscall interface to the kernel is missing, as is the SIGIO signal. The 4.2 print spooler (lpr, lpd) and the Unix graph(1) command are not present. I'm sure there are other things that I haven't missed yet. I am not too familiar with System V and we aren't using it, so I don't know what's missing there. Because the C compiler is a native Apollo compiler and not the Portable C compiler, there are subtle C language incompatibilities. Also, there is no assembler in the standard distribution, the compiler produces error messages in a different format, and the code quality is different between Apollo C and PCC. (It's not clear which is better. Under SR8, Apollo C was clearly inferior to PCC, but the situation has improved under SR9.) Apollo uses a TCP/IP derived from the old BBN sys.10 process-based TCP, which means there are a different set of management commands from the ones a 4.2 user would be used to (ie, different host tables, no netstat, route, arp). Most of the same functionality is present, it's just different. (The network libraries, sockets and so forth, are identical to 4.2 BSD's.) The object and executable formats are unlike Unix's, so programs that dump memory state don't work. In addition, the symbols etext, edata, and end are not provided. To make a sweeping comparison, the Apollo (with a 68010) is slower than the equivalent Sun. Using the Dhrystone benchmark, an Apollo DN320 with an FPA comes in at 793, while a Sun 2/120 without FPA runs at between 1100 and 1200. I don't know the relative clock speeds of the two machines, or the memory wait-state situation on the Apollo, or whether the 68020 versions will be different. In addition, an Apollo with 3 meg, diskless, "feels" slower than a diskless Sun (running ND, not NFS) with 2 meg. One should take into account that this includes the (presumably) extra overhead of running Domain/IX programs as opposed to native Aegis commands, which we don't use much. Some commands, particularly those that deal with directory reading or writing (like "find") are painfully slow. The standard Unix debuggers (adb, dbx) are not supported on the Apollo. The standard editor is nicer in some ways, worse in most, to the Sun dbxtool. It's certainly different - another training problem. The Apollo's performance is not "predictable" to me. There are sometimes long pauses for no good reason. This may well be an artifact of my unfamiliarity with the internals of Aegis, and strange interactions with the Apollo virtual memory and single level store. The Apollo documentation for Domain/IX is almost a straight printout of the Berkeley VAX documentation. Usually the differences and limitations of Domain/IX are not mentioned. As documentation for someone unfamiliar with Unix, it suffers from the typical Unix problem - you have to know a lot about Unix already before the documentation makes sense. Apollo should make an effort to try to expand on the conventional documentation. They have a short guide for new users, but nothing really for systems programming. (Sun has more or less the same problem, but since they've had Unix longer, their documentation is somewhat further along. It still suffers from emphasis on novice users, though. I don't know if the 2.0 documentation is better.) I like the Sun keyboard and optical mouse much better than the Apollo keyboard and mechanical ball mouse. The Sun window interface has somewhat better mechanics; Apollo window placement, cursor treatment, and general user interface have some problems. APOLLO PLUSES: Aegis is a much "cleaner" operating system than Unix in a number of ways. For example, the single level store allows very nice shared libraries to be implemented. Rather than including the object code for all of the C library with every program, as Unix does, Aegis does dynamic binding at run time. The executables are much smaller, and the system can be changed without rebinding anything. I have executables from 4 major releases of Aegis ago that still run with no changes. One could claim that from a design standpoint, Aegis is more consistent than Unix. It has more support for record-oriented files, which might be important for some applications, like databases. (You can't use this and remain Unix-compatible). Apollo has had transparent access to files for much longer than Sun has. Therefore, the performance seems to be much better (I have only limited experience with NFS, but long waits for file opens don't occur on the Apollo.) The performance of Sun ND seems superior to Apollo's distributed access, but remember that ND didn't allow read/write file sharing among machines. In order to run a single ring of machines, much less system administration per processor is needed on the Apollos. It is almost as simple as plugging a new machine into the ring, turning it on, and using it. The Sun requires a much more complicated procedure to configure a new machine. A diskless Sun has to be administered like a separate machine, while a diskless Apollo doesn't have any separate administration problems. The Apollo user interface has some nice features that the Sun lacks, like scrollable back histories, and command resubmission and editing. There is a simple (almost too simple) pervasive editor that is always available on the Apollo to do input editing. The Sun is much more oriented towards multiple ASCII terminal windows. The Apollo graphics package is considerably easier to use than the Sun package, although of course neither is the least bit portable to other kinds of machines or each other. The Apollo error messages, both from system routines and the compilers, are much better than the standard Unix messages found on the Sun. We experienced a large number of CRT failures at Rice, and other groups at Bellcore continue to lose Sun CRTs commonly. We have never had an Apollo CRT go out on us (in two years with four to seven nodes). In general hardware reliability seems higher on the Apollo. Apollo seems to have a much higher commitment to software compatibility and support across releases and different Apollo hardware than Sun does. With Sun, we went through a large number of completely incompatible software upgrades (Unisoft to Sun 0.1 to 0.3 to 1.0 to 2.0) across which most graphics software broke completely. Apollo guarantees compatibility from release N to release N+1, and in practice, across many more release levels. The documentation for Aegis has a rich set of examples in several languages for how to use most of the system interface. As a company, Apollo has exhibited somewhat different tactics than Sun. In the early days, Sun made a lot of promises and then failed to deliver. Apollo delivered a product with full function but bad performance, then concentrated on making it fast. Now that Sun can deliver, the difference is less pronounced - but I still remember a year of not being able to do much with Suns because the graphics and network software wasn't there yet. THE BOTTOM LINE We are getting our work done with the Apollo, working around the problems caused by lack of full Unix support. In general we're happy, but we're also scared that the CS research community is moving to Suns exclusively. It seems clear that Sun's commitment to full native Unix is stronger than Apollo's. We have already had some problems porting programs from Sun or VAX to Apollo. While this can be chalked up in large part to sleazy programming practices, that doesn't make the problem any more manageable. In brief: For applications involving exclusive use of Unix, and contact with the general research community, the clear choice for now seems to be Sun. If you don't have the constraints of Unix and Unix portability, you should give Apollo a look. Mike Caplinger mike@bellcore.arpa ihnp4!bambi!mike ps. I'm still looking for the perfect workstation. It's beginning to look as though I'll have to build it. :-)
JW-Peterson@UTAH-20.ARPA (John W Peterson) (12/08/85)
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. -------
Lepreau@UTAH-20.ARPA (Jay Lepreau) (12/08/85)
This'll get as bad as 4.2 vs Sys V or equiv if this goes on much more. But a few corrections: Debuggers: Mike specifically compared the Apollo debuggers to the Suns's mulit-window dbxtool, not vanilla dbx. Have you used that much, JW? Comittment: Sun recently announced they are joining (some) forces with AT&T to achieve full Sys V compat. Also, from your own arguments about using /com/sh instead of /bin/csh it's obvious that currently Apollo's are very good native workstations and mediocre Unix ones, and will probably always be at a disadvantage running Unix as long as it's layered on Aegis. (Although their shared libs and filesys could give them a big jump if they could make fork go faster than a snail.) Why isn't the lpr stuff distributed, anyway? It doesn't do anything special, why can't it just be compiled and run? -------
JW-Peterson@UTAH-20.ARPA (John W Peterson) (12/08/85)
Word from the rumor mill is that lpr is showing up in the next release or so. They may have wanted to do some work to get it to work with prf/prsvr (this is just a guess though). -------
Giebelhaus@HI-MULTICS.ARPA (12/09/85)
I have some other problems with Mike Caplinger's comparison. I was involved in a comparison of Sun v. Apollo last spring for a research center and it was rather easy for me to see that the better machine for the job was the Apollo. Probably the most important thing to strieghten out is that the Unix on the Apollo is NOT emulated. The Unix runs next to Aegis, not on top of it. Much of it goes all the way down to the kernel level. Some of it like the files system must use the Aegis calls. The tools on the Apollo are much better (including the C compiler). The Aegis operating system is impressively clean and very modular. It is the Unix part of the operating system that gives me all the problems. Apollo cleaned it up some in porting it and it is still much too much of a hack. I am impressed with how quickly apollo was able to do the port (it speaks well of the tools on the Apollo). Apollo is working on making the Unix as perfect as possible so they are not done with it yet. If anyone would like information why we choose Apollo over Sun, I could send it to you through the e-mail.
holtz%cascade.carleton.cdn%ubc.CSNET@CSNET-RELAY.ARPA (Neal Holtz) (12/09/85)
Arguing this in this group is probably like preaching
to the converted but ... I also have some disagreements
with Mike Caplinger's comparison.
I have been looking (in a cursory fashion) at the new Sun's
(externally visible software mostly), and I must say they have
improved considerabley in the past 2 years (of course, that was
pretty easy to do as they were not much of a machine 2 years
ago). Still a ways to go in the windowing dept ...
A bit over 2 years ago we carefully evaluated 4 different workstations
(Apollo, Sun, HP-9000 and Orcatech (a local firm)). It was the easiest thing
in the world to reach a decision -- after listing our requirements in order of
priority and ranking each station within each, it was clear that the Apollos
were miles ahead (at that time). A part of that comparison (where 4 is
best, 0 is no good at all) was (in 1983):
Apollo Sun Orc HP
Virtual memory/large unsegmented address space 3 0 0 4
Constraint-free programming 4 3 0 4
Source-level program debugger 4 0 0 0
Unix-like operating system and programming environment 4 4 4 4
Functioning high-speed network -- distributed file system 4 2 2 2
Overlapping windows on high-speed bit-mapped display 4 1 0 0
Advanced user interface (process control, mice, etc.) 4 2 0 0
Advanced software development environment 4 3 2 3
Good performance in software development (compiling, etc.) 4 2 2 3
Good performance in analysis 3 2 2 4
High resolution graphics (750x1000) or higher 3 3 4 3
Note that we do not believe in depending on Unix for portability of code we
develop, but we did want the 3 or 4 good ideas of Unix -- so Unix itself is
further down the list.
Sun would now rank higher on many of those attributes, probably 1, 3, & 5.
Their windowing system is not up to scratch, and I know realize that is even
more important than we originally though -- now I would move that close to
the head of the list. And, in contrast to Mike's statement, I think the
user interface on the Apollo is *MUCH* better than the Sun:
- special keys for often used functions:
creating new processes, getting help, editing/viewing files
text editing fuctions, etc.
- the fact that the editor is ALWAYS available, no matter where
you type (though it would be nicer if it were more EMACS-like).
Obviously, our needs are not the typical Computing Science stuff -- we do
engineering, from traditional numerical simulation to applications of
techniques from AI. We have no hangup about writing code in Fortran, but
we want lots of applications programs, and most of those already
written are in Fortran.
We have ported or written close to 1,000,000 lines (yes, six zeros) of
code - 75% Fortran, 20% C, 5% Pascal. These range from traditional huge FEM
programs, to solids modellers, to advanced messaging systems, to Prolog and APL
interpreters. And we don't have many people doing it. (we also do a fair bit
of development in Lisp (PSL)).
I am convinced we could not have been nearly as productive with *any* other
machine. The compilers are good, the debugger is superb (and when you
port large Fortran programs, you spend a lot of time in the debugger), and
the standard editor is reasonable.
As far as I am concerned, there is still a large (but narrower) gap between
the machines, in Apollo's favour -- if I had to make the decision again it
would be even easier.
Mike's original comparison, looking at the narrower view of coding in C
for Unix, and nothing else, (which he essentially stated) shows the
Suns to be relatively much better. But I do not believe that holds at
all when you want general purpose machines.srt@LOCUS.UCLA.EDU (Scott Turner) (12/09/85)
Peterson@Utah has answered most of the major points mike%bambi raised about
the Apollos, but I'd like to throw in my two cents worth.
At UCLA we are running a network of 25 Apollos of various flavors, most
of which are used in the Artificial Intelligence Lab. There are also other
sizable Apollo communities out there, particularly at Utah and Yale.
One major plus Apollo has going for it is the service. We've had nothing
but excellent, prompt and exemplary service from Apollo. We seem to suffer
hardware problems in waves (fortunately of diminishing frequence and
severity) and when one occurs the Apollo service people work unstintingly
to correct matters.
At the software level, I was once confused by a fairly obscure graphics
call. I rang up Apollo in Mass and asked for a graphics expert. He called
me back in about 10 minutes. I outlined my problem, he got off the phone,
WROTE TEST CODE RIGHT THEN and called me back shortly with a solution. I
couldn't have asked for more, and this seems to be the attitude throughout
the company, and to me and anyone else who's tried to do real work on a net
of 25 workstations, that's worth a lot.
I've also become very enamored of the Apollo's user interface. I've
recently had a chance to interact with a MacIntosh, Xerox Dandetiger and
a Symbolics LM-2. There seems to be a prevalent attitude that ``Menus are
Good''. Not so for the experienced user. Nothing is more annoying than
to have to constantly leave the keyboard to perform editing functions. The
Apollo interface is designed with this in mind. The interface is a set of
Display Manager commands that can be bound in any way (including sequences)
to any key (including the six mouse keys). And while the DM commands aren't
as versatile and complete as Emac's Mocklisp, they do provide a very
powerful interface. (There is not, however, any way to define new functions
except as sequences of old functions.)
So while the Apollos do have problems (the second citizen status of Unix
being the most annoying) I find them very usable.
-- Scott Turnerapollo@ucbvax.UUCP (12/14/85)
I would very much like to hear why you chose apollo over sun. I am involved in a work-station evaluation project, and apollo and sun are the leading candidates. Any information you can supply would be extremely helpful. Thanks, Andrew J. Cohen Fermi National Accelerator Laboratory Computing Department ...!ihnp4!psuvax1!COHEN@FNALBSN.BITNET
apollo@ucbvax.UUCP (12/16/85)
I would like a copy of your comparison of Apollo and Sun computers. Thank you for the offer. Peter Berke