> -----Original Message----- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER- > [email protected]] On Behalf Of john gilmore > Sent: Friday, October 08, 2010 10:13 AM > To: [email protected] > Subject: Re: TRTR <Snipped> > The TRTR is a relatively new instruction, and I should be prepared to > stipulate that it is now slower than constructs that use CLCs in loops. > > I doubt that it will remain so, but that is not my point here.
Understood, but see below. > The use of a TRTR is here more perspicuous; and attempts to replace single > millicode-based instructions with loops of older hardware ones are, I > think, perverse. A good programming style, like a good prose style, is > preoccupied with lucidity, force, and ease, and not with this sort of > thing. > > On, say, a millisecond IBM 650 they made some sense; on a nanosecond > zArchitecture machine they make none. Retreating into the familiar is > easy, too easy. Attention to such 'problems' just does not help to give > this platform a future. I beg to differ. In the application-level MIPS reduction project of which I spoke, just eliminating the use of redundant high-byte-count MVCL's (COBOL MOVE's, in actual fact) generated about a 10-15% reduction in overall CPU time consumed by the application during the batch window (we are talking about batch record volumes into the tens of millions here). The particular example where I was comparing performance of techniques to find the rightmost non-blank yielded an additional 5% improvement in performance by using the "older" instruction set. Being able to reduce the overall batch window CPU consumption by these kinds of percentages yields real money savings for the company and significant improvements in meeting current SLA's and preparing for anticipated increases in business transaction volumes. Even on nanosecond zArhitecture machines, attention to detailed performance factors does count for real money. Certainly use of a millicoded instruction like TRTR is more transparent and "cleaner" from the perspective of algorithmic design and intent, and even arguably more "maintainable", but when multiplied out by high business transaction volume it is not in any business's best financial interest to use it. Yet, anyway. Peter -- 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.
