I remember when I first was disabused of the quaint notion that the CPU performance of a batch z/OS application could be measured in a deterministic manner, here on this very list some years ago. The implications of processor pipelining and branch prediction and AGI and cache lines had just not sunk into my thick Irish head before that time. I well remember my sincere and aggravated frustration that performance measurement had been reduced to "statistical averages". I was at that time engaged in an active and crucial CPU reduction exercise for my employer, and having the ability to perform deterministic measurement would have made my job then SO much easier.
I am still at least mildly upset that we can no longer accurately measure or predict performance, but only produce statistical estimates. OTOH, having seen the kind of processor-specific, pipeline-optimized instruction generation that the current C/C++ compiler back end can produce (and that hopefully the new COBOL back end will produce as well), I am more sanguine about our ability as programmers to produce fast, efficient code for our employers. However, it would be extraordinarily helpful if IBM commissioned a Redpaper or two about application programming paradigms and design patterns (in more than one application language) so that current and future mainframe coding practitioners could "keep current" with the tremendous hardware enhancements that have been and are being brought into our world, will we, nil we. Or perhaps such desiderata have already been written and I am just ignorant of their availability? Peter -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of John Eells Sent: Wednesday, July 10, 2013 2:55 PM To: [email protected] Subject: Re: Benchmark of Relative instructions vers Base+displacement ones Charles Mills wrote: > In other words, if one had to venture a *guess* it would be that the > immediate instructions were in practice a heck of a lot faster. > > (Don't know that this sort of issue is relevant to the relative versus > branch/displacement comparison.) > <snip> This is a performance question, right? So "it depends." (Yes, I know you knew that.) And I'm not a performance expert, nor did I stay in a well-known hotel last night. But I'll venture out on this "branch" anyway, to say... That John hit the nail on the head when he said that processors have gotten a lot faster than memory. To put this into perspective, since the 3168-3 processor came out in the 1970's the cost of a cache-miss real memory access when counted in machine cycles has risen over 400x. (That's not a typo. It's really more than a factor of four hundred.) That some of our compilers are maximizing the use of immediate and register operands to some extent just for this reason. Although the path length is "theoretically" longer for some of these strings of instructions, they avoid memory accesses often enough that on a practical level they are faster. That it's time for everyone to be thinking of memory accesses the way we've thought about I/O accesses for half a century. Avoid, buffer, prestage...etc. And, finally, that the branch instruction itself does not stand alone. One must load a register to use it as a base in order to establish addressability, and load another to use it as a displacement register, and Load instructions can cause real memory (vs. cache) accesses. So, it seems to me there can be some applicability to relative branch as well. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
