Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!rutgers!cmcl2!rna!kc From: kc@rna.UUCP (Kaare Christian) Newsgroups: comp.sys.ibm.pc Subject: Re: Why unix doesn't catch on Summary: Non-portable?? But at what cost? Message-ID: <552@rna.UUCP> Date: 1 May 89 14:33:41 GMT References: <7632@phoenix.Princeton.EDU> <256@jwt.UUCP> <2496@bucsb.UUCP> <274@tree.UUCP> Organization: Rockefeller University - Neurobiology Lines: 105 In article <274@tree.UUCP>, stever@tree.UUCP (Steve Rudek) writes: > > I read just the other day in _Computer_Systems_News_ that Microsoft's OS/2 > for the 386 is being delayed because of the difficulty of converting > 100,000+ lines of 286 assembly to 386 assembly. This is *Microsoft*, > people: You know--the company which markets perhaps the best optimized > C compiler in the world. And they aren't writing OS/2 in C; or even following > the UNIX lead and doing it 95% in C with bottlenecks in assembly. You > suppose they're just stupid? It's pretty common knowledge that OS/2 *IS* being rewritten in C. Microsoft doesn't want to miss out on RISC developments, etc. Their goal is ubiquity; portablity combined with excellence are required to attain that goal. > I understand that VMS (the preeminent OS for the Digital VAX minicomputer > line) is primarily or entirely in assembly as well. I guess they missed the > boat? > > No. The fact is that UNIX on a VAX doesn't even compare, from a pure > performance standpoint, with VMS. And the efficiency of UNIX on the 386 is > almost certainly going to look rather sickly when compared to a mature > version of 386 OS/2. The VMS vs. UNIX performance wars have raged over the years, and they don't need to be reignited by someone who, apparently, is not very familiar (note the word "understand" above) with VMS. In summary, VMS is better at some things, Unix better at others. VMS has some deep hooks for database and transaction sorts of things, and it has some apps that do those sorts of things quite well. Unix is far more flexible, is better at supporting a heterogenous workgroup, and it can task switch much faster. BTW, there is no such thing as "pure performance" -- its always "performance of chore X." BTW2, a mature 386 OS/2 may have higher performance than Unix, but the difference will probably be due to what features are in "mature 386 OS/2", and how they are implemented. Lightweight processes (threads) can be a win, because you can avoid time consuming context switches. (But apps that rely on threads will be very non-portable). Single user operation can also be an efficiency win. (But it has obvious drawbacks and limitations.) And a lack of security high and low can also be an efficiency win. (But again, the drawbacks are obvious.) If "mature 386 OS/2" is equal or better (to Unix) in functionality *and* performance, then few will use Unix. Even Microsoft doesn't make this claim, they simply think OS/2 is better suited for business users. > Sure, > better coding and algorithms may give a C program a temporary lead. But > no matter what can be done in C it can be done BETTER in assembly. It > sorrows me that there is this tradeoff. But I'll repeat: Portability IS the > enemy of excellence. > ---------- > Steve Rudek ucbvax!ucdavis!csusac!tree!stever ames!pacbell!sactoh0!tree!stever It's certainly possible to rewrite most C programs in assembler and make them run faster, but the improvement is usually modest. On a few special things, the improvement may be significant. But more often, its better algorithms (i.e. using a better search or sort) or different algorithms (writing directly to the screen buffer, instead of using bios calls) that make real differences. Experience has shown that you can usually increase a program's performance by rewriting it. Many assembly programs have had their performance significantly boosted by rewritting them in C, because it becomes much easier to use more sophisticated methods. Similarly, C programs can be rewritten in C or assembly to be more efficient. As has been shown many times, programmer productivity is fairly constant across languages, measured in lines of debugged code per day. (There is a huge individual variation, some people are better than others, but most people will write N lines a day, be they lines of assembly, C, Lisp, or 4GL database.) The higher level languages get you more functionality (and usually more portablity) per line, at lower execution efficiency. Just where you make your tradeoff depends on your market, the skills of your programmers, etc. Excellent programs can be written in 4GL or in assembly. A given program can be written faster and more reliably in C (than in assembly), but if you are planning to sell several hundred thousand copies, and you are betting the company, then you will want to put a great deal of effort into micro efficiency, which is where assembly language excells. A related note: Microsoft and many other PC software companies are finding it increasingly important to make their apps available on a variety of platforms: DOS, OS/2, Windows, Unix, the Mac, etc. The emerging approch is to write a portable core "engine" (usually in C) plus glue and user interface routines for each supported system. Thus 80% of the app is "portable", the other 20% is not portable. Most of these companies are planning to write "excellent" software. It's a no-brainer to decide on C (because it is relatively portable) for the core engine. Portability isn't an absolute. Few (if any) major apps are 100% portable. But something that is 80 or 90% portable is far better than something in assembly that is 0% portable, unless you have unlimited budget and time for development. Portability isn't the enemy of excellence. Rather, the enemies are some of the following: limited programmer skills, limited vision by software designers, restricted development budgets and times, choosing the wrong tools (i.e. using C where it should be asm. or vice versa), and the constantly moving targets. More portable apps can distribute the cost of development across multiple platforms, can gain from the synergy of multiple platforms, and are the most economical (but not the only) way to build excellent software. Kaare Christian kc@rockefeller.edu