lamaster@ames.arc.nasa.gov (Hugh LaMaster) (06/21/89)
In article <4713@alvin.mcnc.org> spl@mcnc.org.UUCP (Steve Lamont) writes: >Seriously, there is nothing wrong with editing files on a Cray, assuming >that the Cray is reasonably local to you and reasonably responsive. : >for most editing tasks, you simply cannot beat the efficiency. (User, >not system) I agree with almost all of this, but would add one comment. "They" who claim that text editing is "inefficient use of a Cray" should have some numbers to back them up. Let them prove that: 1) It is more cost effective to edit on another system, counting the cost of moving the file over to be edited via the network, etc. Don't forget the cost of reading the entire file from disk on the Cray, writing it over the network, reading it back, and writing it to disk, not to mention the CPU and memory utilization by the network layer in the kernel, etc. Then, add the incremental cost of providing computing resources on your editing machine. 2) The cost *savings* (if any) are in any way significant, as a percentage of dollars and/or CPU utilization on the system, on the system in question, looking at the amount of editing that people are actually doing. Then, if they can prove *that*, you can invoke the user efficiency argument. What is lacking is hard evidence that "editing" is a problem in the first place. But, just speculating, my experience is that the most precious resource on Crayxyz's is not interrupts or CPU, but memory, so I guess that if you were looking for a problem you might try to demonstrate that editing is hurting your memory utilization and causing a significant increase in swapping. "System efficiency" in the narrow sense is obviously not synonymous with "getting the job done using the least system resources", but for some reason people forget that when the subject is editing. *sarcasm on* "editing" on "Crays" has been a bugaboo for quite a while. Eventually, people who are morally opposed to it will retire :-) I guess we shouldn't be using interactive debugging either. Isn't it obvious that it is more efficient to insert print statements and resubmit the same job over and over to debug it? After all, you can prove that CPU and memory utilization on the system are higher when you debug in batch mode... Also, programs which do I/O should be banned, since they lower CPU utilization... *sarcasm off* Hugh LaMaster, m/s 233-9, UUCP ames!lamaster NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 Phone: (415)694-6117
khb@chiba.Sun.COM (Keith Bierman - SPD Languages Marketing -- MTS) (06/21/89)
In article <27289@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes: > >1) It is more cost effective to edit on another system, counting the cost >of moving the file over to be edited via the network, etc. Don't forget >the cost of reading the entire file from disk on the Cray, >writing it over the network, reading it back, and writing it to disk, not >to mention the CPU and memory utilization by the network layer in the kernel, >etc. Then, add the incremental cost of providing computing >resources on your editing machine. > >2) The cost *savings* (if any) are in any way significant, as a percentage of >dollars and/or CPU utilization on the system, on the system in question, >looking at the amount of editing that people are actually doing. > It will all depend on how your network is configured, how large your files are and how much editing we are talking about. If the files start out on a front end (say a sun4/390 :>) with NFS and all that, editing locally may be quite cheap. And if you are doing massive edits over several hours, you may not care about "start up time" If the files are huge, the edits are minor and the communication costs are high (say the files live directly on the Cray) clearly running emacs (vi, asoft's tpu or whatever) on the Cray is a win. I used to copy files over a 1200 baud line from a VAX down to a Mac ... if I was going to work on a file for any length of time ... because that made my lifer easier. When I only wanted to tweak a line or two, I used SOS ... the point should be how to maximize work accomplished/satisfaction with the environment. cheers Keith H. Bierman |*My thoughts are my own. Only my work belongs to Sun* It's Not My Fault | Marketing Technical Specialist ! kbierman@sun.com I Voted for Bill & | Languages and Performance Tools. Opus (* strange as it may seem, I do more engineering now *)
fink@nucthy.physics.orst.edu (Paul Fink) (06/21/89)
It is worth mentioning NMFECC's remote editing system. They have a program
for an IBM PC that runs Emacs locally. The companion program on the Cray
sends the PC only the part of the file you are editing, one screen at a time.
When you are done the PC send the diff's to the Cray and the file on the
Cray is updated. This gives good response to the user and minimizes Cray time.
For distant, poorly connected systems it works well.
The bigger question is do we look at supercomputers as just compute servers
or as complete systems? The answer seems to depend on on much Cray time you
get and how you talk to the machine.
____________________________________________________________________________
Paul J. Fink Jr. Internet:
Oregon State University fink@PHYSICS.ORST.EDU
Department of Physics Phone:
Corvallis, Oregon 97331 (503) 754-4631rchrd@well.UUCP (Richard Friedman) (06/22/89)
In article <27289@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes: >What is lacking is hard evidence that "editing" is a problem in the first >place. But, just speculating, my experience is that the most precious >resource on Crayxyz's is not interrupts or CPU, but memory, so I guess that if >you were looking for a problem you might try to demonstrate that editing >is hurting your memory utilization and causing a significant increase in >swapping. > Hugh: MY experience is that editing directly on the CRAY is VERY frustrating (UNICOS). I have to log in via phonelines or networks and the delays both with UNICOS swapping and network make working with VI (say) almost impossible. Having to wait a few seconds for responses leads to real confusion. And editing mistakes. For small editing situations (changing a few syntax errors for example) its alright. But any extensive restructuring of a program I'd rather edit it on my workstation and use KERMIT to upload to the Cray. The problem is trying to do critical work (like editing) in a timesharing environment. What I have done is build a small testbed in my Apollo so I can develop codes locally and only later bring them to the Cray. But then again, my Cray isn't in the next room. (Its 3Kmiles away). -- ...Richard Friedman rchrd@well.uucp (Pacific-Sierra Research/Berkeley, CA.) also: {lll-crg,pacbell,hplabs}!well!rchrd
lamaster@ames.arc.nasa.gov (Hugh LaMaster) (06/22/89)
In article <12295@well.UUCP> rchrd@well.UUCP (Richard Friedman) writes: >In article <27289@ames.arc.nasa.gov> lamaster@ames.arc.nasa.gov (Hugh LaMaster) writes: >Hugh: MY experience is that editing directly on the CRAY is >VERY frustrating (UNICOS). I have to log in via phonelines >or networks and the delays both with UNICOS swapping and network >make working with VI (say) almost impossible. Having to wait My experience has been that it works well when you want to make small changes, as described below. I agree that it makes a lot less sense to write a new program. In fact, the best way to do handle the entire data sharing problem is probably an NFS file sharing system positioned in between your home machine and the compute server. The UNICOS scheduler leaves something to be desired, but it is OK. >editing mistakes. For small editing situations (changing a few >syntax errors for example) its alright. But any extensive Practically speaking, there are times when you want to edit on the Cray and times when you don't. My point was simply that applying pseudo-moral reasons to the decision is not helpful (e.g. "It is a misuse of a Cray to edit on it. The Cray is too expensive/important/whatever to edit on... etc." The Cray makes a very good editor when you want to make a small change to a large file and reuse it immediately on the Cray. Hugh LaMaster, m/s 233-9, UUCP ames!lamaster NASA Ames Research Center ARPA lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 Phone: (415)694-6117
desj@idacrd.UUCP (David desJardins) (08/09/89)
From article <27396@ames.arc.nasa.gov>, by lamaster@ames.arc.nasa.gov (Hugh LaMaster): > My experience has been that it works well when you want to make > small changes, as described below. I agree that it makes a lot less > sense to write a new program. In fact, the best way to do handle > the entire data sharing problem is probably an NFS file sharing > system positioned in between your home machine and the compute > server. I'm not sure that I follow this. Does ``in between'' mean at the remote user's site, or at the compute server's site? (Surely it doesn't mean halfway in between, say in Kansas somewhere.) And do you mean that the ``master'' copy resides on the compute server, or on the file server? If the master copy resides on the file server then you find (for example) that you need to transfer all of the ingredient files to the compute server every time you wish to recompile a large package. So that seems unworkable. On the other hand, if the master copy resides on the compute server, then you have all of the problems of copying the file from the compute server to the file server every time you wish to edit it; it seems you might as well just copy it to your home machine. What exactly did you have in mind? -- David desJardins