Shmuel Metz writes: >S/370? Multiprocessing on mainframes goes back at least to the >late 1950's, and was common even before the S/360 was announced. >Bendix, Burroughs, General Electric and UNIVAC come to mind, but >there were no doubt others. What were they smoking?
In fairness, I don't think they (the original poster's foil) were talking about multiprocessing in the multitasking sense (sharing one CPU). I think they were talking about hardware designs, specifically Symmetric Multiprocessing (SMP) hardware designs. At least, that's what the mention of two 80386 CPUs on the same motherboard suggests. And it's a little tough to pin down when SMP began, because engineers are going to quibble about the definition and exact characteristics that qualify. However, some notable systems include a version of the System/360 Model 65 (with dual processors -- I've seen this referred to as the "M65MP"), and this option carried into the Model 67. The Model 65 started shipping in November, 1965, although I'm not sure exactly when the M65MP variant shipped, and I don't know much about it. Probably not much later, if at all, since the Model 67 shipped in August, 1966. But for the vast majority of customers dual (or more) CPUs in a single machine weren't typical until System/370. The M65MP wasn't first, though. The Burroughs D825, a military computer [a.k.a. the Naval Research Laboratory's AN/GYK-3(V)], gets a lot of recognition as the first (hardware) multiprocessing computer, and this machine started shipping in August, 1962, and was operational in November that year. (UNIVAC LARCs had some design provision for multi-CPUs but never shipped that way.) The D825 could have up to 4 CPUs, and there was a crossbar switch to queue memory requests to the shared memory modules (up to 16). The operating system, AOSP (Automatic Operating and Scheduling Program), allowed a program to have multiple processes executing in parallel on the separate CPUs. [Reference here: http://www.cc.gatech.edu/gvu/people/randy.carpenter/folklore/v3n1.html] All the above was way, way before my time. Before my parents met, etc. Hopefully someone else can fill in the details for those curious. I think it's fair to note that nothing has really changed in all those years about the utility of multi-CPU (now even multi-core) designs. The software elements are still critical, and in some sense SMP concedes defeat when you're out of engineering tricks to make a single core run faster. For example, if you have 4 CPUs each rated at 2 MIPS, that's not going to be as business-attractive as a single CPU running at 8 MIPS, ceteris paribus. (The former machine can never run a single task any faster than 2 MIPS, and sometimes you're just plain single task bound.) I guess there's a slight argument that hardware separation of tasks might be useful when other design elements (such as interrupt processing and operating system support for multiprocessing) are weak. Very slight, perhaps vanishingly so, especially nowadays and in the context of PR/SM. Underlying physical hardware separation is now used for things like zAAPs, zIIPs, and IFLs (i.e. for licensing reasons). Fast forward to 2009. Sun, in particular, talks about how wonderful it is they've got a single CPU die with higher core counts. Well, of course: they had to move in that direction earlier than other vendors because SPARC hit a wall long ago. Adding all those cores is only partial compensation, and increasingly less and less compensation. An UltraSPARC T2 CPU chip, for example, has 8 cores but each maxes out at 1.4 GHz. As another example, have you noticed that the Intel CPU inside your PC (or Mac) has been stuck on 2.x GHz (or occasionally 3.x in a desktop) for a long, long time now -- and that now Intel is pushing quad-core CPUs down into even notebook computers? That's more evidence of reaching that brick wall. Every CPU vendor is struggling with that, but some reached the wall earlier (and harder) than others. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Based in Tokyo, Serving IBM Japan / Asia-Pacific E-Mail: [email protected] ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
