Talk:Cray-1
From Wikipedia, the free encyclopedia
 | This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
| ||||||||||||||
speed
The problem citing the 800 MFLOPS number for the X-MP (the Cray-1's lineage successor) is that this performance figure does NOT correspond to 1982 performance for a 2 processor (then available) X-MP; it more closely corresponds to 4 processor X-MPs on a "good" day which was not until a couple of years later. The text has an impediance mismatch between machine performance and chronology.
--enm 26 Apr 2006 18:00 GMT
- The problem I see with this artical is that thier seems to be inconsistences in the speeds given for the cray-1 and apparently also thiers an accidental use of the acronym MIPS rather then MFLOPS (or megaflops). This article states that In 1975 Cray clammed that the speed was 80 MFLOPS and then give an un-named sorce credit for placed the speed of the Cray-1 at "138–250 MFLOPS". I visited Cray inc's web site and Cray inc claims today that the Cray-1's speed was 160 megaflops (not MIPS). http://www.cray.com/about_cray/history.html
- Now I have nrver read of seen any banchmarks for the Cray-1 giving speeds in MIPS and Cray inc. claims it's speed was 160 megaflops, and this artical says 160 MIPS so I think maybe the acronym MIPS was used by accident and ether MFLOPS or megaflops should of bin used instead. Using MIPS may confuse people in to thinking that MIPS and MFLOPS (or megaflops) mean the samething.
- But the article is quite clear on the difference: the theoretical performance was 2 instructions at 80 MHz which is 160 million instructions, or MIPS. Floating point operations were not one-cycle, nor could they be dispatched on any cycle, so the FP performance was slower, the 136 MFLOPs number. I don't know where the 80 MFLOPs number came from, it's wrong and I'm removing it. Maury 21:39, 28 November 2006 (UTC)
- You say, "Floating point operations were not one-cycle, nor could they be dispatched on any cycle, so the FP performance was slower...." Oh yeah??? That was the whole point of Cray's pipelined vector processors. They yielded a result every clock cycle. Why don't you stick to changing stuff you actually know about or understand! Just because idiots designed the junk from the Intel 4004 family that is in your PC doesn't mean that all computer architects are idiots!!! Doesn't anyone review changes that people make in Wikipedia anymore??? —Preceding unsigned comment added by 98.212.132.146 (talk) 15:48, 12 December 2010 (UTC)
- @98.212.132.146: I think you missed my point. The Cray had vector startup overhead, albeit much shorter than the STAR. That overhead means that single units could not retire one instruction per cycle, on average. But don't take my word for it, take Crays - look at Table III of their report on the machine. Note that a single FP multiply takes 60 clock cycles, and at 10,000 elements you're down to 3.7. That means overall performance will be significantly slower than the potential peak. Do you have a source from Cray that says otherwise? Maury Markowitz (talk) 02:57, 8 December 2017 (UTC)
OS history
Another topic which needs real elaboration is the history of the first planned operating system for the Cray-1 at LANL. This was supposed to be Deimos. An academic paper was written about Deimos, but apparently the message-passing and its Unix-like favor for years put the fear of God in anything smelling like UNIX at LASL (later LANL) and LLL (later LLNL). Why this was and what happened is a lesson for technologists.
--enm 26 April 2006 18:30 GMT
comparison to 2006 ipod shuffle
Gjvo: That's really interesting. Can you provide more details? Mmernex 17:38, 22 May 2007 (UTC)
Comparison with modern pc prosessors
http://www.tomshardware.com/2007/07/16/cpu_charts_2007/page36.html i think the second table shows relevant Mflops?--Teveten 07:07, 3 October 2007 (UTC)
History
The first sentence of the history states:
- In the early 1974 Cray was working at Control Data on a new machine known as the CDC 8600, the logical successor to his earlier CDC 6600 and CDC 7600 designs.
I think that in [1974]] Cray was working at Cray Research and not at Control Data. Later the history states:
- In 1972 the 8600 had reached a dead end.
and a little bit later (without stating a date):
- Cray left.
The article about the CDC 8600 states that:
- In 1972 Cray decided that he couldn't work under such conditions, and left CDC to form Cray Research.
The article about Cray Research states that:
- Cray Research, Inc. (CRI), was founded in 1972 by computer designer Seymour Cray.
So I guess the history should begin with:
- In the years 1968 to 1972 Cray was working at Control Data on a new machine known as the CDC 8600, the logical successor to his earlier CDC 6600 and CDC 7600 designs.
since the article about CDC 8600 states that:
- Development started in 1968
Therefore I will do the change. Glass Tomato 08:47, 2 November 2007 (UTC)
Background notes (STAR)
From the article,
- ... something that might have been obvious had the designers considered Amdahl's Law.
Implying that the designers simply failed to take into account Amdahl's law is a vast over-simplification of the underlying causes of disappointing real-world performance. Amdahl's law is a simple back-of-the-envelope calculation that any idiot can do. I think the STAR's problem may have been an inaccurate estimate of typical workloads. It is all to easy to come up with corner cases that would show a huge speedup with vector processing that are not likely to be found in the real world. For good examples of such toy problems, refer to just about every microbenchmark ever written.
And it's probably likely that any advertised speedups came from inflated or misinterpreted claims spewed by the marketing department of the company, not directly from the designers themselves.
In any case, the claim that the designers were able to engineer a complex piece of technology without understanding one of the simplest principles of parallel programming is laughable. —Preceding unsigned comment added by 24.136.36.147 (talk) 11:43, 9 January 2008 (UTC)
- How is the Amdahl's Law argument different today than it was in regard to the STAR-100? If forecasting the efficacy of computing architectures were that simple, it would have been obvious that none of the fine-grained parallel processors in the Top500.org list should have been built, and they wouldn't have.
- Furthermore, it seems obvious that whoever made the original criticism has never worked in teams or committees on large engineering projects. Inertia and conformance to human social systems are paramount. No one can tell the king he has no clothes and survive. Cray got the (very small) "A Team" in Chippewa. The entire rest of the thousands of employees at CDC were emotionally and financially invested in producing "their" machine. Cognitive dissonance set in. Recall that the main reason they were building the STAR was that someone had published that the content of all the phonebooks (the spy's convenient cryptographic table of the time) in the US could be loaded into the STAR's virtual memory. Someone behind the "black curtain" thought that was important. Introduce the "spooky" need-to-know behavior into the company, and soon it becomes the dominant behavior in the corporate culture. There was no way that most people could find out how the STAR was actually intended to work, let alone how that would map onto commercial computing mixes. There is no evidence that the commercial market was the target market, anyway. The world, and especially the world of the US govt. behind the scenes, is more complicated than you imagine. It's amazing, nay miraculous, that Seymour was able to accomplish what he did while interacting with that theatre of operations.
- Let's remove the impertinent "Amdahl's Law" remark. 98.212.138.123 (talk) 19:56, 24 December 2010 (UTC)
- I spoke with Neil Lincoln, the final architect of the STAR-100, shortly after it was completed. It turns out the original design team FORGOT to design in a way for I/O to put data in/out of memory. They relied on an old concept which had always worked before called "cycle-stealing," wherein the buffered I/O uses "background" memory cycles which are unused by the CPU. Unfortunately in a vector-processing memory-to-memory architecture, there ARE NO MEMORY CYCLES UNUSED during a vector operation. Hence there had to be a whole redesign after-the-fact with kludges inserted into the completed hardware just so the STAR could do I/O. Don't tell me that the same people responsible for that fiasco couldn't have overlooked Amdahl's Law! They were the "B" team; Cray had the "A" team. The company gave these B-team Bozos a significant chunk of Cray's funding which was intended to be used in the 8600 development project, too. It should be obvious why Seymour left CDC. It had begun to die the death of all bloated bureaucracies, and it finished dying shortly after Cray left. 98.212.132.146 (talk) 16:09, 12 December 2010 (UTC)
