Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site utah-cs.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!utah-cs!shebs
From: shebs@utah-cs.UUCP (Stanley Shebs)
Newsgroups: net.ai
Subject: Re: Workstations vs Timeshare
Message-ID: <3528@utah-cs.UUCP>
Date: Wed, 6-Nov-85 17:18:45 EST
Article-I.D.: utah-cs.3528
Posted: Wed Nov  6 17:18:45 1985
Date-Received: Fri, 8-Nov-85 20:58:53 EST
Organization: Univ of Utah CS Dept
Lines: 69

I really hate to go on about this, but if it affects AI expenditures, I
suppose it's worthwhile to explicate the two positions:

>From: forbus@uiucdcsp.CS.UIUC.EDU
>
>Ahem.  How many people who buy vax 780's give them to a single user?  Worse
>still, many people who buy Suns seem to run them with multiple users, and
>often swapping over a network to a shared disk.  The latter is a crazy idea
>for AI programs; while the ethernet may or may not be a bottleneck, sharing
>a disk between several processors certainly is!

Perhaps I'm spoiled; the utah-orion (11/750) load average generally only
goes over 1 when I'm running several compiles in the background, so it's
effectively a single-user machine.  I used to use an Apollo for Lisp, and
gave up on it when I got tired of watching pages fly up and down the little
coax cables.  Each person doing AI work *must* have a certain minimum of
resources - doesn't really matter whether it's in the form of shared big
machine or a workstation.

>And of course, none of the
>Gabriel benchmarks really test paging performance, which is where
>non-trivial AI programs spend most of their time.

I beg to differ; both the "boyer" and "browse" benchmarks are in
the million-cons range, and some others too I think (don't have the
details handy, sorry).  The 3600 spent substantial portions of its
time paging.  One of the reasons that the HP9836s (68000) machines
perform so well on those same benchmarks is that they don't have
virtual memory at all!  Instead, they have maybe about 8 megs of REAL
memory, and really streak along.

I grant that much of the work in qualitative physics is on an even
larger scale than that tested by any of the Gabriel benchmarks, but
most AI research isn't that computation-intensive (for instance,
studying knowledge representation involves more language-building effort
than it does raw computation).  If you *really* want to do massive
computation, get a Cray (as Boyer & Moore are doing for their theorem
prover).

>Remember, however, the original question refered to lisp machines
>versus standard time-sharing environments.  If a stand-alone 20 with PSL
>performs in the neigborhood of a Symbolics, then how will it do with
>20-60 users?  Answer: very badly!

Depends on the load average.  The load average on most machines at
Utah is usually below 1, and therefore the real time results correspond
pretty well to the benchmark results.  

>I think it is safe to say that there
>is NO computer on the market which runs Common Lisp (other lisps are simply
>not contenders at this stage of the game) which will provide for several
>users at once the same performance they can get if they are sitting at
>stand-alone workstations (be they Symbolics, Sun, TI, or Xerox).

Pretty safe all right! For "Common Lisp" substitute "an arbitrary program"
and you still get the same obvious truism.  Again, it depends on the load
average.  The original argument for timesharing hasn't gone away!  If out
of 10 people logged on, only 1 is actually executing a program, then a
timeshared system looks just like a single-user machine.  A timeshared
system gets into trouble under two situations: 1) if everybody is madly
hacking, and not stopping to think, and 2) when the programming environment
does lots of things for the programmer.  Situation 1 seems the normal mode
of operation on workstations - I leave it to you to decide if it's desirable
(personally, I prefer to sit and think about my programs).  Situation 2 will
be a powerful argument for workstations, if it ever comes about... (please
don't flame about any existing PEs, I've used many of them and they have
so little semantic knowledge of my programs that it's ludicrous)

							stan shebs