vvawh@convx1.lerc.nasa.gov (Tony Hackenberg) (10/04/90)
Does anyone know of any studies on the effect of allowing vi usage by many users on supercomputer performance? Does anyone know if there are versions of "vi", "emacs", or other full screen editors that are written to minimize performance hits on supercomputers? -- Tony Hackenberg NASA/Lewis Research Center M.S.142-2, 21000 Brookpark Rd., Cleveland, OH 44135 Internet: vvawh@convx1.lerc.nasa.gov Phone: (216) 433-5201 (work) Opinions are mine & do NOT represent any official position by my employer.
booker@network.ucsd.edu (Booker bense) (10/05/90)
In article <1990Oct4.050509.11405@eagle.lerc.nasa.gov> vvawh@convx1.lerc.nasa.gov (Tony Hackenberg) writes: >Does anyone know of any studies on the effect of allowing >vi usage by many users on supercomputer performance? > >Does anyone know if there are versions of "vi", "emacs", or other >full screen editors that are written to minimize performance >hits on supercomputers? > > > >-- Several people in the systems group here have studied such things, they have even developed an rvi which allows remote editing of files on the YMP. My "limited" understanding of it is that is uses tcp/ip sockets to grab the file down to your workstation. The actual editing takes place there and when you save the file , the changes go back to the YMP. People to contact about this would be schroeder@sdsc.edu or zhengc@sdsc.edu. In my experience the biggest effect of many small interactive jobs is that is makes getting any performance benefits out of auto-tasking very difficult. The more processes there are the more difficult it is to get all of your processes into the cpu. I hear rumors that Unicos 6.0 will include the idea of a "family" of processes and schedule all of them into the cpu at the same time. Also editing( depending on how the scheduler works and how big your ssd is ) can be a very frustrating task. Being swapped out for 40 secs is not fun. One of the local modifications to the kernel we have made here is to include a second-swapper for interactive jobs. Another change made was include a penalty for excessive system calls in the swapper. As a general rule , if the system overhead gets much above 7-8% , everyone feels the effects. - Booker C. Bense /* benseb@grumpy.sdsc.edu These are my own ramblings, no offical opinion , endorsement or actual fact is implied. */
boylanr@silver.ucs.indiana.edu (ross boylan) (10/09/90)
vvawh@convx1.lerc.nasa.gov (Tony Hackenberg) writes: >Does anyone know of any studies on the effect of allowing >vi usage by many users on supercomputer performance? >Does anyone know if there are versions of "vi", "emacs", or other >full screen editors that are written to minimize performance >hits on supercomputers? I recall that some documentation from NCSA (Crays under UNICOS) said that it was OK to run emacs; it didn't degrade system performance.
seanf@sco.COM (Sean Fagan) (10/11/90)
In article <boylanr.655424875@silver> boylanr@silver.ucs.indiana.edu (ross boylan) writes: >I recall that some documentation from NCSA (Crays under UNICOS) said >that it was OK to run emacs; it didn't degrade system performance. Ah, yes, Crays: machines where a 1-2Mb EMACS process is considered small. It isn't that the emacs didn't degrade performance, it was that it was found that using emacs (or other editors, for that matter) locally on the cray was more efficient in *programmer time* than ftp'ing the file from the cray, editing locally on your workstation, and ftp'ing it back. And, yes, programmer time is still very expensive. -- -----------------+ Sean Eric Fagan | "Never knock on Death's door: ring the bell and seanf@sco.COM | run away! Death really hates that!" uunet!sco!seanf | -- Dr. Mike Stratford (Matt Frewer, "Doctor, Doctor") (408) 458-1422 | Any opinions expressed are my own, not my employers'.
cedman@lynx.ps.uci.edu (Carl Edman) (10/12/90)
In article <8144@scolex.sco.COM> seanf@sco.COM (Sean Fagan) writes: In article <boylanr.655424875@silver> boylanr@silver.ucs.indiana.edu (ross boylan) writes: >I recall that some documentation from NCSA (Crays under UNICOS) said >that it was OK to run emacs; it didn't degrade system performance. Ah, yes, Crays: machines where a 1-2Mb EMACS process is considered small. It isn't that the emacs didn't degrade performance, it was that it was found that using emacs (or other editors, for that matter) locally on the cray was more efficient in *programmer time* than ftp'ing the file from the cray, editing locally on your workstation, and ftp'ing it back. And, yes, programmer time is still very expensive. It still seems like a terrible squandering of resources to use valueable cray preformance to do such a simple job with low (by cray standards) preformance requirements as editing files and at the same time use your local workstation as dumb terminal. The solution ? Use "ange-ftp" , a free emacs lisp file. It allows you to read and write files on any filesystem reachable via ftp completely transparently. f.e. if I want to edit a file "/tmp/foo" on the cray "y1.sdsc.edu" and use emacs here to do it I simply open a file (by the standard method) and give "/y1.sdsc.edu:/tmp/foo" as a file name. Reading, writing, dir-edit-ing, and even file name completion works just as if the entire cray filesystem was local. Isn't emacs great ? (No, please no editor flamewar. vi, is great,too) Carl Edman Theorectial Physicist,N.:A physicist whose | Send mail existence is postulated, to make the numbers | to balance but who is never actually observed | cedman@golem.ps.uci.edu in the laboratory. | edmanc@uciph0.ps.uci.edu