eugene@pioneer.arpa (Eugene N. Miya) (02/28/88)
In article <416@micropen> dave@micropen (David F. Carlson) writes: >I know most of these CRAYs are used in DoD research on important things like >bombs and SDI, but my running an EDITOR (ie. slow interactive process) >on a CRAY--presumably payed for with my tax dollars. Ouch! Can't you >find any good emacs for a VT100 on a VAX11/780 to run twenty editor jobs? >(I bet every government facility has tons of workhorse CPU for editor >sessions rather than that premium CRAY time.) Actually most Crays (either 1/Xs, or 2s) aren't used by DOD any more. (Note between LANL and LLNL, there's only 1/4 of a Cray 2 for over a dozen Crays between them) and we are all scambling for the first Ys. In defense of Marty's comment about editing, let me say there's nothing like trying to debug BIG, parallel processing research programs like having a reasonable editor (try 20 MB text files). Yes, we all believe there is a better way, but we are all uncertain of what is. Write us some distributed applications (portable across heterogeneous machines). You can at least keep Unix, ignore those COS, CTSS, VSOS sites. ;-) From the Rock of Ages Home for Retired Hackers: --eugene miya, NASA Ames Research Center, eugene@ames-aurora.ARPA "You trust the `reply' command with all those different mailers out there?" "Send mail, avoid follow-ups. If enough, I'll summarize." {uunet,hplabs,hao,ihnp4,decwrl,allegra,tektronix}!ames!aurora!eugene
lamaster@ames.arpa (Hugh LaMaster) (03/01/88)
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. It was also true then that the available supercomputers were very cost effective for scalar computing in general (relative to the alternatives, such as VAXes and IBM's). Advances is microprocessors make this untrue today, but even so don't assume that it is cheaper to ship a file across a network than to edit it locally. Supercomputers can even be cost effective as database processors (talking about very " ADPish" sorts of activities). They also happen to compute floating point problems quickly. Now, if we could do something about supercomputer software (actually, we are ...>
himel@mips.COM (Mark I. Himelstein) (03/02/88)
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