Thought I'd check to see if I was smart enough to duplicate Andy's results. Same as Andy!
MVCL Results Step Name: STEP010 Cond Code: 0000 Start: 31-May-2011 05:39:00 PM Step Num: 3 PGM Name: MVCTEST End: 31-May-2011 05:39:25 PM CPU (TCB): 00:00:24.00 Storage below 16M: 136k CPU (SRB): 00:00:00.00 Storage above 16M: 4k Trans Act: 00:00:25.48 Service Units: 6,213,461 Tape Mnts: 0 Total EXCPs: 3 MVC Results Step Name: STEP010 Cond Code: 0000 Start: 31-May-2011 05:43:01 PM Step Num: 3 PGM Name: MVCTEST End: 31-May-2011 05:43:04 PM CPU (TCB): 00:00:03.12 Storage below 16M: 136k CPU (SRB): 00:00:00.00 Storage above 16M: 4k Trans Act: 00:00:03.29 Service Units: 808,246 Tape Mnts: 0 Total EXCPs: 3 Andy Coburn <[email protected]> Sent by: IBM Mainframe Discussion List <[email protected]> 05/31/2011 05:12 PM Please respond to IBM Mainframe Discussion List <[email protected]> To [email protected] cc Subject Re: What is the current feeling for MVC loop vs. MVCL? The following is a snip from a program which I just ran on our Z10 whose characteristics are shown last below. The program first moved 65536 bytes from one location to another using MVCL and did this 1 million times. You'll see it took ~56 seconds. Then the same number of bytes were moved using 1 million MVC loops. This took ~8 seconds. Finally, the same number of bytes were moved 1 million times using MVCLE. I have run this program on every CEC that I have had available to me and the results are always relatively the same although the actual numbers change. MVCL has some extraordinarily useful functions: Truncation, padding and returning addresses and lengths after MVCL. Each of these would have to be done manually if a MVC loop were used and these instructions would have to be added into the total time for MVC loops. And, yes, I wrote a MVCL macro. But once one tries to support the case where bits 8 through 31 of R1+1 and R2+1 are not equal the macro gets very big and very awkward. And the macro would have to return the 4 registers with contents the same as MVCL would. 1 MILLION MVCL INSTRUCTIONS IN SECONDS 55.961093 1 MILLION MVC LOOPS IN SECONDS 8.389260 1 MILLION MVCLE INSTRUCTIONS IN SECONDS 115.548643 OPERATING SYSTEM= HBB7770SP7.1.2 HBB7770 CPU ID FROM STIDP: TYPE=2098 VERSION=00 SERIAL=00XXXX EXECUTION ENVIRONMENT: LPAR=YES VM=NO CPU ID FROM STSI: MANUF=IBM TYPE=2098 MODEL=R03 SERIAL=00000000000XXXXX VERSION CODE FROM CONVERSION TABLE= ROLLING 4-HOUR AVERAGE UTILIZATION IS 23 MSUS LPAR XXXX IS UNCAPPED IN A 89 MSU CEC ADJ FACTOR 1946 ACCUM WEIGHT 6385225 TIMES ACCUM 23219 LPAR_NAME=XXXX LPAR_ID=0003 LPAR_SIZE=89 CEC_SIZE=89 ARCH=Z/ARCHITECTURE > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Charles Mills > Sent: Tuesday, May 31, 2011 2:02 PM > To: [email protected] > Subject: Re: What is the current feeling for MVC loop vs. MVCL? > > Just my uninformed opinion, but it's hard for me to see how an MVC loop > could be faster. Both are interruptible. (MVC is not but an MVC *loop* is.) > Both update registers (okay, three versus four). > > I know microcode is not magic but gee, if MVC were faster than whatever > MVCL > does, wouldn't the microcode writers just have used an MVC loop instead of > what they did use for MVCL? > > My uninformed opinion is that MVCL worst case should be no slower than an > MVC loop for indeterminate length moves of possibly more than 256 bytes > (and > as a side benefit, it is a heck of a lot easier to use in that situation, > unless you happen to be very short on spare registers). > > Charles > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf > Of Mike Schwab > Sent: Tuesday, May 31, 2011 1:35 PM > To: [email protected] > Subject: Re: What is the current feeling for MVC loop vs. MVCL? > > How about a macro to replace MVCL with a loop using the same registers but > using MVC? Anyone ever write one? > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html ******* This message may contain confidential information intended only for the use of the addressee(s) named above and may contain information that is legally privileged. If you are not the addressee, or the person responsible for delivering it to the addressee, you are hereby notified that reading, disseminating, distributing or copying this message is strictly prohibited. If you have received this message by mistake, please immediately notify us by replying to the message and delete the original message immediately thereafter. Thank you. ******* ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
