[comp.editors] Quote from new book

mayoff@cs.utexas.edu (Robert Mayoff) (01/18/91)

Here's a bit of fuel for the emacs/vi debate.  This is a quote from a new book
I bought entitled _System_Performance_Tuning_, by Mike Loukides.  It's
a Nutshell Handbook from O'Rielly & Associates.  This is from p. 54, in
the "Some Tricks for Users" section.  The footnote is part of the
quote.


- Virtually all incardations of the popular emacs editor are real hogs:
they use a lot of memory and a lot of CPU time.  If you can convince
your users to use vi or some other editor,* you will gain a lot of
ground.  Most windowing systems, including SunOS, have some kind of
built-in editor.  These build-in editors tend to be underused; Sun's is
quite useful.  If you look through UUNET sources, you may find some
public domain versions of emacs that have been written to minimize CPU
load.  If you feel like experimenting, try one of these.
---
* One of this book's reviewers commented: "Fat chance!"  If you go this
route, you have your work cut out for you.  emacs users (including the
author) are a loyal bunch who would rather flame than switch.  And
emacs is an incredibly versatile editor.  But the rewards for getting
users to change are significant.


I showed this to an emacs devotee where I work.  His comment: "That's
one book I'll never read!"
-- 
/_  rob		<mayoff@cs.utexas.edu>
 /_ Fun things to do with UNIX (#2 in a series):
  / echo "rsh `hostname` -n source eat.cpu &" > eat.cpu; source eat.cpu

raoul@eplunix.UUCP (Nico Garcia) (01/19/91)

In article <1046@grit.cs.utexas.edu>, mayoff@cs.utexas.edu (Robert Mayoff) writes:
> quite useful.  If you look through UUNET sources, you may find some
> public domain versions of emacs that have been written to minimize CPU
> load.  If you feel like experimenting, try one of these.

We've had very good luck here with various versions of JOVE, Jonathan's Own
Version of Emacs. I went from using honest to gods full-blown GNU-EMACS
to using JOVE in 10 minutes, and was pleased by the better speed and 
*lack* of oddball features. (Who needs their editor to play tower
of hanoi, for gods' sake? You'd think it was an X windows!) The 
teachjove program is also nice, and the use of Ctrl-\ rather than Ctrl-s
gives stupid modems and terminals a better fighting chance.

I believe JOVE resides at uunet.uu.net. Good stuff.
-- 
			Nico Garcia
			Designs by Geniuses for use by Idiots
			eplunix!cirl!raoul@eddie.mit.edu

staff@cadlab.sublink.ORG (Alex Martelli) (01/21/91)

jfr@locus.com (Jon Rosen) writes:
	...
:By the way, this is also why I think Plan 9, as described in several
:recent mags, is severely broken... The emphasis is on terminal servers
:for interaction with the file and CPU servers... thus, no user will
:have a true local computing capability... Why is this still being
:considered??? We can now buy Sparc chips running 15Mips at a cost

Plan 9's PU-servers are MULTI-processor machines, to be dimensioned at
about 1 processor PER PROCESS concurrently executing, that is, MORE
than 1 processor/user if the typical users are doing significant
computation (rather than just data-access tasks, handled in the file
server, or terminal-interaction, handled in the gnot).  1 to 3 mbit/sec
from the gnot to the file-and-CPU-servers'-cluster are claimed to be
enough for subjectively-instantaneous interaction, so with high speed
remote connections becoming cheaper and widely available in the future,
this would allow anybody to have "his/her own computer" at hand anywhere
in the world - working from home or from office or on a trip without
even noticing the difference, and so on.

I'm not defending (or attacking!) this system-architecture approach,
just putting right a misconception on the NUMBER of CPU's per user that
it is predicated on!

:386s...  The Plan 9 article in DrDobbs used the COST of workstations
:as a justification for using X-type terminals!!! What is missing is

Given that Plan 9's authors made the UKUUG meeting's prize competition
be on the most fitting INSULT for X, I think you should expect their
seconds (as in "duel"!) after this...:-).  Cost of a very powerful
workstation, say a SS-2, MIPS Magnum, Decstation-5000, or IBM RISC-6000,
is not a joke when you equip it with a nice amount of memory - we're
looking at 40K$ to 50K$ easily (list), and how long will it be before
you would really prefer to upgrade it?


