Here is more on the IBM z Systems mainframes. The z16 is the first to use IBM’s Telum processor, which includes on-chip support for artificial intelligence inferencing, 8 cores per chip, each with 32 megabytes of cache per core and the ability to dynamically share cache among cores, effectively creating a virtual memory system for cache. Clock speed for the water-cooled multi-frame systems is 5.2 Ghz, and unlike typical desktop and workstation processors, can run all day with all cores running at this maximum rate with no thermal throttling down.
Virtual memory? As in virtual and physical addresses, MMUs (CMUs?), TLBs, translation tables and all that stuff?
When I hear “share caches among cores”, I think of something more akin to NUMA than VM. Alas, I’m unlikely ever to understand how any of it really works.
This long-time unixhead has been inexplicably curious about IBM’s biggest iron for a number of years, going so far as to partake of more than one of their annual introductory Master the Mainframe programs.
But there’s a huge confounding disconnect for me. On the one hand, the 360/370/390/zXX machines are amazingly advanced, or were amazingly advanced when they were new, IBM having started virtualizing operating systems what-?, like 40 or 50 years ago? OTOH, many of the primary terminal user interfaces (ISPF, TSO, JCL) and transaction-processing systems seem like they haven’t changed much since their birth back in the computing technology stone age.
I know there’s much more to zXX than that, but it’s weird to me (and amazing!) that so much of the world’s commerce still runs on machines whose 40-50 year old roots are still front and center.
“Virtual memory for cache” is IBM’s terminology for what they’re doing. It doesn’t work in the same manner as virtual main memory backed by slower secondary storage, but the principle is the same: make it appear, transparently to the processor, that it has a larger amount of local, fast memory by backing up the physical memory with secondary storage allocated on demand as programs run. In this case, instead of main memory and peripheral mass storage, they’re transparently expanding the amount of Level 2 (L2) cache available to a processor core by allowing it to use the cache belonging to other cores, albeit running at a speed comparable to Level 3 (L3) cache. Whether this will confer any benefit depends strongly upon the mix of jobs run on the mainframe. If it includes those that use relatively little cache and others that will run faster with more cache, even if slower, it’s a win. The first round of virtual memory was, in general, less beneficial to real-world workloads than the professors who invented it imagined it would be. We’ll have to see how well this works on the workloads people are really running on IBM mainframes (about which I assume IBM knows a lot more than I).
But, wait—most of the world’s other computing workloads run on the Intel x86 architecture, whose roots trace back to the Datapoint 2200, whose instruction set was invented by my college classmate Harry Pyle in the late 1960s, (The first Datapoint 2200 was delivered in May, 1970.) Intel couldn’t build a single chip processor with the required performance, so Computer Terminal Corporation (later Datapoint) built their own serial CPU from TTL medium-scale-integrated circuits, and only later did Intel implement a variant of the instruction set in their 8008 and 8080 processors, going on to extend it in the 8086 and thence (regrettably) to the present day.
In any case, the roots of our most common “software stack”: the x86 instruction set, C language, Unix-like operating system, etc. are only a few years younger than than the IBM 360/370/etc. architecture.
But, at some point, it doesn’t matter so much how old or new it is, but how compatible it is with what has gone before, permitting customers to preserve their investment in software and systems that run on the platform. When I worked with Univac mainframes, this was almost an article of faith: a program I developed in the early 1970s and last built around 1978 continued to run without modification on Univac and the successor Unisys mainframes to the present day, on Unisys ClearPath Dorado systems. This was so strong an imperative that during the formation of Autodesk, Inc. I penned a paragraph in “Information Letter #1” about “Terminating products”, because our founders, steeped in Univac heritage, assumed that “products are forever”.
Terminating Products
Some people have expressed concern about the continuing support burden of products we decide to terminate because of bad sales. This is a non-issue. When a product is terminated, support of it is terminated and those who inquire are simply told “that product is discontinued”. Only in the computer business does the insane idea that by buying a $300 product (or, for heaven’s sake, a $35 product) entitle the purchaser to all products of the implementor’s mind unto eternity and unlimited free consultation at the press of a touchtone button. If you buy a refrigerator, you don’t expect to get a new one every 6 months because a new model comes out, and the same thing holds here. We warrant the product will agree with the manual and will work for, say, 6 months after purchase. When that expires, our connection with that product is totally severed. We may choose to offer existing customers a good deal on new versions, but that is a marketing tactic, not a moral imperative! If we find the mass market we seek, we can’t afford to talk to one in a hundred end users. We have to make the software work in such a way, supported by the manuals, that users can use the package on their own, and provide the aids to those who distribute the software so that they can answer user questions locally. This isn’t impossible: numerous products meeting this criterion sell well currently. So, when we terminate a product, it’s done.
This was seen by some founders as heretical, if not overtly diabolical.
That said, when your customers have made a huge investment in your products, pulling the rug out from under them may create the incentive they need to seriously ponder alternatives. The “cost of switching” or “technological hysteresis” may be negated when your vendor callously destroys their investment in its products.
One of the remarkable business stories of the four last decades is how Microsoft has managed to maintain their chokehold on their customer base despite the most callous and disregard and willful destruction of customers’ buy-in to their regrettable “platforms”.
