And those results mirror the results I have seen from application-level MIPS-reduction exercises over the last several years. Eliminating "long" moves (FSVO "long") reduced measured CPU time by non-trivial amounts (in batch, on average, over multiple runs, over millions of input records), adding up to a provable significant savings at the end of the exercises. These were mostly COBOL programs, but any change that eliminated an MVCL in the generated code helped.
It may not seem logical, but measurements bear out the facts. Peter > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Andy Coburn > Sent: Tuesday, May 31, 2011 6:10 PM > To: [email protected] > 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 -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. ---------------------------------------------------------------------- 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
