Ahead of New Year's resolution mania, I have to confess to a questionable decision dating back to my absolute first IT job as a programmer trainee. The company was TRW Credit Data, ancestor of Experian. The application was Business Credit, which performed B2B reporting analogous to consumer reporting.. My task was to (re)write a report on all the record types in the data base. The procedure was simple: read a record, determine the type, increment the appropriate counter, then read the next record.
As a newbie, I got curious about the relative speed of these strategies: 1. L R15, COUNTER 2. A R15,=F(+1) 3. ST R15, COUNTER 1. L R15, COUNTER 2. LA R15,1(,R15) 3. ST R15, COUNTER I asked my manager, who encouraged me to delve into the manual Shmuel cites. I decided that LA was faster because there was no storage access. The program ran like a banshee. It ran so fast that it was used to benchmark new hardware. Really! It wasn't till later that I pondered a basic flaw. As written, the program could not handle a counter greater than 16M because it ran in 24 bit mode. This was before XA. At the time I wrote it, the data base was comfortably within that limit, but over time, long after I had moved on, I (still) wonder if the application survived and if any counter ever hit the limit. Moral: whether or not size matters, speed is certainly not a simple metric. . . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile [email protected] [email protected] > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] > On Behalf Of Shmuel Metz (Seymour J.) > Sent: Thursday, December 24, 2015 12:26 PM > To: [email protected] > Subject: [Bulk] Re: Is there a source for detailed, instruction-level performance > info? > > In <[email protected]>, on 12/23/2015 > at 08:28 PM, Thomas Kern > <[email protected]> said: > > >Perhaps what might be useful would be an assembler program to run loops > >of individual instructions and output some timing information. > > That would work on a simpler machine. Even the timings in, e.g., GA22-7011-4, > BM System/370 Model 158 Functional Characteristics, were too complex. > > -- > Shmuel (Seymour J.) Metz, SysProg and JOAT > ISO position; see <http://patriot.net/~shmuel/resume/brief.html> > We don't care. We don't have to care, we're Congress. > (S877: The Shut up and Eat Your spam act of 2003) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
