Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!crdgw1!steinmetz!davidsen
From: davidsen@steinmetz.ge.com (Wm. E. Davidsen Jr)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Why unix doesn't catch on
Message-ID: <13723@steinmetz.ge.com>
Date: 2 May 89 16:18:50 GMT
References: <7632@phoenix.Princeton.EDU> <256@jwt.UUCP> <2496@bucsb.UUCP> <274@tree.UUCP>
Reply-To: davidsen@crdos1.UUCP (bill davidsen)
Organization: General Electric CRD, Schenectady, NY
Lines: 69

In article <274@tree.UUCP> stever@tree.UUCP (Steve Rudek) writes:

| 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?

	You may understand it, but it's not true. Depending on the
version of the o/s, 40-60% of the system is written in BLISS, a VAX
speciffic high level language. I checked with our VMS guru who has
source fiche, and major chunks are in BLISS.
| 
| 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.

	Wow! The people I talked to here and elsewhere in the company
thought that the better performance of Ultrix for "general processing"
like mail, word processing, etc, was important. They don't know that
their performance isn't pure.

	Slight sarcasm aside, even the sysmgrs who hate UNIX with a
passion agree that it does better under a heavy office processing load.
Database stuffmay run a little faster since part of it is coded in the
o/s, but you pay a penalty in filesystem performance for other file
access. Also, for some time (over a year, but I don't know how much
longer) some of the magic file types couldn't be copied over DECNET.

	Having coded some fairly large (20-100k line) programs in
various languages, assembler isn't going to make a big difference in
speed or size over a reasonable C (or other) compiler. With a good
algorithm for the job you should see less than 2:1 in speed and 20% in
size (based on recoding a few critical routines).

	On the subject of doing things like direct screen writes, and
ignoring the fact that it limits you to a single tasking display, it was
neat stuff on CP/M and on a PC, but using high level languages and o/s
calls I can update the display now as fast as anyone could want. 

	Since the display hardware only updates every 35ms (or so) and
the eye won't notice anything much under 40ms, why worry about doing
something which is already close to the threshold of perceptability? If
you can't see that it's faster, why do it?

	The cost of writing anything large in assembler is so high the
vendors are moving away from it. It makes them slower to market, and
means they have to charge more. 

	When the customer could see/feel the better performance it made
sense as a sales technique. When the customer couldn't run larger code
in his limited memory it made sense. When 90% of the computer market
was one o/s (first CP/M, the PC-DOS) portability was less of an issue.
When compilers generated garbage code it made sense. Those days are
gone, and not missed by those of us who lived though them.

	Today it's much harder to justify the time to write and debug
in assembler, and that trend is getting stronger. Save assembler for
the module at the innermost loop, a few interrupt handlers, and things
like that. All of the arguments for assembler are based on conditions
which no longer exist, and you assume that the average programmer can
write assembler as well as s/he write C. Having taught both to people
who already knew one other language, it isn't so; being able to write
good code in assembler is an art, and the line between competent code
and good code will never be crossed by most people.

-- 
	bill davidsen		(wedu@crd.GE.COM)
  {uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me