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