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:IBM-MAIN@bama.ua.edu] On
> Behalf Of Charles Mills
> Sent: Tuesday, May 31, 2011 2:02 PM
> To: IBM-MAIN@bama.ua.edu
> 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:IBM-MAIN@bama.ua.edu] On
> Behalf
> Of Mike Schwab
> Sent: Tuesday, May 31, 2011 1:35 PM
> To: IBM-MAIN@bama.ua.edu
> 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to