Programs in many languages running on many systems suffer a performance loss when converted to execute in 64-bit mode.  PL/I programs on z/OS are the opposite:  in general, the 64-bit version of a program will run faster.  As always, there could be exceptions to this observation.  We will briefly explain some reasons why converting programs to 64-bit execution on some systems causes a performance degradation.  Then we will talk about “the silver bullet” for PL/I on z/OS.

Most hardware platforms, certainly including IBM’s z/Architecture, have dedicated resources to handle memory.  With every generation of hardware, this becomes more important because CPU speed improvements generally outstrip memory speed improvements.  That means that with each generation, memory actually appears to be slower than the previous generation from the perspective of the CPU.  Some examples of hardware resources include translation look-aside buffers (TLBs) and hierarchical caches.  A TLB is a hardware mechanism for more quickly mapping a virtual address page to a physical page.  A cache is a mechanism for retaining recently loaded data and, sometimes, for predictively pre-fetching data.  If a typical program’s data contains a large number of pointers, that program’s data will grow a lot when compiled for 64-bit execution.  (If all the data consists of pointers, the size of the data will double.)  But that means that the pages found by the TLB and the data loaded into the caches contains as little as half of the actual user program data and that means going back to (slow) memory more often while processing the program data.

Some of what is described above can apply to PL/I programs.  However, PL/I programs tend to have a limited number of pointers relative to other data types.  The reason that 64-bit PL/I programs tend to run faster than 31-bit programs is because in 64-bit, we use a calling convention (sometimes known as an application binary interface (ABI)) called XPLINK (Extra Performance Linkage.)  XPLINK offers a number of significant performance improvements over the ABI used in 31-bit.  One of the biggest ones is the fact that the first three integer parameters (and pointer data is considered integer data in this context) and floating-point parameters are passed in machine registers.  Not only does this avoid passing data in memory, the fact that the receiving procedure gets its arguments in registers often improves register assignment and code generation dramatically in the receiving procedure.  XPLINK also offers simpler (faster) allocation of stack frames, faster operations on function pointers and other performance focused features. Therefore, XPLINK is the ”silver bullet” that can have a significant positive impact on the runtime performance of 64-bit applications.

Since many PL/I programs do not have data sections dominated by pointers and since many are quite well structured (which usually means a good number of procedure calls) they tend to perform faster when compiled for 64-bit execution.  For my own code, I would only ever compile for 64-bit execution.  Though I should point out one potential issue.  If you compile for 64-bit execution, it is best to compile the entire application and not just one or two packages.  That is because 64-bit code can only call 31-bit code, and vice-versa, on DLL boundaries.  That could require repackaging some code.  Furthermore, crossing that boundary in either direction requires a lot of overhead and is not very good for performance.