Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!pasteur!ames!xanth!nic.MR.NET!hal!ncoast!allbery From: allbery@ncoast.ORG (Brandon S. Allbery) Newsgroups: comp.sys.ibm.pc Subject: Re: Why unix doesn't catch on Message-ID: <13595@ncoast.ORG> Date: 22 Apr 89 00:56:40 GMT References: <7632@phoenix.Princeton.EDU> <256@jwt.UUCP> <7697@phoenix.Princeton.EDU> <268@tree.UUCP> Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery) Followup-To: comp.sys.ibm.pc Organization: Cleveland Public Access UN*X, Cleveland, Oh Lines: 54 As quoted from <268@tree.UUCP> by stever@tree.UUCP (Steve Rudek): +--------------- | I would LIKE for UNIX to win out against OS/2. I feel that UNIX is at a | tremendous disadvantage, though, for a reason that I've never seen | discussed: UNIX programmers and companies which are selling to the UNIX | marketplace are so caught up in keeping their products easily portable between | different UNIX machines that they generally make little or no effort to | optimize their code via assembly. They write everything in C and a well | written 100% C program generally can't hold a candle to a well written | assembly program--the compilers just aren't that good and they never will | get that good since the UNIX compilers themselves are caught up in the | portability trap. +--------------- Portability doesn't necessarily preclude speed. Look up the Free Software Foundation's "gcc" compiler -- it does a *lot* of optimization, and is written in (nominally) portable C code. On the other hand, the portable applications can be moved from DOS to OS/2 just as easily as from UNIX-386 to UNIX-68K. Blinding speed is great, but if it doesn't run under your OS (or does so only in a limited way, as with OS/2 (i.e. it singletasks, when OS/2 is multitasking) it doesn't benefit you anywhere near as much as a slower one that *does* work in your environment. Compilers in portability traps: Granted that AT&T's Portable C Compiler is the most common C compiler under Unix -- because it either comes with Unix or is an easily available accessory -- it's not the only one. People who want to pay for it can get the Green Hills compiler for the 68K. People who are willing to do the work to maintain it can get GCC, mentioned above. Other GOOD optimizing compilers exist, and programs compiled with them run rings around programs compiled with pcc. (I recall when a 68020 System V system I used to use got an OS upgrade which included the OS and utilities being recompiled with the Green Hills compiler instead of pcc. It was DEFINITELY noticeable.) I'll also mention that MSC and Turbo C aren't optimizing compilers to the same degree as are available for Unix; optimization beyond "peephole" pcc-style optimization and some relatively simple cases is decidedly non-trivial. And you pay through the nose for it, in one way or another. Another point -- optimization technology took a big leap forward when RISC processors became popular. It *had* to. I'm not sure how much of that has leaked back into the world of CISC compilers, but when it does compilers will get even better. Let's not bring in specious arguments. The tools exist to make C very nearly as fast as assembler, if developers are willing to put some of their profits into their compilers. ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@ NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser