shore@ncifcrf.gov (Melinda Shore) (08/23/88)
In article <20463@tut.cis.ohio-state.edu> bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes: >The Cray vector architecture has fairly poor handling of character I/O >and interrupts/context switches, at least in the conventional UNIX >sense. Not to mention no VM and poor performance swapping large processes. While the trend on interactive systems is to optimize user performance (as opposed to machine performance), you probably don't want to sink your Cray just to run emacs. -- Melinda Shore shore@ncifcrf.gov NCI Supercomputer Facility ..!uunet!ncifcrf.gov!shore
cracraft@venera.isi.edu (Stuart Cracraft) (08/29/88)
In article <588@fcs280s.ncifcrf.gov> shore@ncifcrf.gov (Melinda Shore) writes: >In article <20463@tut.cis.ohio-state.edu> bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes: >>The Cray vector architecture has fairly poor handling of character I/O >>and interrupts/context switches, at least in the conventional UNIX >>sense. > >Not to mention no VM and poor performance swapping large processes. >While the trend on interactive systems is to optimize user performance >(as opposed to machine performance), you probably don't want to sink >your Cray just to run emacs. Cray will never have VM. Trying to fit every Unix process into Cray main memory and swapping out whenever one or two people type a character to service the interactive processes is tantamount to disaster. In fact, this is being noticed. Whenever two or three compute-bound processes are running under Unicos, the interactive users go totally unserviced for periods ranging as long as several minutes; it is questionable whether tuning parameters, using a better scheduler, or even increasing main memory will fundamentally change this. Face it folks! The Cray ain't a Unix timesharing system. It's going to be interesting to see as more and more Crays switch to Unicos whether the system will be turned into a batch environment and logins disallowed since the interactive response is so poor. Give me a high-end Vax Unix/Ultrix any day for interactive work. Or better yet, a Toshiba T5100 laptop portable running Unix! Stuart
fouts@lemming.nas.nasa.gov.nas.nasa.gov (Marty Fouts) (08/30/88)
In article <20463@tut.cis.ohio-state.edu> bob@allosaur.cis.ohio-state.edu (Bob Sutterfield) writes: >In article <523@nikhefh.hep.nl> i91@nikhefh.hep.nl (Fons Rademakers) writes: >>Could somebody tell me if it possible at all to port GNU Emacs to a >>Cray runnig Unicos 4.0? If so, did somebody already to this? If not, >>why not? > >It's been done with an older version of Unicos. But do you really >want to do your work that way? > >The Cray vector architecture has fairly poor handling of character I/O >and interrupts/context switches, at least in the conventional UNIX >sense. I suspect you'd get better performance (and bother the heavy >crunchers on the Cray less) if you used ftp-find-file to keep the >editing on your friendly local workstation or front-end host. Do the >compiling and debugging and big problem solving on the Cray, and keep >the user interaction on a machine better suited to it. > WE use GNU on our Cray 2, and find that ftp-find-file would require much more overhead on the 2 then using GNU does. I've seen this its-faster-not-to-do-characters-on-a-supercomputer reflex a lot of times, but when I've measured it, it doesn't work out to be true. ftp, especially of a long (>60K line) program for a small number of changes is much more expensive than making the same changes in a window. It is true that interaction should happen on the front end and computing on the back, but ftp-find-file isn't as effective as keeping a shell window open, editing and doing recompiles locally. Better yet might be supdup with GNU split between the front and back end, ala Pike's editor on the BLIT, but I haven't measured that, so I am only speculating. +-+-+-+ I don't know who I am, why should you? +-+-+-+ | fouts@lemming.nas.nasa.gov | | ...!ames!orville!fouts | | Never attribute to malice what can be | +-+-+-+ explained by incompetence. +-+-+-+
jr@PIZZA.BBN.COM (John Robinson) (09/02/88)
Marty Fouts <fouts%lemming.nas.nasa.gov@BBN.COM> said: > Better yet > might be supdup with GNU split between the front and back end, ala > Pike's editor on the BLIT, but I haven't measured that, so I am only > speculating. How about X client code on the Cray, with server on a Sun or uVax? Emacs already includes X support. The WS is fast enough at the screen updating, and the super would just send lots of lines of new screen. I/O interrupts happen at packet (line) boundaries rather than every character on the Cray (right?). Of course X is probably just the supdup of the '90's :-). /jr jr@bbn.com or bbn!jr