alan@uf.msc.umn.edu (Alan Klietz) (10/07/90)
Archive-name: rvi/05-Oct-90 Original-posting-by: alan@uf.msc.umn.edu (Alan Klietz) Original-subject: Re: "vi" & Supercomputer Performance Archive-site: uc.msc.edu [137.66.1.3] Archive-directory: /staff/rvi Reposted-by: emv@math.lsa.umich.edu (Edward Vielmetti) Credit please. Rvi was written at the University of Minnesota in 1987 and posted to comp.sources.unix volume 4. The most recent version is available via anonymous ftp to uc.msc.edu in the directory /staff/rvi. Secondly, it does not copy the file but rather it generates ``ed'' commands for execution on a remote machine. So anyway, let's talk philosophy. Simply put, you have to weigh to machine cost of keystrokes against the benefit of better user interaction. The average # of keystrokes that can reach a supercomputer remain somewhat constant while the number of cycles per unit of time that a super can offer has historically increased exponentially with each new model. So the fraction of supercomputer processing power dedicated to keystroke processing eventually crosses a critical threshold where it becomes acceptible. It reflects not only raw CPU speed but also multithreaded kernels, multiheaded machines, better I/O devices (e.g. DX Hyperchannels), better Internet latency, and so on. Historical note: Rvi was written before we did a study that showed that a single processor Cray-2 w/slow memory had less than 7% overhead in dealing with 32 simulated users in vi typing one keystroke per second. So we junked rvi and we ported vi and X10 to our machine. This was back when the debate was still raging at Cray Research. Today they offer X11 as a standard product. Granted, autotasking complicates things somewhat because it makes a context switch much more painful where stragglers can slow down striped loops. I don't know how UNICOS 6 does things, but as you suggested it ought to dedicate processors to autotasking or greatly penalize switches of active autotasked jobs. Swapping can be avoided by setting your sched parameters appropriately. There is nothing intrinsically wrong with running a screen editor on a supercomputer. -- Alan E. Klietz Minnesota Supercomputer Center, Inc. 1200 Washington Avenue South Minneapolis, MN 55415 Ph: +1 612 626 1737 Internet: alan@msc.edu