Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!pyramid!prls!mips!himel
From: himel@mips.COM (Mark I. Himelstein)
Newsgroups: comp.arch
Subject: Re: Editing on Crays
Message-ID: <1734@gumby.mips.COM>
Date: 1 Mar 88 16:25:29 GMT
References: <9495@steinmetz.steinmetz.UUCP> <3815@megaron.arizona.edu> <235@amelia.nas.nasa.gov> <416@micropen> <5288@ames.arpa> <5381@ames.arpa>
Reply-To: himel@gumby.UUCP (Mark I. Himelstein)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 34

In article <5381@ames.arpa> lamaster@ames.arc.nasa.gov.UUCP (Hugh LaMaster) writes:
>Editing on Crays is not as far fetched or sacrilegious as most people seem to
>assume.  A few years ago during one presentation I saw someone claimed that
>Crays were the most cost effective editing machines available.  I believe it
>was true then.

I was involved in an analysis of this problem as well as the more general
problem of "Should we do multi-user interactive timesharing on the CRAY
or just keep bying more vaxes?" at Sandia labs in Livermore a couple of
years ago. The timesharing system was Lab developed CTSS.
A couple of notes that were true 5 years ago (no idea how they have
aged with the advent of cheap supermicros):

- indeed all statistics we saw from various places (most notably MFECC)
	that were running timesharing on their CRAY's indicated that the
	cost per seat was cheaper than adding "front-end" machines.
- no "interactive" system I knew of then on CRAY's were support character
	interrupts. Most were line oriented. Most users were developing
	ways to interact with pc's so screen oriented editing occurred
	in the pc without undo bother to the CRAY.
- most everyone's general belief was that having the whole cycle of
	interactive development on the same machine you ran on increased
	productivity (edit/compile/run/debug).
- many common interactive activities could be done by the CRAY very
	effectively-- like searching text files which is a common part
	of editing activity.
- In some aspects, CRAY's running CTSS were more friendly than UNIX. For 
	example, a job that died due to an error or machine crash
	was easily restartable (runnable core files, checkpointed IO files,
	etc). Since these machines are costly, CTSS developed a healthy 
	respect for sustaining long running jobs.
- CTSS could be configured to favor batch or interactive jobs on the fly.

Mark I. Himelstein	<I speak for myself>
himel@mips.COM