Finally caving in to overwhelming temptation. In my first IT job as an assembler application trainee, my assignment was to (re)write a data base accounting program. The program read every record in the application data base and reported the number of each type of record. Pretty simple. There were hundreds of record 'buckets', and my program counted and formatted totals for all of them into the millions.
As a newbie, I wanted to streamline the process as much as possible. I consulted manuals in the department library (no internet then) to assess relative instruction efficiency. My manager encouraged me (thank you Frank) to spend the extra time. I decided on this technique when I needed to tally a particular record type: L Rn,COUNTER Fetch the counter LA Rn,1(,Rn) Increment the count ST Rn,COUNTER Update the counter Along with some fairly 'imaginative' structural techniques, this program ran like a bat out of aitch ee double hockey sticks. I was later told after I had joined the sysprog staff that my program had been used to benchmark hardware and software upgrades. Wow. After I had move on, I was nagged by an obvious limitation: while the data base at the time contained at most 12M records of any type, my technique would fail utterly in the 24 bit world if any bucket hit the 16M ceiling. Don't know what ever happened, but Experian ultimately inherited the issue. No one has tracked me down. Point is that I was a bargain potato in a world where hardware was the gorilla in the data center. Nowadays I make a boatload of dough, while the hardware gets cheaper by the generation. Efficiency should never be dissed, but there are also other fish to fry in the 21st Century. Lesson: maintain perspective.; . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile [email protected] From: Charles Mills <[email protected]> To: [email protected], Date: 02/17/2014 08:19 PM Subject: Re: Optimization, CPU time, and related issues Sent by: IBM Mainframe Discussion List <[email protected]> Isn't it called Jump, or more properly, Branch Relative on Condition? Charles -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Bernd Oppolzer Sent: Monday, February 17, 2014 4:35 PM To: [email protected] Subject: Re: Optimization, CPU time, and related issues Hello, when we discussed the one bit copy topic recently, I had a solution in mind that was kind of inspired by the new "store on condition" instruction, but there was no such solution, because a instruction like "OI on condition" or "NI on condition" would have been necessary, and there are no such instructions. Now my question: I could imagine some use cases for a new instruction, that supresses the execution of the next instruction, depending on certain values of the condition code. For example SKIP NEXT INSTRUCTION IF NOT ZERO, or IF ZERO. This would be much more general than "store on condition", because you could skip every instruction (not only ST), depending on the condition code. Of course, this needs some extensions to the machine logic, because it must be possible that only the PSW will be incremented but the instruction is not executed, depending on this SKIP condition. But: it saves some branches in some cases. My question is: if we had such an instruction, how would this fit into the overall machine concept? And: are there some performance benefits, or are there some problems with this approach, which I do not see? I'm sure, that some historical machines had such concepts ... Kind regards Bernd Am 18.02.2014 00:36, schrieb Ed Jaffe: > > Bottom line: every developer should try to write code that runs as > fast as possible. A single MSU increase at just the wrong time could > translate into huge $$. > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
