Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!lamaster From: lamaster@ames.arc.nasa.gov (Hugh LaMaster) Newsgroups: comp.arch Subject: Re: Cray & Amdahl (Really: VM on vector processors) (Was: ...) Message-ID: <12174@ames.arc.nasa.gov> Date: 22 Jul 88 16:15:39 GMT References: <4232@cbmvax.UUCP> <76700035@p.cs.uiuc.edu> <9a0K/cbluk1010IHSPc@amdahl.uts.amdahl.com> <228@sdeggo.UUCP> <5342@june.cs.washington.edu> <7588@boring.cwi.nl> Reply-To: lamaster@ames.arc.nasa.gov.UUCP (Hugh LaMaster) Organization: NASA Ames Research Center, Moffett Field, Calif. Lines: 70 In article <7588@boring.cwi.nl> dik@cwi.nl (Dik T. Winter) writes: >The major problem with virtual memory on vector machines is that you get >paging interrupts during the execution of an instruction. The CDC 205 >has virtual memory, and there are problems. I beg to differ. I have seen no "problems" with virtual memory on the Cyber 205, other than those arising from: 1) The confusion that users sometimes experience when they have a larger set of facilities to choose from, or, 2) Problems which are exactly the same on Crays- namely, there is never enough real memory for some people and their programs. >the instruction. That takes a lot of time. The 205 has two different >page sizes, large pages of 65536 words (8 bytes/word) and small pages >of (site selectable) 512, 2048 or 8192 words. The number of >associative registers is 16, and these are shared amongst the jobs on >a system. It appears that the selection of small page size is very >critical. I have a small (~10 lines) program that will run 2 times The Cyber 205 does have a "problem" because of its memory to memory vector instruction set, as opposed to Cray's vector registers. The problem is/was vector startup time was fairly long on the Cyber 205. This problem appears to have been solved on the ETA-10 with better overlap, etc., and short vector performance seems to be much better. (Still the same memory to memory architecture.) The "problem" with small page sizes is actually an installation option intended to benefit installations with a relatively small amount of main memory. The solution, if you have more memory, is to use a larger small page size. > >The Cray on the other hand addresses all its memory directly, so no >address translation is needed and no vector instruction interrupt. It is true that Cray vector instructions are atomic, and those on the 205 are restartable, but the context is saved quite efficiently on the 205. A complete context switch actually takes fewer cycles on the 205 than it does on the Cray 1/X/Y-MP's, and many fewer than the Cray-2. So, the assumption that virtual memory OR memory to memory vector instructions cause long context switch times relative to Cray is not correct. As stated above, the "price" of the 205 architecture was poor short vector performance, and, or course, the extra hardware that virtual memory consumes (a virtual memory MMU takes up a LOT more space than a non-virtual MMU - I think it is worth it but others disagree...). I note also that a Benefit to the 205 architecture is excellent long vector performance. >to memory, and the maximal vector size is 65535. So my arguments >above would imply that you could have a Cray with virtual memory, >but not a 205! There is, in fact, no reason why a Cray type architecture can't have virtual memory. In fact, a number of vector machines built by other companies have done approximately that. The real debate, in my opinion, is not between virtual and non-virtual (virtual won a long time ago, in my opinion- Cray is an anachronism in this respect) but between a memory to memory pipeline and a vector register architecture. But these are only two of many proposed possibilities, and some good performing machines have been built with other architectures entirely. None have been commercially successful yet, but I would not assume that that will always be the case. -- 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