lamaster@pioneer.arpa (Hugh LaMaster) (06/05/87)
In article <3643@spool.WISC.EDU> lm@cottage.WISC.EDU (Larry McVoy) writes: >Hi. Does anyone out there know about the ETA machine? It's supposed The ETA instruction set architecture is a superset of the Cyber 205. The ETA machine has added instructions to handle block transfers from a large (~256MW) shared memory, and to handle multiple processors, and multi-tasking (like Cray X-MP). As far as a single user is concerned, the difference is multi-tasking and shared memory. The shared memory is like the Cray SSD. Since the basic instruction set is the same as the Cyber 205, that would be the place to start to learn about the ETA. (Another non-architectural difference is a faster clock than the 205). There is supposed to be a new operating system for the Cyber 205 which provides Un*x and Posix kernel services. Unfortunately, the first machine, at Florida state, doesn't have the new software yet. When it does, both Cray (with Unicos) and CDC/ETA will have unix systems on their supercomputers. The old CDC operating system for the 205 is VSOS, which is based on LTSS; users of CTSS on Crays will find it similar [that may be good or bad depending on your point of view :-) ] 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")
lamaster@pioneer.UUCP (06/08/87)
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")