Slashdot Mirror
IBM Mainframe Running World's Fastest Commercial Processor
dcblogs writes "IBM's new mainframe includes a 5.5-GHz processor, which may be the world's fastest commercial processor, say analysts. This new system, the zEnterprise EC12, can also support more than 6-TB of flash memory to help speed data processing. The latest chip has six cores, up from four in the prior generation two years ago. But Jeff Frey, the CTO of the System Z platform, says they aren't trading off single-thread performance in the mainframe with the additional cores. There are still many customers who have applications that execute processes serially, such as batch applications, he said. This latest chip was produced at 32 nanometers, versus 45 nanometers in the earlier system. This smaller size allows more cache on the chip, in this case 33% more Level-2 cache. The system has doubled the L3 and L4 cache over the prior generation."
There are some engineering tricks I've seen IBM use which are pretty cool. Take the POWER7 CPU line for example. You can disable every other core, allowing the cores that are operational use the cache of the cores that are not on. This gives not just cache, but allows a higher clock speed. Of course, this feature is mainly used to deal with applications which are licensed by the hardware cores present.
Mainframes are probably one of the most underutilized tools out there. However, for performance per square foot in the data center, they are hard to beat these days.
Of course, the biggest advantage: It isn't x86. With virtually everything running on the x86 or amd64 platform, all it would take is an undocumented instruction similar to the F0 0F bug that happens to give ring 0 access, and virtually the whole world is vulnerable with absolutely zero way of protecting against it except reaching for the network cable or power switch.
No, that's not a correct supposition -- quite the opposite, actually. All processors, including Intel X86, use microcode (or what IBM calls millicode) to a degree. IBM knows it well. After all, they invented microcode/millicode in the System/360 in 1965. But IBM uses microcode comparatively less nowadays than other processor architectures. The vast majority of zEC12 instructions are implemented entirely in hardware, including IEEE-754-2008 decimal floating point as an example. There's some really, really interesting new stuff in the instruction set, like the first transactional memory ("transaction execution facility") instructions in a commercial server, and some "feedback" instructions that can tell Java applications/the JVM how to dynamically tune itself in a live running environment. Very cutting edge -- so cutting edge I've got to crack open some engineering manuals to try to figure out what they've done, although they probably need to write those manuals.
Yes, you could do that. Multiple images, actually. And that's basically what these servers do automatically. There are 4 levels of cache, main memory (which is RAID-protected actually, called RAIM -- only IBM does that), and there's another optional level of directly processor-addressable memory called Flash Express which is nonvolatile -- that's new, too. It works particularly well for fast paging, in-memory databases, memory dumps, etc. Then you go into fiber-attached and heavily cached solid state disk, fast disk, nearline disk, tape libraries. There are a lot of storage layers, and they're all very big.
I'm quite sure that for the applications people actually use mainframes for, you're utterly wrong.
Not only do they scale massively higher in terms of throughput, they also manage to do it with obscene uptimes (measured in years) and reliability nothing can compare to.
For certain kinds of applications, what you say is largely true. But at the huge end for things like banking, financial transactions, and airline reservations ... there's really no comparison.
I've worked on projects trying to do exactly this. And I've seen a couple of them fail.
Trying to map out all of the use cases for software which is mission critical and has been around since the 60's can actually prove to be exceedingly challenging if not impossible.
I'm just not convinced that for the kinds of applications and environments where people will run mainframes that what you suggest would give the same performance or scalability as a big giant mainframe. There just seems to be something missing from that picture, and to me it's the sheer volume of stuff these things handle. Certainly not even in the same category as what you call a midrange desktop.
Lost at C:>. Found at C.