:Let's hear it for Jerry Pournelle's law: (At least) one Cpu per
:user... (and now at least three)...

Definitely not violated by Plan 9.  Please do redirect followups to
comp.arch, as suggested in my header, as the relationship to editors
seems tangential at best, while comp.arch has been recently filled with
non-architectural discussions...!
-- 
Alex Martelli - CAD.LAB s.p.a., v. Stalingrado 53, Bologna, Italia
Email: (work:) staff@cadlab.sublink.org, (home:) alex@am.sublink.org
Phone: (work:) ++39 (51) 371099, (home:) ++39 (51) 250434; 
Fax: ++39 (51) 366964 (work only), Fidonet: 332/401.3 (home only).

cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) (01/23/91)

jfr@locus.com (Jon Rosen) writes:
...
| By the way, this is also why I think Plan 9, as described in several
| recent mags, is severely broken... The emphasis is on terminal servers
| for interaction with the file and CPU servers... thus, no user will
| have a true local computing capability... Why is this still being
| considered??? We can now buy Sparc chips running 15Mips at a cost
| that would allow every individual to have one at relatively low cost.

 There are both significant advantages and significant disadvantages
to both shared versus independant computing facilities and terminals
versus workstations (I'm using "terminal" in the generic sense of
'something that does no significant computing for me', not in the
sense of a VT100). I don't think there's a single right answer for all
circumstances, and I'm not sure the Plan 9 folks would argue that
their approach is right for everyone.

| The Plan 9 article in DrDobbs used the COST of workstations as a
| justification for using X-type terminals!!! What is missing is that
| the use of these kinds of terminals also increases the network
| costs...

 And how much is NFS or RFS network traffic eating, compared to an X
terminal's traffic? The exact tradeoff varies from application mix to
application mix, and from user community to user community. Fast
diskless workstations and fast servers for them kill a network far
faster than almost all uses of X terminals. Note that the Plan 9
design carefully sepperates compute server<->disk server traffic from
Gnot<->compute server traffic.

| In many highly interactive graphic applications (which we are
| starting to see in all disciplines, even the barebones business type
| applications), the number of interactions between the client and
| server at the keystroke or mouse level will put a very heavy burden
| on the network...

 This depends on how you write applications; the Blit approach is to
push as much of the complicated user interaction off to the "terminal"
as possible, and cut down the terminal<->computer traffic. A Blit
application typically does all graphic rendering and user interaction
(or as much as is possible) entirely in the terminal; simple mouse
clicks and keystrokes aren't sent up to the computer, only high-level
commands and whole lines and similar things. The papers the Bell Labs
crowd have written about the Blit, especially in the second issue of
the Bell Technical Journal devoted to Unix (reprinted by AT&T as UNIX
SYSTEM READINGS AND APPLICATIONS, Volume II) makes for very
interesting reading.

 In an effort to inspire new and interesting articles instead of
repeats of the canonical N shared computing versus independant
computing, here's a nice summary article I saved from one of the
previous rounds of this discussion:

Article 14676 of comp.arch:
Path: news-server.csri.toronto.edu!smoke.cs.toronto.edu!neat.cs.toronto.edu!moraes
Newsgroups: comp.arch
From: moraes@cs.toronto.edu (Mark Moraes)
Subject: *MY* machine
Message-ID: <90Mar22.151241est.3224@smoke.cs.toronto.edu>
Followup-To: alt.religion.computers
Organization: Department of Computer Science, University of Toronto
References: <51771@lll-winken.LLNL.GOV> <100598@convex.convex.com> <1990Mar20.174931.2202@utzoo.uucp> <189@nominil.lonestar.org>
Date: 22 Mar 90 20:13:06 GMT
Lines: 75

