On Wed, 25 Apr 2012 22:58:17 +0200, Fritz Wuehler <[email protected]> wrote:
>"HeyBub" <[email protected]> wrote: > >> Nomen Nescio wrote: >> >> >> >> If you've already done it, get someone to show you the miracle of >> >> cut-and-paste. I'd like to see the code. >> > >> > Sign the NDA! You should be thanking us for telling you how to save >> > money but you just want to argue 5 billion instructions in one batch >> > job are insignificant. So what's the point? Believe what you want. >> > Better yet, try it yourself and learn. If you got the stuff, that is! >> >> So, I took your challenge and coded it up. Here's my code: >> >> MOVE 52000000000 TO MAX. *> 5 billion > >Can you show the PICTURE for MAX? > >> CALL 'TIMEIT-BEGIN'. > >Don't have this routine obviously. I'll see what else I can use. Probably >safest to write two separate programs but with this tiny example it's not >going to be very useful. For best results take a big program and straight >line it as the other poster suggested. We have seen the difference. Anybody >who tries it will also. > >> PERFORM MAX TIMES >> MOVE MAX TO DUMMY >> END-PERFORM. > > >This is an inline PERFORM. It should compile like two GO TOs. We have been >talking about old-style (non-inline) PERFORMs. If you have optimization on >the compiler should move the MOVE outside the PERFORM and eliminate the loop >entirely resulting in a nice piece of code one instruction long that doesn't >loop. Of course this doesn't represent what we have been discussing which is >hundreds of PERFORMS performing large blocks of code. The test case you >wrote probably isn't worth anything. You have to test it with a real >production program and you will find the same results me and the other >poster reported. > >To change your inline PERFORM to the ones we have been fixing use the format > > PERFORM TIME-LOOP THRU TIME-LOOP-EXIT MAX TIMES. PERFORM TIME-LOOP THRU TIME-LOOP-EXIT may not optimize because of ambiguity of path to reach TIME-LOOP-EXIT. If Tom Ross reads this on IBM-MAIN he can clarify. If you code PERFORM TIME-LOOP and TIME-LOOP can NOT be reached by GO TO or fall through, The IBM z series compiler will either move the code in line or general fewer instructions for the PERFORM because it doesn't have to handle the fall through condition. This is based on coding programs for VS COBOL II V1R4 and COBOL for MVS and VM in the late 1990s and reading the generated code. If all the programs you deal with have PERFORM ... THRU or GO TO statements you may never see the new PERFORM optimizations. The COBOL VS PERFORM ... VARYING ... UNTIL was a pig. The VS COBOL II V1R4 and later compilers could generate some slick code. Techniques I used to take an hour off a compute bound program compiled with the COBOL VS compiler and which were detailed in an article by me in a 1991 or 1992 issue of Technical Support published by NaSPA would have to be revisited when moving to VS COBOL II V1R4 and later to reduce the CPU time further. Clark Morris > > .. > >TIME-LOOP. > MOVE MAX TO DUMMY. >TIME-LOOP-EXIT. > EXIT. > > >> CALL 'TIMEIT-DURATION' USING DURATION. >> DISPLAY DURATION. >> MOVE 0 TO WSCOUNT. >> CALL 'TIMEIT-BEGIN'. > >> LOOP. >> ADD 1 TO WSCOUNT >> MOVE MAX TO DUMMY >> IF WSCOUNT > MAX >> GO TO LOOP-EXIT >> ELSE >> GO TO LOOP. >> LOOP-EXIT. > >This is pretty poor looping code. Unoptimized it probably generates twice as >many tests as even an inline PERFORM. The first test is going to execute 5 >billion times for nothing since it will never be true until the end. > >A simple way to do this would be > > MOVE ZERO TO WSCOUNT. > > LOOP. > ADD 1 TO WSCOUNT. > MOVE MAX TO DUMMY > IF WSCOUNT < MAX > GO TO LOOP. > >I'll check if Enterprise COBOL is smart enough to unroll this loop with >optimization. > >> CALL 'TIMEIT-DURATION' USING DURATION. >> DISPLAY DURATION. >> >> The results were: >> >> PERFORM = 2.36seconds >> GO TO LOOP = 37.78 seconds > >Not sure why there should be so much difference. Your compiler may have >(should have) optimized your inline PERFORM out of existence. Inline PERFORM >is fine, it's the out of line PERFORMs we have been discussing (see previous >posts). > >If you have optimization turned on also make sure it hasn't reordered the >calls to TIMEIT-BEGIN or done anything else that could affect the timing >between the two sections. As stated above this example isn't useful because >it just shows the difference without paging effects. Actually it doesn't >even show that at this point until we correct the things I mentioned. > >These trivial examples don't give an accurate performance measurement since >you're running on a PC with nothing else going on and we have been talking >about a busy mainframe shop with batch work. In a small example everything >is on one page. Out of line PERFORM can affect the paging rate when spread >out over a big program. The results are significant on busy systems. Another >poster's confusion about nested PERFORMs also shows possible problems with >PERFORM. For all their alleged simplicity most people don't understand how >they work. > > >> >> >> > >> > Yeah but you don't have a z/OS box, Enterprise COBOL, or a big >> > nightly batch window. And that is what this discussion has been about. >> >> A. How do you know I don't have a Z-OS box? Another presumption on your >> part. > >Because you keep talking about running COBOL on your PC and write code like >a PC programmer where not much matters. > >> B. You are correct: we don't have a big nightly batch window. We write >> software for our customers. But our customers don't have big nightly batch >> windows either - our software updates in real-time. Sorry about your '70's >> programs. > >They're not my '70's programs. I just fix what people pay me to fix. Sorry >if that upsets you. And 70s COBOL for the most part is just fine. It's the >'90's post-Dijsktra COBOL that is problematic. > >> C. We, at least I, am talking about the efficiency of a PERFORM vs. GO TO. >> If you want to re-define the subject and try my code on your big iron, be my >> guest. > >No, we have been talking about the efficiency of out of line (standard) >PERFORM vs. GO TO in an IBM mainframe environment running a big batch >workload with hundreds of programs processing the Carl Sagan-like billions >and billions of records using Enterprise COBOL. > >> >> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
