Re: The Seymour Cray Era of Supercomputers

On Tue, 20 May 2025 19:59:48 +0000, John Levine wrote:

According to Michael S  <already5chosen@yahoo.com>:

At time of introduction CDC 6600 was undoubtedly much faster both than
older [more expensive] IBM 7030 and than contemporary [significantly
less expensive] S/360 Model 50. But it was not "orders of magnitude
faster". Not even one order of magnitude faster, except, may be, vs
Model 50 in artificial very memory-light floating-point intensive
scenarios.
High end S/360 (Model 65) came about half a year later. I would imagine
that for non-floating-point code it had about the same speed as 6600.

>
Those 360 models seem wrong.  The 360/50 was a midrange machine that
shipped in August 1965, the /65 was a large machine that shipped
in November 1964, and the 360/75 was a high end machine that
shipped in January 1966.  They were all announced at the same
time, give or take IBM's replacing the paper 60 and 70 with the
faster 65 and 75.
>
STRETCH was about 1.2 MIPS, the /50 was 0.133 scientific, 0.169
commercial,
the /65 was .563 and .567, and the /75 was .940 and .670, so only
the /75 was a plausible replacement.  The high end machine was the /91
which shipped late and over budget in Oct 1967 and was much faster,
1.9 MIPS scientific and 1.8 MIPS commercial.  (I think the 91's
actual commercial performance was much lower since it simulated
decimal arithmetic in software, but nobody ran RPG programs on
a /91.)
>
For concrete numbers a double precision floating point memory
to register add on the /50 took 9.7us, /65 took 2.5us, /75 took .92us
>
Floating multiply was 47us, 7.7us, 4.1us.
>
The numbers for the /91 depended on whether the operands were
available but if they were adds were 120ns, multiply 180ns.
>
The 6600 was reported to be three times faster than STRETCH which
would have been 3.6 MIPS, a lot faster than any 360 of the time
and well over an order of magnitude faster than the not particularly
fast 360/50.

CDC 6600 was a 100ns machine with about 3-cycle per instruction perf
overall. This corresponds rather well with John's statement above.

>
>