Java Grown Up with the System z10

If you read the newspaper articles and watch IBM executives speak on television about the new System z10, you will hear them use some interesting phrasing concerning performance: "...up to 100% faster for CPU-intensive applications."

That's a bold claim, but I think what's most interesting about the System z10 EC is that, for perhaps the first time, this machine is a mainframe-supercomputer. Its quad-core processor technology is state-of-the-art in every respect — not just in I/O performance and execution integrity, but in sheer number-crunching punch. The hardware decimal floating point support is one example, but another example is how Java and XML workloads behave on this machine compared to its predecessors, which were already quite good.

I guess it's no secret that Java simply requires more processing capacity than, say, compiled C/C++ or COBOL, ceteris paribus. That's true on any platform. Processor capacity is never free — except during off-peak hours :-) — but in the large scale enterprise systems world (i.e. mainframes) we care about how code scales, because we worry about supporting the largest number of users as economically as possible. So we keep COBOL, PL/I, C/C++, and other code — and create billions of new lines each year — in part because the code execution is efficient and has evolved with the organization's performance needs in mind.

Before I was born the great debate was between COBOL and Assembler. High level languages like COBOL were slow and inefficient but more portable, and Assembler was peppier but harder to learn and maintain. The high level languages mostly "won." However, when IBM created the System/360 architecture, Assembler got a boost because it was more portable, able to run on any bigger System/360 or any successor. A lot of that Assembler is still running, and a lot of people are still writing new Assembler.

Anyway, there's a similar debate concerning Java, although that debate is probably winding down now. IBM and other vendors keep incrementally improving Java technology, with progressively faster just-in-time compilers and better platform optimizations. In 2004, when IBM introduced the zAAP technology, Java economics radically improved, and Java invaded huge numbers of mainframe sites. And now, in early 2008, we have the System z10. The new quad-core design once again radically improves Java's economics, with Java typically much closer to that "up to 100% improvement" figure than other workloads. So if you roughly double the core Java performance, increase the number of cores to as many as 64 per machine, triple the memory (for those memory-hungry Java applications, to trade memory for CPU), steer work better using HiperDispatch, allow up to 32 of those 64 cores to be license-free zAAPs, and run the whole thing on zNALC-priced z/OS LPARs that enjoy another "technology dividend," what does that do to the economics?

It means the System z10 is the ultimate Java platform, that's what. And the machine still runs everything else you ever wrote (or will write) in the other languages, faster and better.

Now, contrary to popular belief, path length still matters. Java is not the universal programming language; no language is. (Well, maybe Rational EGL, which lets you program in one easy language and deploy to either a COBOL or Java runtime, without learning either language. Darn useful, that.) But the new System z10 challenges traditional thinking: what if mainframe processing power were comparatively cheap and abundant, especially for Java? What if mainframes really were supercomputers?

System z10 is a disruptive technology.

It's fascinating working with Java developers who experience running their code on the mainframe for the first time. Their first reaction is typically, "It can run?" Then, "Wow, it runs!" Yes, write-once/run-anywhere really works, at least for J2EE applications.

But the next reaction is often, "Are you sure what the mainframe is saying about my code is true?" That's because there are no coding secrets when you run on the mainframe. WebSphere Application Server for z/OS can produce a flood of juicy SMF records to help expose poor quality (e.g. poor performing) code quickly and precisely. Tools like Jinsight (free and exclusively for System z) and Tivoli Composite Application Manager peer even deeper inside. The mainframe is the best Java diagnostic environment on the market, at least "out of the box." All this introspection can be a blow to the sometimes fragile egos of application developers who suddenly learn that, no, code to look up an account balance probably shouldn't require two full CPU-seconds per user. Make sure you understand that psychological dynamic.

One solution is to award bonuses to developers who meet or exceed performance targets. There are some complexities in how to run such a program, but the concept makes sense and can help establish a new performance-oriented esprit d'corps within the development community.

Sample Jinsight Screen
Jinsightlive02

by Timothy Sipples February 28, 2008 in Application Development
Permalink

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d834521c8469e200e5508895d28833

Listed below are links to weblogs that reference Java Grown Up with the System z10:

Comments

Here is a different twist on the meaning of "Java Grown Up With the System z10". Today March 14, 2008, the z390 Portable Mainframe Assembler and Emulator tool version v1.4.01 was released with support for 226 new z10 mainframe instructions. z390 is an open source J2SE java tool which runs on Windows XP/Vista and Linux and now allows students and system software developers to code and unit test mainframe assembler for the new IBM z10 mainframe.

In initial performance testing, the new compare and branch instructions on the z10 appear to deliver a 15% performance gain over the previous equivalent 2 instruction sequence consisting of compare and then branch on condition code.

Don Higgins
don@higgins.net

Posted by: Don Higgins | Mar 14, 2008 9:40:23 PM

The comments to this entry are closed.



The postings on this site are our own and don’t necessarily represent the positions, strategies or opinions of our employers.
© Copyright 2005 the respective authors of the Mainframe Weblog.