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.)