The last time this thread came up (under the titles "Fad computing"
and "X-terminals vs workstations"), some of us went offline and
had our little private flame war, er, rational discussion.  Some points
that were brought up:

- The problem with single-user vs shared is mainly political, partly
emotional, almost never technical.  (So let's get this debate out of
comp.arch, please -- it has almost nothing to do with architecture
other than the fact that computers are involved periperally in the
debate)

- There's a warm fuzzy feeling of "knowing this machine is MINE, all
MINE, and you can get your grubby paws off it, thank you."  By the
same token, there's this warm fuzzy feeling of having the latest, most
sexy hardware on your desk, often giving you the same effective
throughput as the last generation...

- Some shared computing facilities (SCFs) start to dictate what
hardware their users run.  `No, you can't buy machines from vendor X
even if they're more cost-effective because we don't like them, or
because it'll spoil our "special relationship" with vendor Y.'

- Some shared computing facilities (SCFs) start to dictate what
software their users run.  (In particular, many sysadmins let their
personal idiosyncrasies get in the way of user support -- things like
sh vs csh vs ksh, vi vs jove vs emacs, suntools vs X10 vs X11, troff
vs TeX vs *[Ww]ord* etc)

- SCFs usually involve charging or cost sharing of some form, which is
always a minefield of political problems.  Accusations that one group
of users is subsidizing another, that charges are biased, etc creep in.
People end up preferring to pay larger amounts of money just to get
free of the strings.

- Some SCFs start setting arbitrary resource limits, even if users are
willing to pay for more.  (Anecdotes about the computer centres that
wouldn't let you print more than N pages per month go here)

- Most SCFs hate networks of workstations, especially diskless
workstations since they're a pain to administer.

- Some people believe that running your own workstation is a piece of
cake.  After all, the vendors ship systems that can be used straight
out of the box.

- Sysadmins?  What sysadmins?  That's what grad students are for!

- Disk disasters?  What disk disasters?

- Networks are a snap!

- Security is too expensive; no one will break into our machines!

- Vendors ship secure systems that casual hackers can't break into
easily!

- Why bother upgrading the operating system?

- Having multiple servers and machines makes your environment more
tolerant of faults.  (memories of 45 machines symlinking to a
single shared news partition, mail partition, or /etc/motd go here)

- Having Unix get between your window system and your display can be a
real drag; typically, a cheap windowing terminal gets better
responsiveness than your expensive workstation/cruncher because it
doesn't have to do system calls just to process mouse movement.

- People who want single-user machines are best advised to go and buy
some brand of personal computer, unless they're sufficiently
Unix-savvy, or willing to learn a fair bit of arcania.

	Mark.

PS: Oh yeah, for the humour impaired, some of the items above should
probably have smileys after them...

--
		V9: the kernel where you can do
			fgrep <something> */*.[ch]
		and not get "Arguments too long".
cks@hawkwind.utcs.toronto.edu	           ...!{utgpu,utzoo,watmath}!utgpu!cks

guy@auspex.auspex.com (Guy Harris) (01/25/91)

Well, there's a bit of an oversimplification there.  Remember, there's
also Gnot<->disk server traffic, since a Gnot is *(g)not* a Blit; it's
a, well, diskless workstation, with a real virtual memory OS (basically
the same one as runs on the compute servers) that supports access to a
file system.  Editors can run, in their entirety, on a Gnot (they can
also run, in their entirety, on a compute server, as far as I can tell,
but I think they typically run on the Gnot). 

Since the Gnot won't be running as many applications as a diskless
workstation in a more typical workstation/file server configuration,
you'll probably have less file access traffic over the network, but the
situation isn't identical to that in the Blit/timesharing machine or
X-terminal/timesharing machine case.

>		V9: the kernel where you can do
>			fgrep <something> */*.[ch]
>		and not get "Arguments too long".

(Well, *one* of the kernels where you can do that, anyway.  I've yet to
run out of the 1MB of arguments I get with SunOS 4.x, although if you
use the C shell, *it* might impose a more stringent restriction.)