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: mike%bambi@MOUTON.ARPA Newsgroups: mod.computers.apollo Subject: Apollo vs. Sun: A short comparison Message-ID: <8512071818.AA18181@mouton.ARPA> Date: Sat, 7-Dec-85 13:18:17 EST Article-I.D.: mouton.8512071818.AA18181 Posted: Sat Dec 7 13:18:17 1985 Date-Received: Sun, 8-Dec-85 03:35:25 EST Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 190 Approved: apollo@yale-comix.arpa 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. :-)