Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!rex!ames!pioneer.arc.nasa.gov!lamaster From: lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) Newsgroups: comp.arch Subject: Re: RISC vs. CISC -- SPECmarks Message-ID: <1991May2.162909.9165@news.arc.nasa.gov> Date: 2 May 91 16:29:09 GMT References: <3423@charon.cwi.nl> <11602@mentor.cc.purdue.edu> <1991Apr30.163153.18568@midway.uchicago.edu> Sender: usenet@news.arc.nasa.gov (USENET Administration) Organization: NASA Ames Res. Ctr. Mtn Vw CA 94035 Lines: 67 In article <1991Apr30.163153.18568@midway.uchicago.edu> rtp1@quads.uchicago.edu (raymond thomas pierrehumbert) writes: >> Comments on Cyber 205, page faults, etc. > >I suffered with a Cyber 205 for 6 or 7 years, and I know the machine >from a scientific user's viewpoint. For just about all fluids >codes, we found virtual memory to be essentially worthless. For Cray was quoted once as saying something like (paraphrase): "If you don't have it (real memory) you can't fake it." If you look at "Virtual Memory" as an attempt to fake real memory, then, it won't work. On the other hand, from the Operating System point of view, "Memory Mapping" (another name for Virtual Memory) has tremendous benefits, particularly if you want even a modest interactive load. Otherwise, you either buy twice as much memory as you really need, or, throw away half you CPU swapping big jobs against each other. To some extent, the benefit of virtual memory is invisible to the user. If the system has virtual memory, you can run interactively and still get very high utilization. On the other hand, your particular job hasn't speeded up. But, the user benefits due to more throughput/faster turnaround/etc. >out of core codes, we had to manage I/O by hand, and about all >virtual memory did for us was to enable us to create blocks of >virtual storage that we could move things in and out of "by hand" Well, I saw 205 jobs which used the memory mapping I/O functions to achieve full channel utilization on 8 high speed channels. I would say that I saw virtual memory create great benefits to individual jobs through this technique (memory mapped files, combined with the "advise" functions to tell the system what pages you expected to use). You could program really fast I/O on that system, and also get an immediate benefit as soon as more memory was available to the job. >vs. otherwise. What made the Cyber a pain to program, and killed it >vs. the Cray, was that (1) it had a long pipeline, hence a big hit >for short vectors, which meant that codes had to be rewritten to >use very long vectors, True, this was a big problem. The benchmarks that ran on the ETA-10 showed that the long vector startup was not necessary. The ETA-10 had better instruction overlap with the same basic architecture. (2) it couldn't execute vector instructions >unless data was contiguous in memory, so for non-unit strides, you >had to do scatter-gather. Yes, this really was the Achilles Heel for this particular Architecture. >The cache machines, like IBM, also have problems with non-unit >strides, but I'm finding that using strip-mining, it is relatively >easy to get around them, provided your algorithm has re-use of >data. I have only limited experience with the new, fast-only-in-cache, machines, but I have to say that the code you need to get optimum performance is even more non-intuitive than that for the older vector architecture machines. Even worse, code which was previously optimal for vector machines, and which was OK on a wide variety of other machines, is now pessimal for these machines. Sigh... Hugh LaMaster, M/S 233-9, UUCP: ames!lamaster NASA Ames Research Center Internet: lamaster@ames.arc.nasa.gov Moffett Field, CA 94035 With Good Mailer: lamaster@george.arc.nasa.gov Phone: 415/604-6117 #include