Version 6.1 of the Enterprise PL/I for z/OS compiler includes the revitalization of some key compiler components.  This required an intense effort that was undertaken not only to allow for exploitation of IBM z16 but also to ensure that PL/I will continue to make future generations of the z/Architecture vital in all the many roles where it operates.

Regardless of processor designer, it becomes increasingly difficult to simply increase clock speed to increase performance.  I’m using an 16 point font and at 5.2Gz, light travels approximately the length of the first three words of this paragraph in one clock cycle.  So there are limits to data paths within the processor.  Adding functional units to the processor also has challenges.  This is primarily because most code in the world is fairly sequential.  That means that enhanced performance often requires that the result generated by one functional unit needs to be passed directly to another functional unit “on the fly.”  That requires a lot of complicated (and combinatorically challenging) result forwarding logic.

Hardware teams do remarkable work to overcome the problems.  But they also pursue other avenues to improve the performance of existing workloads.  Some recent examples include deploying vector registers to speed up one of PL/I’s fundamental data types:  packed decimal.  And with IBM z16, this was further enhanced to pack and unpack zoned decimal date into and out of vector registers.  These are just examples;  every recent z/Architecture including IBM z16 has had a number of features to improve the performance of many typical PL/I applications.

We see this trend continuing for years to come.  It does mean that to take full advantage of new features available with IBM z16 and future architectures, it will be necessary to recompile performance critical programs.   It also means that our compilers need to be continually updated to support that effort.  The revitalization of key compiler components that we undertook in this release sets up the PL/I compiler to be ready to exploit future z/Architecture features which, in turn, will keep PL/I programs performing well long into the future.

Speaking of PL/I performance, our goal is to continuously improve that.  If your organization has key programming practices or makes frequent use of programming idioms, we would like to hear about those to see how the compiler handles them.  Similarly, if you have a performance critical program and you think the compiler could do a better job, please let us know.