"You need a little bit of logic... and programmer here and there"
--
"So, let me tell you a little bit, a few of the problems, that ah, and the solutions that I see in building large computers.
First of all... I think that building large computers should be done with the fewest possible people.
One is perfect, but you can't quite work with one.
So.. the next best thing is about 12."
"The reason you need 12 is you kind of need one person from each of the disciplines that are necessary.
You need a mechanical engineer to build the box that it'll go in.
You need an electrical engineer to put the circuit together.
You need a little bit of logic... and programmer here and there
And you need a secretary of course.
But not very many."
Cray had a funny quote on the virtues of fast CPUs over parallelism "If you were plowing a field, which would you rather use? Two strong oxen or 1024 chickens?". Of course history has shown tjat the "chickens" was the strategy the field went with.
This is only half of it. There is a limit of how strong an ox can be, and, at some point (on the way to the Cray 3) Seymour hit it. That limit is pretty close to how strong a chicken can be, and we just got breed chicken that are as strong as Seynmour's best oxen - which got us to a problem: the only way forward was with lots of ox-sized supechicken.
Someone should make that imagery into an educational video.
The 6600, and no doubt Watson was lectured on it, was an extremely specialised machine - it had 60 bit words and that was it. No bytes, shorts, or anything similar. It was designed for floating point math. IBM had machines for science and business that were entirely different and incompatible prior to the 360.
It's very normal to slow down new model releases so they don't cannibalize too much of the sales of previous established lines. CDC was a very lean company, while IBM had a lot of different lines to protect from their own disruption.
It's always an important thing to remember it's better to develop the product that will kill your cash cow, because someone will, and you don't want it to be your competition.
Excuse me? No character addressability? The scientific machines IBM was selling in 1963, the 704x/709x, were 36-bit-word-addressible. The 6600 was definitely similar to those, in many ways. And you didn't need character addressibility for business applications, there were Cobol compilers for those machines. The stranger feature of the 6600 was the division between the central processor and the peripheral processors; if the 360 had been designed that way, much of the operating system would have been running in the channels, or in the smaller computers then used for offline punchcard/printer support.
A much greater omission was IBM's refusal to consider time-sharing, until it was too late, and then they made a total mess of it with TSS/360. (The 360/67 was a good machine, I have fond memories of it, but it needed a different OS, Michigan Terminal System in our case.) It took IBM a long time to understand the need for interactive computing.
The IBM 704, 7090 were computers targeted at the science market, being (some of?) the first with floating point hardware. Their “business” counterparts would be the 705, 1401 and did decimal math and string processing. You could run business apps on both, but manipulating strings in them is a kludge because you either pack a character as a word or you need pointers within pointers. With 36-bit words, at least, you can have a character pointer turn into an address by two bitshifts.
Oh, and there was a Cobol compiler for the 6600. (Wirth's first Pascal implementation was also for the 6600, as I recall.) My point is that the central processor architecture of the 6600, apart from the large word size, was entirely consistent with the way that scientific computers from IBM, Univac, Philco, General Electric, and other manufacturers were designed.
As for time-sharing,IBM explicitly ruled it out as a design objective for OS/360. Then MIT went shopping for a partner for Multics. IBM had nothing of interest for them, but GE agreed to design a virtual memory version of their 635, the 645. Suddenly, IBM realized that they were going to lose a market, so they rapidly added memory mapping to the 360/65, producing the Model 67. They also announced Time Sharing System/360, but the early versions were unusable (20 minutes to log in, for example), so a few folks at the University of Michigan whipped up an interim solution, the Michigan Terminal System, which worked fine, and was in service at various places from 1968 to the 1990s.
Although IBM produced various time-sharing systems, including Call/360, APL\360, the Time Sharing Option, and VM/CMS, they never really understood it, which is why a few underfunded folks at a university could produce something better than what they could produce with a professionally-managed team.
By contrast, DEC did get it in that era, which is why the PDP-10 did so well in university computer science departments.
It also was built with discrete transistors - no ICs in it at all. My first programming class at Purdue used the CDC6500 & 6600 with punch cards. Purdue's old 6500 is now in a museum in Seattle.
Due to CDC 6600, IBM lost almost completely the market for what today would be called high-performance computing, which was then dominated for 3 decades by CDC and then by Cray, after Seymour Cray left CDC.
However, during that time the market for lower-cost and acceptable performance computers was expanding very quickly, so IBM had growing revenues and profits, without being affected by the loss of a smaller market.
They were more strongly affected by the ascension of DEC, as the main vendor of minicomputers, which took the lower end of the market from IBM, but the medium-performance market, especially for business data processing, where the greatest profits were achievable, remained dominated by IBM, so they had little to worry about.
There's a dead comment in this thread by the fabled Don Hopkins, and the only reason I can imagine is that he commented, factually but negatively, on Elon Musk. Shameful comment-killing, just shameful.
I believe a lot of people on HN consider trans people rights something controversial and worth censoring.
As for Elon, I will call the website Twitter, because if he can deadname his daughter, I can deadname his companies as well.
After the acquisition of Twitter, a large number of talented people walked away, a lot because of his attitude towards work-life balance, and, I assume, later, as his darkest side became more and more public (culminating in Trump's inauguration Dr. Strangelove event), a lot of the remaining talent left for healthier pastures. That period was full of outages and data loss.
On @DonHopkins, I love his "FORTH ?KNOW IF HONK ELSE FORTH LEARN THEN"
I used CDC computers 1986-92. They sucked, and CDC employees could not comprehend that they sucked. They had convinced themselves that their alternate universe was real.
One can even argue that occurred by the early 70s. A set of incompatible, non modern platforms, with the best of those optimal for batch Fortran number crunching, counter to industry growth. Organizational metastasis with agreement on a next gen platform (Cyber 180 as Star was stillborn) only by the end of the decade. Standards, coupled with profound organizational incompetence, ground it to dust by that point. They made really good OEM disk drives for a while but sold the unit off to fund their continuing failures.
There really needs to be a book that’s not an encomium to William Norris.
The 180/990 and the 205 were a pretty good FORTRAN vector machines if that was the problem you wanted to solve; the compiler was quite good. The other 170/180s were...for everything else...not so much. That boat had sailed.
The college I was at in the late 70s had a CDC 6600 which I learned FORTRAN. With around 100+ sold, I wonder if that was donated to the school from a company that upgraded their system ? While still at school it was replaced by a CDC 7600.
To me, the system ran very well.
Sad to see all those computer companies disappear over the years, I think there may be only 3 or 4 left making big iron.
I might have gone to the same college, in the 80s. I was a TA helping students punch FORTRAN on cards - already pretty obsolescent.
One thing about the CDC - it had perhaps the worst command interface I've run into. Data files were modeled as tapes, and you had to keep rewinding them.
Compiling a program appended to the object file, but running ran the start of the file, so you needed to rewind between, lest you run an old version. Much time lost trying to figure out why changes were ineffective.
FORTRAN variables had 8 significant characters, but the linker had only seven, so it was possible to get unintentional aliases.
University of Arizona? I remember their antediluvian Cyber in 1984 and helping my roommates punch Fortran on cards. I at least got to use a VAX 11/750.
The term RISC was coined more than 15 years later, and the first RISC CPU, i.e. IBM 801, was designed several years before the introducing of the term "RISC".
IBM 801 deserves to be called the first RISC machine, because its design methodology had the explicit goal of achieving a greater performance than IBM 370, by simplifying its instruction set.
CDC 6600 was not created by the simplification of an earlier architecture. It was more complex than the previous very simple CDC computers.
Nonetheless, it was designed to achieve the maximum performance permitted by the available technology and both James E. Thornton and Seymour Cray were extremely competent computer designers, so many of their design decisions coincide with those that were also preferred many years later for the RISC CPUs.
True, but a lot of resources are still wasted in the instruction cache and instruction decoder, with 2 instructions instead of 1.
Any superscalar CPU has limits on the number of instructions that can be fetched, decoded, renamed and dispatched and having 2 instructions instead of 1 for each load and store in an array processing loop can exceed any of those limits and slow down the execution, even when there are enough ALU/AGU execution units available.
"population count" is often associated with hamming distance with uses in information theory, coding theory, and cryptography. There is another use, which I think is what it was really used for - cosine similarity.
The usual definition for two vectors A and B is A.B = |A||B|cos ø. If A and B are binary it becomes, A and B = popcnt(A)popcnt(B)cos ø. The similarity measure is how close cos ø is to 1.
Using modern vocabulary, with a message and a set of search criteria using a word embedding on the message, calculate the similarity to each search using, cos ø = (A and B)/(popcnt A * popcnt B). This is only be vectorizable when there is an intrinsic popcnt instruction. Results that have > 0 values for cos ø mean there is some similarity.
So, to capture, (re)scan and flag all messages that contain certain keywords, design a system to generate a KEYSCORE. When eXtended to reduce false positives, build a follow on system called XKEYSCORE.
The last paragraph is pure speculation, but I think it has merit. Worth a try on your own data?
The most striking thing to me about IBM memos from this era is just how literate executives were. These days most VPs struggle to write a single sentence worth reading.
Many people from that era were well read and well spoken. He in particular sounded like he had some interesting life experiences: air force pilot, ambassador to the Soviet Union, president of the Boy Scouts, etc.
They also had secretaries (even more-so at the executive level) who would proof-read the letter and return it to the boss for their revision and/or signature. Contrast that with today where it's easy for someone to click send and off it goes, incomplete thoughts and grammar errors and all.
If you want to improve your communications - when you finish writing your email, leave it as a draft for 30-40 minutes. Then go back an re-read it with a fresh viewpoint.
If I can suggest - the USAF has a manual for this, which guides you in being clear, concise, and specific:
I worked for a government entity and was involved in a lawsuit based on a very old, not-IBM mainframe contract that was solicited before I was born and amended like 30 times.
The memos and letters in those files were both amazing and depressing, as when you fast forwarded from the late 70s to circa 2010, the writing quality steadily declined.
Related? I have several sets of old encyclopedias, Collier's from the 40's and World books from the 60's and 80's. It is very noticeable how much better the older articles are written.
And weird errata, while looking for an example the Wikipedia article on Collier's claims they started in 1949 while my copies have copyrights 1932 - 1944 so were probably printed 1944/45.
Classic example of a small very motivated team with free reigns vs committee development at IBM. The irony is that less than 20 years later IBM would do the same thing and it lead to the IBM PC.
Did IBM consider the PC a successful product? Especially over time it's eaten their bread and butter mainframe market and they pulled out of the end user computing to Lenovo. On the flip side if they didn't do it, others were already trying.
At least for a couple of years it was a massive success. If they had not done the PC somebody else would have become the PC I think so they were damned if they did and damned if they did not.
> To achieve a profit for the ACS program, Amdahl asked IBM management to approve three ACS/360 models: the high-performance design, a 1/3 performance version, and a 1/9 performance version. He felt that these performance goals would be a good fit with the System 360 marketing plans. He remembers that IBM Corporate Marketing evaluated the targets and reported: "1) the supercomputer alone was a loss leader! 2) the supercomputer plus the 1/3 performance computer was break-even! And 3) the supercomputer plus both the 1/3 performance computer and the 1/9 performance computer was normal profit -- 30% pre-tax!"
> Gene Amdahl interview in April-June 1997, IEEE Design and Test of Computers: "The company decided not to build it because it would have destroyed the pricing structures. In the first place, it would have forced them to make higher-end machines. But with IBM's pricing structure, the market disappeared by the time performance got to a certain level. Any machine above that in performance or price could only lose money."
> In his autobiography, Father, Son, & Co., Tom Watson, Jr., writes about the Model 90 series in competition with CDC and his decision to cancel their sales (Bantam Books, 1990, page 384): "Finally my business sense overcame my pride and I belatedly figured out that we couldn't compete with Control Data for the same reason that General Motors can't compete with Ferrari in building two-hundred-mile-an-hour sports cars. Supercomputers had become so highly specialized that even if we came up with a design equal to theirs, it would never fit in with the rest of our product line, our style of selling, our volume and profit targets, and so on." He goes on to say that his "temper was partly to blame for IBM's erratic behavior in the supercomputer market".
45 comments
[ 2.8 ms ] story [ 35.8 ms ] threadI never imagined he’d be caught by that mistake.
https://en.wikipedia.org/wiki/CDC_6600
--
"So, let me tell you a little bit, a few of the problems, that ah, and the solutions that I see in building large computers. First of all... I think that building large computers should be done with the fewest possible people. One is perfect, but you can't quite work with one. So.. the next best thing is about 12."
"The reason you need 12 is you kind of need one person from each of the disciplines that are necessary. You need a mechanical engineer to build the box that it'll go in. You need an electrical engineer to put the circuit together. You need a little bit of logic... and programmer here and there And you need a secretary of course. But not very many."
https://managingdesignanddevelopment.blogspot.com/2022/09
Someone should make that imagery into an educational video.
It's always an important thing to remember it's better to develop the product that will kill your cash cow, because someone will, and you don't want it to be your competition.
A much greater omission was IBM's refusal to consider time-sharing, until it was too late, and then they made a total mess of it with TSS/360. (The 360/67 was a good machine, I have fond memories of it, but it needed a different OS, Michigan Terminal System in our case.) It took IBM a long time to understand the need for interactive computing.
As for time-sharing,IBM explicitly ruled it out as a design objective for OS/360. Then MIT went shopping for a partner for Multics. IBM had nothing of interest for them, but GE agreed to design a virtual memory version of their 635, the 645. Suddenly, IBM realized that they were going to lose a market, so they rapidly added memory mapping to the 360/65, producing the Model 67. They also announced Time Sharing System/360, but the early versions were unusable (20 minutes to log in, for example), so a few folks at the University of Michigan whipped up an interim solution, the Michigan Terminal System, which worked fine, and was in service at various places from 1968 to the 1990s.
Although IBM produced various time-sharing systems, including Call/360, APL\360, the Time Sharing Option, and VM/CMS, they never really understood it, which is why a few underfunded folks at a university could produce something better than what they could produce with a professionally-managed team.
By contrast, DEC did get it in that era, which is why the PDP-10 did so well in university computer science departments.
However, during that time the market for lower-cost and acceptable performance computers was expanding very quickly, so IBM had growing revenues and profits, without being affected by the loss of a smaller market.
They were more strongly affected by the ascension of DEC, as the main vendor of minicomputers, which took the lower end of the market from IBM, but the medium-performance market, especially for business data processing, where the greatest profits were achievable, remained dominated by IBM, so they had little to worry about.
As for Elon, I will call the website Twitter, because if he can deadname his daughter, I can deadname his companies as well.
After the acquisition of Twitter, a large number of talented people walked away, a lot because of his attitude towards work-life balance, and, I assume, later, as his darkest side became more and more public (culminating in Trump's inauguration Dr. Strangelove event), a lot of the remaining talent left for healthier pastures. That period was full of outages and data loss.
On @DonHopkins, I love his "FORTH ?KNOW IF HONK ELSE FORTH LEARN THEN"
There really needs to be a book that’s not an encomium to William Norris.
The 180/990 and the 205 were a pretty good FORTRAN vector machines if that was the problem you wanted to solve; the compiler was quite good. The other 170/180s were...for everything else...not so much. That boat had sailed.
To me, the system ran very well.
Sad to see all those computer companies disappear over the years, I think there may be only 3 or 4 left making big iron.
One thing about the CDC - it had perhaps the worst command interface I've run into. Data files were modeled as tapes, and you had to keep rewinding them.
Compiling a program appended to the object file, but running ran the start of the file, so you needed to rewind between, lest you run an old version. Much time lost trying to figure out why changes were ineffective.
FORTRAN variables had 8 significant characters, but the linker had only seven, so it was possible to get unintentional aliases.
As a grad student, I got to use a VAX.
IBM 801 deserves to be called the first RISC machine, because its design methodology had the explicit goal of achieving a greater performance than IBM 370, by simplifying its instruction set.
CDC 6600 was not created by the simplification of an earlier architecture. It was more complex than the previous very simple CDC computers.
Nonetheless, it was designed to achieve the maximum performance permitted by the available technology and both James E. Thornton and Seymour Cray were extremely competent computer designers, so many of their design decisions coincide with those that were also preferred many years later for the RISC CPUs.
But when superscalar came around, such a RISC can execute the address update instruction concurrently with the memory access instruction.
Any superscalar CPU has limits on the number of instructions that can be fetched, decoded, renamed and dispatched and having 2 instructions instead of 1 for each load and store in an array processing loop can exceed any of those limits and slow down the execution, even when there are enough ALU/AGU execution units available.
The usual definition for two vectors A and B is A.B = |A||B|cos ø. If A and B are binary it becomes, A and B = popcnt(A)popcnt(B)cos ø. The similarity measure is how close cos ø is to 1.
Using modern vocabulary, with a message and a set of search criteria using a word embedding on the message, calculate the similarity to each search using, cos ø = (A and B)/(popcnt A * popcnt B). This is only be vectorizable when there is an intrinsic popcnt instruction. Results that have > 0 values for cos ø mean there is some similarity.
So, to capture, (re)scan and flag all messages that contain certain keywords, design a system to generate a KEYSCORE. When eXtended to reduce false positives, build a follow on system called XKEYSCORE.
The last paragraph is pure speculation, but I think it has merit. Worth a try on your own data?
If you want to improve your communications - when you finish writing your email, leave it as a draft for 30-40 minutes. Then go back an re-read it with a fresh viewpoint.
If I can suggest - the USAF has a manual for this, which guides you in being clear, concise, and specific:
https://static.e-publishing.af.mil/production/1/saf_aa/publi...
The memos and letters in those files were both amazing and depressing, as when you fast forwarded from the late 70s to circa 2010, the writing quality steadily declined.
Here is an example from 1921, https://archive.org/details/colliersnewencyc01newy/page/40/m...
And weird errata, while looking for an example the Wikipedia article on Collier's claims they started in 1949 while my copies have copyrights 1932 - 1944 so were probably printed 1944/45.
> To achieve a profit for the ACS program, Amdahl asked IBM management to approve three ACS/360 models: the high-performance design, a 1/3 performance version, and a 1/9 performance version. He felt that these performance goals would be a good fit with the System 360 marketing plans. He remembers that IBM Corporate Marketing evaluated the targets and reported: "1) the supercomputer alone was a loss leader! 2) the supercomputer plus the 1/3 performance computer was break-even! And 3) the supercomputer plus both the 1/3 performance computer and the 1/9 performance computer was normal profit -- 30% pre-tax!"
> Gene Amdahl interview in April-June 1997, IEEE Design and Test of Computers: "The company decided not to build it because it would have destroyed the pricing structures. In the first place, it would have forced them to make higher-end machines. But with IBM's pricing structure, the market disappeared by the time performance got to a certain level. Any machine above that in performance or price could only lose money."
> In his autobiography, Father, Son, & Co., Tom Watson, Jr., writes about the Model 90 series in competition with CDC and his decision to cancel their sales (Bantam Books, 1990, page 384): "Finally my business sense overcame my pride and I belatedly figured out that we couldn't compete with Control Data for the same reason that General Motors can't compete with Ferrari in building two-hundred-mile-an-hour sports cars. Supercomputers had become so highly specialized that even if we came up with a design equal to theirs, it would never fit in with the rest of our product line, our style of selling, our volume and profit targets, and so on." He goes on to say that his "temper was partly to blame for IBM's erratic behavior in the supercomputer market".
[1] https://people.computing.clemson.edu/~mark/acs_end.html