MVCOS? Also needs to be re-driven after 4K -----Original Message----- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Steve Smith Sent: 20 October 2020 22:59 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Conditional MVCL macro?
There's actually a big difference between MVCL being interruptible, and MVCLE stopping periodically before it's finished. The latter is not interruptible, it just stops before completion periodically for the program to do something else if it wants to. Checking a flag is a possibility, but to what end I cannot figure. Anyway, that is not possible with MVCL (without OS assistance that does not exist). I've heard contrary information on the relative performance of MVCL & MVCLE. I had no idea that MVCLE generally only moved a maximum of 4K per iteration, which on the face of it would seem to imply it could be very slow for large moves (particularly if your program fools around much before re-driving it). As for MVCL, I've heard consistently that it is considerably slower than MVCs galore, which still puzzles me. The explanations I've heard sound to me like they could possibly amount to a trivial extra cost, i.e. much less than what is commonly observed. And for something completely different... sometimes I use MVCK for a variable-length move instead of EX/MVC or MVCL. I haven't done any performance tests, because I haven't used it in performance-critical code (and it does have a warning that it is slow). But for programming convenience, getting & setting the key is (at least slightly) less of an annoyance than setting up EX. I vaguely recall a rumor that there is an MVCX milli-code instruction that works the same without the key specification. Sure would be nice if that appeared in PoOp. sas On Tue, Oct 20, 2020 at 3:09 PM Christopher Y. Blaicher < cblaic...@precisely.com> wrote: > There may be a hint to the reason for the jump in the explanation of > MVCLE, programming note 3. > > "The function of not processing more than approximately 4K bytes of > either operand is intended to permit software polling of a flag that may be > set by a program on another CPU during long operations." > > If a similar process happens with MVCL at the 2K boundary, that could be > the explanation. I'm not a hardware guy, so just guessing. > > Chris Blaicher > Technical Architect > Precisely.com > > > -----Original Message----- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > On Behalf Of Christopher Y. Blaicher > Sent: Tuesday, October 20, 2020 2:47 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Conditional MVCL macro? > > This message originated Externally. Use proper judgement and caution with > attachments, links, or responses. > > > I just re-ran a test on our z15 machine and got interesting numbers. The > $MVC was reasonably linear from start to finish. The MVCL has a big jump > from 2K to 4K, but was also reasonably linear outside of that jump. It > never caught up to the $MVC implementation. > > TEST TYPE = BASE CODE > CPU TIME USED= 0.003873 > TEST TYPE = 1K 4 MVC > CPU TIME USED= 0.171274 > TEST TYPE = 1K $MVC > CPU TIME USED= 0.183642 > TEST TYPE = 1K MVCL > CPU TIME USED= 0.345227 > TEST TYPE = 2K $MVC > CPU TIME USED= 0.357314 > TEST TYPE = 2K MVCL > CPU TIME USED= 0.509385 > TEST TYPE = 4K $MVC > CPU TIME USED= 0.704173 > TEST TYPE = 4K MVCL > CPU TIME USED= 2.790247 > TEST TYPE = 8K $MVC > CPU TIME USED= 1.426892 > TEST TYPE = 8K MVCL > CPU TIME USED= 5.480536 > TEST TYPE = 32K $MVC > CPU TIME USED= 5.835773 > TEST TYPE = 32K MVCL > CPU TIME USED= 21.734112 > TEST TYPE = 64K $MVC > CPU TIME USED= 12.278130 > TEST TYPE = 64K MVCL > CPU TIME USED= 43.380435 > TEST TYPE = 128K $MVC > CPU TIME USED= 54.570900 > TEST TYPE = 128K MVCL > CPU TIME USED= 86.739562 > > All the iterations used this basic set of instructions. > * > * TEST 1K $MVC > * > SPACE , > L R9,REPEATCOUNT DO IT 100,000 TIMES > TIMEUSED STORADR=STARTIME,CPU=TOD,LINKAGE=SYSTEM > LOOP1A DS 0H > L R3,POOLADDR GET FROM ADDRESS > L R4,TOADDR GET TO ADDR > L R5,=A(1024) MOVE 1K BYTES > $MVC (R4),(R3),(R5) MOVE IT > AHI R3,1024 > AHI R4,1024 > BCT R9,LOOP1A LOOP THE NEEDED NUMBER OF TIMES > TIMEUSED STORADR=ENDTIME,CPU=TOD,LINKAGE=SYSTEM > SPACE 3 > LA R1,=CL12'1K $MVC' > BAL R14,TIMEOUT > * > * TEST 1K MVCL > * > SPACE , > L R9,REPEATCOUNT DO IT 100,000 TIMES > TIMEUSED STORADR=STARTIME,CPU=TOD,LINKAGE=SYSTEM > LOOP2 DS 0H > L R2,POOLADDR GET FROM ADDRESS > L R3,=F'1024' > L R4,TOADDR GET TO ADDR > L R5,=F'1024' > MVCL R4,R2 MOVE IT > BCT R9,LOOP2 LOOP THE NEEDED NUMBER OF TIMES > TIMEUSED STORADR=ENDTIME,CPU=TOD,LINKAGE=SYSTEM > SPACE 3 > LA R1,=CL12'1K MVCL' > BAL R14,TIMEOUT > The REPEATCOUNT value is 10,000,000 > Both POOLADDR and TOADDR areas are 256K in size, so they both should be on > page boundaries. > > Chris Blaicher > Technical Architect > Precisely.com > > > -----Original Message----- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > On Behalf Of Charles Mills > Sent: Tuesday, October 20, 2020 1:57 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Conditional MVCL macro? > > This message originated Externally. Use proper judgement and caution with > attachments, links, or responses. > > > Right. > > I should have said "an interruptibility that is visible to the surrounding > assembler instructions via the CC." > > Charles > > > -----Original Message----- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU > ] > On Behalf Of Seymour J Metz > Sent: Tuesday, October 20, 2020 10:52 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Conditional MVCL macro? > > MVCL is, and always has been, interruptible. > -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
