Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!necntc!ames!pioneer!lamaster From: lamaster@pioneer.UUCP Newsgroups: comp.arch Subject: Re: ETA Message-ID: <1711@ames.UUCP> Date: Mon, 8-Jun-87 15:14:37 EDT Article-I.D.: ames.1711 Posted: Mon Jun 8 15:14:37 1987 Date-Received: Wed, 10-Jun-87 07:05:01 EDT References: <3643@spool.WISC.EDU> <3238@well.UUCP> Sender: usenet@ames.UUCP Reply-To: lamaster@pioneer.arc.nasa.gov (Hugh LaMaster) Organization: NASA Ames Research Center, Moffett Field, Calif. Lines: 71 In article <3238@well.UUCP> rchrd@well.UUCP (Richard Friedman) writes: >The ETA-10 is (will be? was? might be?) an 8 processor system. >Each processor is essentially a Cyber-205. >Apparently, there will also be a 4 processor version. There is a 1 processor machine installed and running at Florida State. The UNIX operating system is not running, however; there is a skeleton operating system at the moment. The current hardware design permits up to 8 processors. When the multiprocessor/multitasking/unix_services kernel is running, multiple processor machines could be shipped. My understanding is that all the problems are software, not hardware (which ought to make them easy to solve, right :-) ) >Like the cyber-205, it will have all the problems of that >machine. CDC has a very arrogant attitude towards programming, True, perhaps, but the next statement does not follow >and to attain the top speed of the machine, you have to >write in 205-FORTRAN with many non-standard syntax constructs. > On the Cray, you have to write in assembly language. The 205 Fortran constructs are much easier to use than assembly language. If you are saying that less programmer effort is required to get a certain level of vectorization on the Cray (for example) then you are certainly correct. The Gather problem discussed below is the primary reason. >Unlike the CRAY and other vector processors, the 205 is a memory to >memory pipeline, and can only attain high speeds for long >vector lengths. Virtual memory also degrades vector performance >everytime there is a reference out of in-core memory. There are several misconceptions here. Memory to memory vector instructions do not imply long start up times. The long start up times on the Cyber 205 are a result of various design decisions. The Cyber 205 pipeline implements much more than the add, multiply, divide, and logical instructions that the Cray has. Unfortunately, these functions add setup time and pipeline stages. Sometimes, these functions save a lot of CPU time. With 20-20 hindsight, there is probably a better implementation. In my experience, the biggest problem with Cyber 205 performance is that non-contiguous vectors must be GATHERED first. This puts a much bigger burden on the programmer than machines (Cray et al) which allow vectors to have a constant stride with no performance penalty. Finally, there is the shibboleth about virtual memory. Seymour Cray is right; you can't fake (physical memory) that you don't have. However, virtual memory does not hurt performance either, and simplifies data management in many ways. However, whether you have virtual memory or not, if your problem is bigger than physical memory, you will have to arrange data access such that you are actually working on real memory, and you have to stream the data in and out quickly. This is just as much of a problem with the Cray architecture. Both companies have hit upon the same solution: bigger memories. There are many considerations favoring virtual memory over Cray type addressing. I don't want to go into them all here, but imagine having to swap 128 MW out just to bring in a 30 KW process which will run for a second. Hugh LaMaster, m/s 233-9, UUCP {seismo,topaz,lll-crg,ucbvax}! NASA Ames Research Center ames!pioneer!lamaster Moffett Field, CA 94035 ARPA lamaster@ames-pioneer.arpa Phone: (415)694-6117 ARPA lamaster@pioneer.arc.nasa.gov "In order to promise genuine progress, the acronym RISC should stand for REGULAR (not reduced) instruction set computer." - Wirth ("Any opinions expressed herein are solely the responsibility of the author and do not represent the opinions of NASA or the U.S. Government")