After its Meteoric Rise, CMOS Rocket Levels Off

For the mainframe, and the whole computer industry, it’s been a great ride on complementary metal-oxide semiconductor (CMOS) technology. We’ve enjoyed a yearly compound growth in single-engine speed of almost 30 percent since the introduction of the first IBM CMOS mainframe.

The IBM 9672 R11 was introduced in 1994 and rated at about 15 MIPS. Last year, IBM shipped the zEnterprise EC12 (zEC12) mainframe rated at about 1,500 MIPS. That’s a 100-fold increase over about 18 years. And perhaps it has spoiled us. For more than a decade, we have let these CMOS advances absorb a good deal of our increasing capacity demand. Figure 1 shows the rapid growth in CMOS processor capacity we’ve enjoyed over nearly two decades.

The CMOS capacity curve bends so strongly upward because of advances both in silicon chip technology and in processor design. The first IBM CMOS mainframe was a relatively low-frequency processor at its introduction, while the current zEC12 is probably the highest-frequency, commercially available, general-purpose processor at 5.5 GHz.

The CMOS mainframes also started with a relatively simple processor design and evolved into a sophisticated RISC-like processor, capable of very efficient execution of the rich and complex z/Architecture. Many of the improvements in processor design were actually a redeployment of design ideas that had been developed for the bipolar processors that preceded the CMOS-based systems. These include techniques like:

  • Superscalar parallelism
  • Advanced branch prediction
  • High-frequency pipelines, and
  • Out-of-order instruction execution

Some of these techniques have had further innovation, like more sophisticated branch-prediction algorithms. Also, practices have been introduced allowing a RISC-like instruction processor design despite z/Architecture being a complex instruction set architecture. One interesting technique that enabled this is called instruction “cracking,” whereby complex instructions are decomposed into simpler instructions so they can be efficiently executed on a very high-frequency processor. This combination of silicon technology improvements and design advances has led to the explosive growth in CMOS processing power, culminating with the zEC12 and its processor speed of more than 1,500 MIPS.

We’ve also experienced a phenomenal ramp-up of the number of processors in a box and the number of processors supported in a single z/OS image. We started the new century with the zSeries z900, which had what now is seen as a paltry maximum number of 16 processors. The mainframe platform had spent the previous two decades since the introduction of 370-XA climbing from the two processors of the 3081 to the 16 of the z900.

Then, IBM seriously turned its attention to increased levels of multiprocessing for z/OS after the introduction of the zSeries z990 in 2003. In 2004, the z/OS maximum was raised to 32 processors, and just three years later, that figure was doubled to 64 processors. Now, on the latest systems, the maximum number of processors supported in a z/OS image is nearly 100. Figure 2 shows the growth in the number of processors configurable on a single CMOS system. The number of processors supported in a single z/OS image has lagged a bit behind this, but basically follows the same curve.

As far as capacity increase is concerned, things have been great for quite a while. But, it looks like we’re going to run into a rough spot. The hardware engineers have told us that the CMOS speed-up is slowing down—probably to single-digit percent annual growth. The speed bump is a combination of physics problems with powering ever faster, ever-denser chips and exhausting the design ideas from the bipolar days. It’s not just a mainframe problem. It’s an industry-wide phenomenon.

This will put a huge pressure on the number of processors needed to grow the capacity of z/OS images as much as is needed for demanding new workloads. But, there are problems here, too. After almost a decade of full-court press on flattening multiprocessing overheads, the IBM engineers and programmers might be running short of ideas here, too.

Hiperdispatch might be the last great idea for reducing MP overhead, which isn’t linear, so things can go from bad to abysmal very quickly. The absence of gains from single-engine speed-up can easily lead into a rise in the required number of processors that results in a precipitous drop in MP efficiency, which leads to a need for even more processors, which further lowers efficiency, and so on. The results are not tenable. We can see already with the zEC12 that configuring the 100th processor contributes only half the effective capacity increase as adding the eighth one. Another approach is needed if we’re going to be able to continue to grow workloads.

In an upcoming article, we’ll look at just such an approach that can provide another dimension of capacity delivery to pick up the slack being left by diminished single-engine speed-up and the steepening resistance to increasing the number of processors in a single z/OS image.

Bob Rogers worked on mainframe system software for 43 years at IBM before retiring as a Distinguished Engineer in 2012.

comments powered by Disqus



2019 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Safely Concealed

IBM Identity Mixer is poised to change how Web users reveal personal data

Ups and Downs

IBM and Stanford University push spintronics to smaller levels

Computing in 3-D

Chips could gain depth to keep delivering on Moore’s Law

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters