Re: What is the current feeling for MVC loop vs. MVCL?

[Shmuel Metz (Seymour J.)]

In , on 06/02/2011
   at 06:56 PM, Paul Gilmartin  said:

>Is this a hardware feature?

That depends upon what "it" is.

>If not, I could envision doing it in software: point the page table
>entry at a physical page containing zeroes; widely shared, and
>entirely write-protected.  Then a protection exception could be
>handled as if it were a page fault.

Why not mark the page as invalid and treat the page fault as a page
fault? Prezeroing new page frames does not require the full generality
of copy-on-write.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Shmuel Metz (Seymour J.)]

In <061901cc208f$6732dae0$359890a0$@us>, on 06/01/2011
   at 02:09 PM, Jim Thomas  said:

>Have the 'longer' times for MVCL's been noticed on 'older' processors
>?.

On some processors the MVCL was faster, so it depends on how far back
you're going.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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

Re: What is the current feeling for MVC loop vs. MVCL

[Dale Miller]

Just for a little somewhat humorous light on the subject - Many years  
(and COBOL versions) ago, the COBOL compiler changed its generated  
code so that if the "OBJECT-COMPUTER" was specified as "IBM-370"  
rather than IBM-360 (I may be a little fuzzy on the syntax) and the  
length of the field was larger than 512 (again, possible fuzziness of  
my memory) the generated code used MVCL rather than MVC's. There was a  
great deal of consternation when the old technique of blanking a field  
by setting the first byte of a field to blank, then moving the field  
to itself (offset by one) failed to do anything, since the POO  
description of the MVCL stated that the MVCL would do nothing except  
set a condition code when the input and output areas overlapped  
destructively. The complaint was shrugged off with a WAD from IBM,  
since, at least at the time, the COBOL specs specifically said the  
results of such a move were undefined, even though people had been  
doing it for years.


Dale Miller
dalelmil...@comcast.net

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Shmuel Metz (Seymour J.)]

In , on 06/01/2011
   at 01:36 PM, Tony Harminc  said:

>The assembler programmer does not have an easy way to recompile and
>take advantage of whatever the hardware implementors and compiler
>designers have come up with since the code was written.

If the code is imbedded in macros then it becomes easier. BTDTGTTS.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Chip Grantham]

> If the next use turns out to be for a page-in from aux or from a DIV 
object, then there is no need to zero it.

Very true.  And it make sense when zeroing a page was expensive to the 
processing power available to a CEC.  I wonder though, if a separate 
process - an off board process, like the process that adjusts page last 
reference used byte, could recognize that the page needed to be zeroed? 
I'm just brainstroming. 

>Also, the residual data in available frames is sometimes useful when 
doing problem diagnosis using a stand-alone dump.

For my experience, I've see more dumps from non-zeroed storage than from 
the gain of looking at freed pages in a stand-alone dump (which I've never 
done). 

As a side, I really appreciate the BEAR.  I has helped with a lot with 
random storage values.  Tx


Chip Grantham  |  Ameritas  |  Sr. IT Consultant | cgrant...@ameritas.com 
5900 O Street, Lincoln NE 68510 | p: 402-467-7382 | c: 402-429-3579 | f: 
402-325-4030

 



Jim Mulder  
Sent by: IBM Mainframe Discussion List 
06/03/2011 09:34 AM
Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@bama.ua.edu
cc

Subject
Re: What is the current feeling for MVC loop vs. MVCL?






> I've never understood why a page is put on the available frame queue 
> without first zeroing it.  It's kinda like putting dirty dishs in the 
> cupboard and washing them when you take them out only if company 
> complains.  It would seem to me, in my humble opinion, easy enough to 
put 
> an engine on the chip with the sole responsibility of zeroing the page 
and 
> putting it on the queue.  My humble opinion.

  At the time a frame is made available, it is not known whether
its next use will require it to be zeroed or not.  If the next use
turns out to be for a page-in from aux or from a DIV object, then
there is no need to zero it.

 Also, the residual data in available frames is sometimes useful
when doing problem diagnosis using a stand-alone dump.
 
Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

--
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

***
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: What is the current feeling for MVC loop vs. MVCL?

[Jim Mulder]

> I've never understood why a page is put on the available frame queue 
> without first zeroing it.  It's kinda like putting dirty dishs in the 
> cupboard and washing them when you take them out only if company 
> complains.  It would seem to me, in my humble opinion, easy enough to 
put 
> an engine on the chip with the sole responsibility of zeroing the page 
and 
> putting it on the queue.  My humble opinion.

  At the time a frame is made available, it is not known whether
its next use will require it to be zeroed or not.  If the next use
turns out to be for a page-in from aux or from a DIV object, then
there is no need to zero it.

 Also, the residual data in available frames is sometimes useful
when doing problem diagnosis using a stand-alone dump.
 
Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Chip Grantham]

I've never understood why a page is put on the available frame queue 
without first zeroing it.  It's kinda like putting dirty dishs in the 
cupboard and washing them when you take them out only if company 
complains.  It would seem to me, in my humble opinion, easy enough to put 
an engine on the chip with the sole responsibility of zeroing the page and 
putting it on the queue.  My humble opinion. 

Chip Grantham  |  Ameritas  |  Sr. IT Consultant | cgrant...@ameritas.com 
5900 O Street, Lincoln NE 68510 | p: 402-467-7382 | c: 402-429-3579 | f: 
402-325-4030

***
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: What is the current feeling for MVC loop vs. MVCL?

[Jim Mulder]

> >>If the CPOOL spanned one or more 4K aligned pages, then a ZERO=YES
> >>could zero the area before and after the 4K block and just set the
> >>virtual page table entries for the block to be a read-only dedicated
> >>pre-zero'ed page. I seem to have the impression that STORAGE does
> >>this for allocated pages in some cases (I think that allocated area
> >>has to be page aligned and a multiple of page length to get
> >>pre-zeroed storage).
> >
> >   There are no cases where STORAGE provides you with
> >a read-only page.
> >
> >   What you are suggesting would be considerably slower
> >than clearing done by your own code.

> I might have phrased my description incorrectly. What I was saying is 
> that when you initially allocate an virtual area when that area is 
> actually mapped to memory the page that gets loaded (paged-in) is 
> pre-zeroed. I was just suggesting that this would be simplest to do 
> if there was a single pre-zeroed page to be used for the page-in and 
> the mapping table entry was marked to not use that DASD copy as the 
> target when the virtual page needs to be paged out again.
> 
> BTW: Is my impression that if I use STORAGE to allocate a 
> MULTIPLE-PAGE area, then the virtual page will be pre-zeroed? If so, 
> how is this done?

 When RSM assigns a frame to a virtual page which is in a first
reference state (which simply means that the page is invalid 
at some level in the DAT structure, and there is no copy of 
the virtual storage elsewhere (on aux or in the home
object for a DIV map), RSM zeros the frame.  This is done 
using an MVCL with a source length of zero. On recent 
generations of machines, the MVCL millicode recognizes this case
(4K starting boundary, and length is a multiple of 4K) 
and uses a hardware operation (which is available only to
millicode) which does a padding store executed in the
storage controller, without bringing the lines into the cache hierarchy. 

  For the various ways of allocating virtual pages, there is 
documentation stating when a program can depend on the the
storage being zeroed by the system, in case that knowledge can
allow the program to avoid redundantly zeroing the storage.

  When a virtual page is allocated, it will either be backed
by a zeroed frame, or will be in a first reference state, and then 
subsequently be backed by a frame when an access exception
occurs. 

  CPOOL GET does not allocate virtual storage (well, except
in the case where a CPOOL GET,COND results in a new pool 
extent being built).  The virtual storage is allocated when 
the CPOOL BUILD is done.  CPOOL GET runs in the key and state
of its caller, and simply does a CDS to remove the first cell
from the free queue and return that to the caller.  CPOOL FREE
simply does a CDS to add the freed cell to the head of the free queue.
CPOOL GET and FREE do not interface with RSM to back or unback
virtual pages. 

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Paul Gilmartin]

On Thu, 2 Jun 2011 20:27:25 -0400, Tony Harminc wrote:

>On 2 June 2011 19:56, Paul Gilmartin  wrote:
>> On Thu, 2 Jun 2011 16:29:44 -0700, Edward Jaffe wrote:
>>>
>>>Not pre-zeroed per se, but the pages are in first-reference state.
>>>
>> Is this a hardware feature?  (I haven't a PoOp (PrOp) handy.)
>>
>> If not, I could envision doing it in software: point the page
>> table entry at a physical page containing zeroes; widely shared,
>> and entirely write-protected.  Then a protection exception
>> could be handled as if it were a page fault.
>>
>> Is it worth the cost of implementation, whether done in hardware
>> or in software?  It's merely coddling programmers who perform
>> a fetch long before they store to the same location.
>
>It's not *wrong* or even misleading or obscure, as long as you know
>that the storage contains zeroes. If you obtained the storage using a
>form of STORAGE OBTAIN or GETMAIN that guarantees to give you zeroed
>storage, then where's the problem?
>
>> They deserve to be treated according to the second definition of "coddle" 
>> rather than the first.
>
>It's not merely a matter of coddling programmers (even ovoid ones);
>the system cannot hand out storage that contains someone else's data,
>even if you didn't ask for it to contain zeroes.
>
I understand that quite well, but:

o That's why I asked in an earlier ply whether the page is
  zeroed even if it was previously used by the same address
  space.  I suppose:
  - it's not worth keeping track.
  - even within a job there may be security perimeters
that must be respected.

o I'm puzzled by the value of the first-reference state.  Previous
  plies suggested there is a mechanism such that fetches from a
  (virtual) page in that state will succeed and return zeroes without
  handling a page fault, dedicating a physical page to the address
  space, and clearing that storage.  This is of value only if the
  first fetch from the page precedes the first store into that page
  by a significant interval (or the page is fetched from and never
  stored into).  This seems to me to be a program structure that's
  unlikely and poorly designed.

-- gil

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Tony Harminc]

On 2 June 2011 19:56, Paul Gilmartin  wrote:
> On Thu, 2 Jun 2011 16:29:44 -0700, Edward Jaffe wrote:
>>
>>Not pre-zeroed per se, but the pages are in first-reference state.
>>
> Is this a hardware feature?  (I haven't a PoOp (PrOp) handy.)
>
> If not, I could envision doing it in software: point the page
> table entry at a physical page containing zeroes; widely shared,
> and entirely write-protected.  Then a protection exception
> could be handled as if it were a page fault.
>
> Is it worth the cost of implementation, whether done in hardware
> or in software?  It's merely coddling programmers who perform
> a fetch long before they store to the same location.

It's not *wrong* or even misleading or obscure, as long as you know
that the storage contains zeroes. If you obtained the storage using a
form of STORAGE OBTAIN or GETMAIN that guarantees to give you zeroed
storage, then where's the problem?

> They deserve to be treated according to the second definition of "coddle" 
> rather than the first.

It's not merely a matter of coddling programmers (even ovoid ones);
the system cannot hand out storage that contains someone else's data,
even if you didn't ask for it to contain zeroes.

Tony H.

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Paul Gilmartin]

On Thu, 2 Jun 2011 16:29:44 -0700, Edward Jaffe wrote:
>
>Not pre-zeroed per se, but the pages are in first-reference state.
>
Is this a hardware feature?  (I haven't a PoOp (PrOp) handy.)

If not, I could envision doing it in software: point the page
table entry at a physical page containing zeroes; widely shared,
and entirely write-protected.  Then a protection exception
could be handled as if it were a page fault.

Is it worth the cost of implementation, whether done in hardware
or in software?  It's merely coddling programmers who perform
a fetch long before they store to the same location.  They
deserve to be treated according to the second definition of
"coddle" rather than the first.

-- gil

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Edward Jaffe]

On 6/2/2011 2:25 PM, Robert A. Rosenberg wrote:
BTW: Is my impression that if I use STORAGE to allocate a MULTIPLE-PAGE area, 
then the virtual page will be pre-zeroed? If so, how is this done?


Not pre-zeroed per se, but the pages are in first-reference state.

--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Paul Gilmartin]

On Thu, 2 Jun 2011 17:25:50 -0400, Robert A. Rosenberg wrote:
>
>I might have phrased my description incorrectly. What I was saying is
>that when you initially allocate an virtual area when that area is
>actually mapped to memory the page that gets loaded (paged-in) is
>pre-zeroed. I was just suggesting that this would be simplest to do
>if there was a single pre-zeroed page to be used for the page-in and
>the mapping table entry was marked to not use that DASD copy as the
>target when the virtual page needs to be paged out again.
>
Are you suggesting that it's more efficient to zero a page
by reading in a page of zeroes from DASD than by MVC[L],
overlapping, in a loop, whatever?

Based on the anecdotes here so far, I'd vote for STM
in a loop.

>BTW: Is my impression that if I use STORAGE to allocate a
>MULTIPLE-PAGE area, then the virtual page will be pre-zeroed? If so,
>how is this done?
>
Does it depend on whether the physical page(s) allocated
previously belonged to a different address space or to the
same address space?

-- gil

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Robert A. Rosenberg]

At 02:53 -0400 on 06/02/2011, Jim Mulder wrote about Re: What is the 
current feeling for MVC loop vs. MVCL?:



 >>> Obviously you can have "fast clear" for objects with lengths that

  256-multiple using n*XC  - however I have often wished for a
  ZERO=YES option on the CPOOL BUILD so that you are guaranteed a
  clean cell for each subsequent CPOOL GET. If anyone else agrees, I
  might consider raising a Share requirement 


   Such a requirement would likely be rejected.  There isn't anything
CPOOL can do to obtain better performance for clearing a cell than
what you can do in your own code.  Clearing done by CPOOL would be
guaranteed to be at least marginally slower, and in some cases
considerably slower, than clearing done by your code.



If the CPOOL spanned one or more 4K aligned pages, then a ZERO=YES
could zero the area before and after the 4K block and just set the
virtual page table entries for the block to be a read-only dedicated
pre-zero'ed page. I seem to have the impression that STORAGE does
this for allocated pages in some cases (I think that allocated area
has to be page aligned and a multiple of page length to get
pre-zeroed storage).


  There are no cases where STORAGE provides you with
a read-only page.

  What you are suggesting would be considerably slower
than clearing done by your own code.

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY


I might have phrased my description incorrectly. What I was saying is 
that when you initially allocate an virtual area when that area is 
actually mapped to memory the page that gets loaded (paged-in) is 
pre-zeroed. I was just suggesting that this would be simplest to do 
if there was a single pre-zeroed page to be used for the page-in and 
the mapping table entry was marked to not use that DASD copy as the 
target when the virtual page needs to be paged out again.


BTW: Is my impression that if I use STORAGE to allocate a 
MULTIPLE-PAGE area, then the virtual page will be pre-zeroed? If so, 
how is this done?


--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Anne & Lynn Wheeler]

dcrayf...@gmail.com (David Crayford) writes:
> http://www.redbooks.ibm.com/redbooks/pdfs/sg246515.pdf
>
> There is one programming aspect that is relevant, although only
> slightly linked to the use of a split cache. For many years, it has
> been an axiom among S/360 - S/390 users that assembly language
> programmers probably produce faster code than high-level language
> compilers.  This is no longer true. Processors that use pipelines
> (including z800 and z900 machines) require a certain amount of
> nonsequential code to obtain the best performance. For example, if an
> instruction loads a register and the next instruction uses the
> register, we do not have optimum code. This sequence will stall the
> pipeline for several processor cycles. (The instructions work
> correctly, of course, but they take longer than necessary.) The best
> technique is to interleave several unrelated instructions between
> loading a register and using the new contents of the register.
>
> This is not natural, sequential thinking for an assembly programmer,
> although he could learn to do it. IBM’s recent S/390 compilers contain
> logic to produce this sort of optimized code.

re:
http://www.garlic.com/~lynn/2011g.html#67 What is the current feeling for MVC 
loop vs. MVCL?

which makes highly optimized code start to look more like old-time
horizontal microcoding (high-end pok machines, 3830 controller, etc)
... where the programmer was dealing in concurrent operations with
various latencies ... and trying to maximize overlapped operation.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Jim Mulder]

>>> Obviously you can have "fast clear" for objects with lengths that
>>>  256-multiple using n*XC  - however I have often wished for a
>>>  ZERO=YES option on the CPOOL BUILD so that you are guaranteed a
>>>  clean cell for each subsequent CPOOL GET. If anyone else agrees, I
>>>  might consider raising a Share requirement 
>>
>>   Such a requirement would likely be rejected.  There isn't anything
>>CPOOL can do to obtain better performance for clearing a cell than
>>what you can do in your own code.  Clearing done by CPOOL would be
>>guaranteed to be at least marginally slower, and in some cases
>>considerably slower, than clearing done by your code.

>If the CPOOL spanned one or more 4K aligned pages, then a ZERO=YES 
>could zero the area before and after the 4K block and just set the 
>virtual page table entries for the block to be a read-only dedicated 
>pre-zero'ed page. I seem to have the impression that STORAGE does 
>this for allocated pages in some cases (I think that allocated area 
>has to be page aligned and a multiple of page length to get 
>pre-zeroed storage).

  There are no cases where STORAGE provides you with
a read-only page.

  What you are suggesting would be considerably slower
than clearing done by your own code. 

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Gerhard Postpischil]

On 6/1/2011 5:21 PM, Robert A. Rosenberg wrote:

If the CPOOL spanned one or more 4K aligned pages, then a
ZERO=YES could zero the area before and after the 4K block and
just set the virtual page table entries for the block to be a
read-only dedicated pre-zero'ed page. I seem to have the
impression that STORAGE does this for allocated pages in some
cases (I think that allocated area has to be page aligned and a
multiple of page length to get pre-zeroed storage).


That only covers the first request for a cell. If it is freed 
and then assigned again, an explicit clear would be needed to 
satisfy the OP. I'm with Jim Mulder on this; in my case I use 
CPOOL services to build trees (c.f.i. Knuth volume 3 - balanced 
trees), and each cell I get is completely initialized by a move 
(link addresses and leaf data). Which makes me wonder how many 
uses would benefit from a cell that's zeroes vs. ones that 
completely fill the cell with data?


Gerhard Postpischil
Bradford, VT

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[David Crayford]

It's not just OOO that gives optimized compilers an advantage over 
manually crafted assembler. It's been true since zArchitecture that to
write highly effecient code one needs knowledge of the pipeline There 
was a redbook when the zArch machines z/800 z/900 came out

that mentions the non-sequential code that compilers generate.

http://www.redbooks.ibm.com/redbooks/pdfs/sg246515.pdf


There is one programming aspect that is relevant, although only slightly 
linked to the use of a
split cache. For many years, it has been an axiom among S/360 - S/390 
users that assembly
language programmers probably produce faster code than high-level 
language compilers.
This is no longer true. Processors that use pipelines (including z800 
and z900 machines)
require a certain amount of nonsequential code to obtain the best 
performance. For example,
if an instruction loads a register and the next instruction uses the 
register, we do not have
optimum code. This sequence will stall the pipeline for several 
processor cycles. (The
instructions work correctly, of course, but they take longer than 
necessary.) The best
technique is to interleave several unrelated instructions between 
loading a register and using

the new contents of the register.

This is not natural, sequential thinking for an assembly programmer, 
although he could learn
to do it. IBM’s recent S/390 compilers contain logic to produce this 
sort of optimized code.



On 2/06/2011 12:09 AM, Anne & Lynn Wheeler wrote:

re:
http://www.garlic.com/~lynn/2011g.html#57 What is the current feeling for MVC 
loop vs. MVCL?

other recent gcc reference:
http://www.garlic.com/~lynn/2011g.html#50 My first mainframe experience

... and recent reference to out-of-order pipeline introduced
http://www.garlic.com/~lynn/2011f.html#46 At least two decades back, some gurus 
predicted that mainframes would disappear in future and it still has not 
happened

mentions that introduction of out-of-order in most recent mainframe
accounts for significant part of throughput increase (although it has
been in other architectures for decades).

decades ago, out-of-order was given as major rise of advanced compilers
for high-throughput optimization ... since internal machine processing
was getting a lot more complex with various kinds of instruction
interdependencies and complex dataflow ... becoming harder and harder to
address with manual effort.



--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Robert A. Rosenberg]

At 12:32 -0400 on 06/01/2011, Jim Mulder wrote about Re: What is the 
current feeling for MVC loop vs. MVCL?:



 > Obviously you can have "fast clear" for objects with lengths that

 256-multiple using n*XC  - however I have often wished for a
 ZERO=YES option on the CPOOL BUILD so that you are guaranteed a
 clean cell for each subsequent CPOOL GET. If anyone else agrees, I
 might consider raising a Share requirement 


  Such a requirement would likely be rejected.  There isn't anything
CPOOL can do to obtain better performance for clearing a cell than
what you can do in your own code.  Clearing done by CPOOL would be
guaranteed to be at least marginally slower, and in some cases
considerably slower, than clearing done by your code.


If the CPOOL spanned one or more 4K aligned pages, then a ZERO=YES 
could zero the area before and after the 4K block and just set the 
virtual page table entries for the block to be a read-only dedicated 
pre-zero'ed page. I seem to have the impression that STORAGE does 
this for allocated pages in some cases (I think that allocated area 
has to be page aligned and a multiple of page length to get 
pre-zeroed storage).


--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Martin Packer]

I would expect MVPG to be slow - given its history. If we no longer feel 
the need to go "the scenic route" :-) maybe it isn't.

Martin

Martin Packer,
Mainframe Performance Consultant, zChampion
Worldwide Banking Center of Excellence, IBM

+44-7802-245-584

email: martin_pac...@uk.ibm.com

Twitter / Facebook IDs: MartinPacker
Blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker



From:
Tony Harminc 
To:
IBM-MAIN@bama.ua.edu
Date:
01/06/2011 18:40
Subject:
Re: What is the current feeling for MVC loop vs. MVCL?
Sent by:
IBM Mainframe Discussion List 



On 1 June 2011 12:32, Jim Mulder  wrote:

>  If your 8K MVCLs have 4K-aligned sources and targets, then
> they may be taking advantage of the page mover hardware.  In that
> case, MVCs could be considerably slower.

I had been about to suggest the MVPG instruction, but it's quite
possible that MVCL will use the same infrastructure if circumstances
are right. One imagines that with fewer options and special cases to
evaluate, fewer registers to tie up and none to update, for MVPG the
setup would be shorter, and the execution at least as fast. But one's
imagination is often not a good guide; I have a rather casual
benchmark for these two (that is, MVCL of 4k on a page boundary vs
MVPG with no fancy options) that shows MVPG just barely beating MVCL
on a z10, and losing heavily on all earlier machines I had access to
(P390, zPDT, MP3000, FLEX/ES and z9).

John Gilmore's points are well taken. If I may suggest one more,
loosely put, it is to use instructions for what they are usually used
for (which is, even more approximately, what they are documented to be
used for). This is likely to take advantage of hardware optimizations
over time without forcing a tight binding to the hardware of the day.
The assembler programmer does not have an easy way to recompile and
take advantage of whatever the hardware implementors and compiler
designers have come up with since the code was written.

Tony H.

--
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







Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU






--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Jim Thomas]

John,

I concur However ... there is one question I'd like 
to ask if I may. 

Have the 'longer' times for MVCL's been noticed on 'older'
processors ?. Has MVPG (limited users) been tried ? .. and 
again ... for MVPG that is, any difference between 'older'
and the 'new' z10 ?. 

Jim Thomas
617-233-4130 (mobile)
636-294-1014(res)
j...@thethomasresidence.us (Email)


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of john gilmore
Sent: Wednesday, June 01, 2011 10:02 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: What is the current feeling for MVC loop vs. MVCL?

The "optimizations" that compilers use are certainly interesting in the
sense that there are things to be learned from them.
 
They do, however, have two limitations.  They are particularist, appropriate
usually but not always to the run-time environment in which a particular
compiler's output will be executed but often less so in a different
environment.  (Both advantages and disadvantages have, for example, attended
the use of shared optimizing machinery by IBM PL/I and C.)  
 
These optimizations are also devised by groups whose full-time job is to
optimize code skeletons that are used stereotypically in compiler-generated
code; and these groups inevitably come to have a vested interest in
cleverness, i.e., non-standard, less than obvious ways of doing things. 
 
I have been dismayed by this thread.  It would be better for almost all of
us almost all of the time to use MVCLs, devoting the time not wasted by
examining clever alternatives to them to more significant problems.  

John Gilmore Ashland, MA 01721-1817 USA

  
--
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



-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1375 / Virus Database: 1509/3671 - Release Date: 05/31/11

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Charles Mills]

Or devoting the time to figuring out how not to MVC(L) the data at all.
Pointers are your friend. Of course, sometimes you have to move the data.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of john gilmore
Sent: Wednesday, June 01, 2011 8:02 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: What is the current feeling for MVC loop vs. MVCL?

The "optimizations" that compilers use are certainly interesting in the
sense that there are things to be learned from them.
 
They do, however, have two limitations.  They are particularist, appropriate
usually but not always to the run-time environment in which a particular
compiler's output will be executed but often less so in a different
environment.  (Both advantages and disadvantages have, for example, attended
the use of shared optimizing machinery by IBM PL/I and C.)  
 
These optimizations are also devised by groups whose full-time job is to
optimize code skeletons that are used stereotypically in compiler-generated
code; and these groups inevitably come to have a vested interest in
cleverness, i.e., non-standard, less than obvious ways of doing things. 
 
I have been dismayed by this thread.  It would be better for almost all of
us almost all of the time to use MVCLs, devoting the time not wasted by
examining clever alternatives to them to more significant problems.  

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Tony Harminc]

On 1 June 2011 12:32, Jim Mulder  wrote:

>  If your 8K MVCLs have 4K-aligned sources and targets, then
> they may be taking advantage of the page mover hardware.  In that
> case, MVCs could be considerably slower.

I had been about to suggest the MVPG instruction, but it's quite
possible that MVCL will use the same infrastructure if circumstances
are right. One imagines that with fewer options and special cases to
evaluate, fewer registers to tie up and none to update, for MVPG the
setup would be shorter, and the execution at least as fast. But one's
imagination is often not a good guide; I have a rather casual
benchmark for these two (that is, MVCL of 4k on a page boundary vs
MVPG with no fancy options) that shows MVPG just barely beating MVCL
on a z10, and losing heavily on all earlier machines I had access to
(P390, zPDT, MP3000, FLEX/ES and z9).

John Gilmore's points are well taken. If I may suggest one more,
loosely put, it is to use instructions for what they are usually used
for (which is, even more approximately, what they are documented to be
used for). This is likely to take advantage of hardware optimizations
over time without forcing a tight binding to the hardware of the day.
The assembler programmer does not have an easy way to recompile and
take advantage of whatever the hardware implementors and compiler
designers have come up with since the code was written.

Tony H.

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Jim Mulder]

IBM Mainframe Discussion List  wrote on 06/01/2011 
10:33:51 AM:

> Rob Scott 

> I know that in the software I am involved in, that "MVCL(*)" for 
> clearing is used *way* more than any movement purposes as I am a 
> heavy user of CPOOL services. 
> 
> Obviously you can have "fast clear" for objects with lengths that 
> 256-multiple using n*XC  - however I have often wished for a 
> ZERO=YES option on the CPOOL BUILD so that you are guaranteed a 
> clean cell for each subsequent CPOOL GET. If anyone else agrees, I 
> might consider raising a Share requirement 

  Such a requirement would likely be rejected.  There isn't anything
CPOOL can do to obtain better performance for clearing a cell than 
what you can do in your own code.  Clearing done by CPOOL would be
guaranteed to be at least marginally slower, and in some cases
considerably slower, than clearing done by your code. 
 
> (2) Is there any performance difference in MVCL when L2 is zero? 

  Well, at least you can't get any cache misses on the source
when the source length is zero. 

> -Original Message-
> Behalf Of Charles Mills
> Sent: 01 June 2011 14:20
> Subject: Re: What is the current feeling for MVC loop vs. MVCL?
> 
> This thread has been really informative. I am going to put this to 
> use. I have code that is executing a million or so ~8K MVCLs a day. 
> I have other things on my plate at the moment but I will replace 
> that with an MVC loop at some point.
> 
> It seems to me like the ideal way to do this would be to have not 
> two stages (MVC for 256 and EX'ed MVC) but rather three cases: A 
> loop with a "hard-coded" or "unrolled" string of 16 MVC's that moved
> 4K blocks and incremented registers by 4K on each iteration; 
> followed by a loop of 256-byte MVCs; followed by an EX'ed MVC for 1 
> to 255 bytes. (Obviously each step would be optional depending on 
> the exact count.)
> 
> Thoughts?

  If your 8K MVCLs have 4K-aligned sources and targets, then
they may be taking advantage of the page mover hardware.  In that
case, MVCs could be considerably slower. 


Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Anne & Lynn Wheeler]

re:
http://www.garlic.com/~lynn/2011g.html#57 What is the current feeling for MVC 
loop vs. MVCL?

other recent gcc reference:
http://www.garlic.com/~lynn/2011g.html#50 My first mainframe experience

... and recent reference to out-of-order pipeline introduced
http://www.garlic.com/~lynn/2011f.html#46 At least two decades back, some gurus 
predicted that mainframes would disappear in future and it still has not 
happened

mentions that introduction of out-of-order in most recent mainframe
accounts for significant part of throughput increase (although it has
been in other architectures for decades).

decades ago, out-of-order was given as major rise of advanced compilers
for high-throughput optimization ... since internal machine processing
was getting a lot more complex with various kinds of instruction
interdependencies and complex dataflow ... becoming harder and harder to
address with manual effort.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Anne & Lynn Wheeler]

john_w_gilm...@msn.com (john gilmore) writes:
> These optimizations are also devised by groups whose full-time job is
> to optimize code skeletons that are used stereotypically in
> compiler-generated code; and these groups inevitably come to have a
> vested interest in cleverness, i.e., non-standard, less than obvious
> ways of doing things.

more recent state-of-the-art ... is to build a model of the hardware &
instruction operation ... and have code that selects instruction
combinations based on specified cycles (or some other criteria) ... that
code is now finding non-standard, possibly non-obvious, instruction
sequences (also makes it easier to do large number of backends across
variety of different machine architectures). Part of machine model (for
execution) includes things like out-of-order execution dependencies.

long ago and far away, early cp67 (virtual machine precursor to vm370,
ran on 360/67) shipped with virtual address tables initialized pointing
to a special "zeros" page on disk. I changed that to indicate a "zeros"
page and just cleared the storage to zeros. Common operation of the
period was to use (multiple) overlapping MVC. I did implementation that
saved registers, zero'ed ten registers and did BXLE STM loop for those
ten registers (significantly faster than overlapping MVC ... on 360/67).

GCC 4.6
http://gcc.gnu.org/gcc-4.6/changes.html

from above:

S/390, zSeries and System z9/z10, IBM zEnterprise z196

Support for the zEnterprise z196 processor has been added. When using
the -march=z196 option, the compiler will generate code making use of
the following instruction facilities:

Conditional load/store
Distinct-operands
Floating-point-extension
Interlocked-access
Population-count

The -mtune=z196 option avoids the compare and branch instructions as
well as the load address instruction with an index register as much as
possible and performs instruction scheduling appropriate for the new
out-of-order pipeline architecture.

When using the -m31 -mzarch options the generated code still conforms to
the 32-bit ABI but uses the general purpose registers as 64-bit
registers internally. This requires a Linux kernel saving the whole
64-bit registers when doing a context switch. Kernels providing that
feature indicate that by the 'highgprs' string in /proc/cpuinfo.

The SSA loop prefetching pass is enabled when using -O3.

... snip ...

-- 
virtualization experience starting Jan1968, online at home since Mar1970

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[john gilmore]

The "optimizations" that compilers use are certainly interesting in the sense 
that there are things to be learned from them.
 
They do, however, have two limitations.  They are particularist, appropriate 
usually but not always to the run-time environment in which a particular 
compiler's output will be executed but often less so in a different 
environment.  (Both advantages and disadvantages have, for example, attended 
the use of shared optimizing machinery by IBM PL/I and C.)  
 
These optimizations are also devised by groups whose full-time job is to 
optimize code skeletons that are used stereotypically in compiler-generated 
code; and these groups inevitably come to have a vested interest in cleverness, 
i.e., non-standard, less than obvious ways of doing things. 
 
I have been dismayed by this thread.  It would be better for almost all of us 
almost all of the time to use MVCLs, devoting the time not wasted by examining 
clever alternatives to them to more significant problems.  

John Gilmore Ashland, MA 01721-1817 USA

  
--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Tom Marchant]

On Wed, 1 Jun 2011 10:26:37 -0400, Gerhard Postpischil suggested:

>variable MVCs to bump the starting address up to a
>4K multiple (if needed)

Of the source or the destination?

-- 
Tom Marchant

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Richard L Peurifoy]

On 6/1/2011 9:27 AM, Gerhard Postpischil wrote:

On 6/1/2011 9:19 AM, Charles Mills wrote:

It seems to me like the ideal way to do this would be to have not two
stages
(MVC for 256 and EX'ed MVC) but rather three cases: A loop with a
"hard-coded" or "unrolled" string of 16 MVC's that moved 4K blocks and
incremented registers by 4K on each iteration; followed by a loop of
256-byte MVCs; followed by an EX'ed MVC for 1 to 255 bytes. (Obviously
each
step would be optional depending on the exact count.)


If you go through this exercise, I'd also suggest one (minor?) variation
- variable MVCs to bump the starting address up to a 4K multiple (if
needed), then the 4K byte moves, then some more short ones, as needed.
It would be instructive to see whether that's faster than a set of
unaligned moves.


I seem to recall that there was some optimization in MVCL for 4K
aligned moves. Maybe it would be better to use MVC's to get to 4K,
and then switch to MVCL's. However all this checking may overwhelm
the savings.

Note, I have not verified my recollection of this.

--
Richard

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Rob Scott]

I am going to digress a bit here.

I got into a discussion with Martin Packer about some of this and it raised a 
few interesting thoughts :

(1) What percentage of executed MVCL instructions are for clearing storage 
versus actually moving data?

I know that in the software I am involved in, that "MVCL(*)" for clearing is 
used *way* more than any movement purposes as I am a heavy user of CPOOL 
services. 

Obviously you can have "fast clear" for objects with lengths that 256-multiple 
using n*XC  - however I have often wished for a ZERO=YES option on the CPOOL 
BUILD so that you are guaranteed a clean cell for each subsequent CPOOL GET. If 
anyone else agrees, I might consider raising a Share requirement 

(2) Is there any performance difference in MVCL when L2 is zero? 

I seem to recall hearing a while ago that there might be...however am not sure.

(3) How does MVC v MVCL compare in AR mode with source and target using 
different ALETs ?


(*) Yes - I have a @MVCL macro too :-) 

 

Rob Scott
Lead Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Charles Mills
Sent: 01 June 2011 14:20
To: IBM-MAIN@bama.ua.edu
Subject: Re: What is the current feeling for MVC loop vs. MVCL?

This thread has been really informative. I am going to put this to use. I have 
code that is executing a million or so ~8K MVCLs a day. I have other things on 
my plate at the moment but I will replace that with an MVC loop at some point.

It seems to me like the ideal way to do this would be to have not two stages 
(MVC for 256 and EX'ed MVC) but rather three cases: A loop with a "hard-coded" 
or "unrolled" string of 16 MVC's that moved 4K blocks and incremented registers 
by 4K on each iteration; followed by a loop of 256-byte MVCs; followed by an 
EX'ed MVC for 1 to 255 bytes. (Obviously each step would be optional depending 
on the exact count.)

Thoughts?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
David Crayford
Sent: Tuesday, May 31, 2011 8:32 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: What is the current feeling for MVC loop vs. MVCL?

On 1/06/2011 12:13 AM, Kirk Wolf wrote:
> The IBM C compiler would generate an MVC loop.   So, that's how IBM feels
I
> guess.
>

And when the length is a constant it generates multiple MVC instructions to 
eliminate branches. Kind of like loop unrolling.

*
*char input[528];
*
*memcpy( output, input, sizeof input );
MVC  (*)void(256,r1,0),input(r4,1508)
MVC  (*)void(256,r1,256),input(r4,1764)
MVC  (*)void(16,r1,512),input(r4,2020)

And if you increase the size of the buffer it generates a loop with loop 
unrolling (if that makes sense). There seems to be a HWM where it drops into a 
loop.

*
*char input[1];
*
*memcpy( output, input, sizeof input );
LA   r0,5
LA   r6,2176(r4,)
@2L4 DS   0H
MVC  (*)void(256,r1,0),input(r6,0)
MVC  (*)void(256,r1,256),input(r6,256)
MVC  (*)void(256,r1,512),input(r6,512)
MVC  (*)void(256,r1,768),input(r6,768)
MVC  (*)void(256,r1,1024),input(r6,1024)
MVC  (*)void(256,r1,1280),input(r6,1280)
MVC  (*)void(256,r1,1536),input(r6,1536)
LA   r1,(*)void(,r1,1792)
LA   r6,input(,r6,1792)
BRCT r0,@2L4
MVC  (*)void(256,r1,0),input(r6,0)
MVC  (*)void(256,r1,256),input(r6,256)
MVC  (*)void(256,r1,512),input(r6,512)
MVC  (*)void(256,r1,768),input(r6,768)
MVC  (*)void(16,r1,1024),input(r6,1024)

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Gerhard Postpischil]

On 6/1/2011 9:19 AM, Charles Mills wrote:

It seems to me like the ideal way to do this would be to have not two stages
(MVC for 256 and EX'ed MVC) but rather three cases: A loop with a
"hard-coded" or "unrolled" string of 16 MVC's that moved 4K blocks and
incremented registers by 4K on each iteration; followed by a loop of
256-byte MVCs; followed by an EX'ed MVC for 1 to 255 bytes. (Obviously each
step would be optional depending on the exact count.)


If you go through this exercise, I'd also suggest one (minor?) 
variation - variable MVCs to bump the starting address up to a 
4K multiple (if needed), then the 4K byte moves, then some more 
short ones, as needed. It would be instructive to see whether 
that's faster than a set of unaligned moves.



Gerhard Postpischil
Bradford, VT

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Charles Mills]

This thread has been really informative. I am going to put this to use. I
have code that is executing a million or so ~8K MVCLs a day. I have other
things on my plate at the moment but I will replace that with an MVC loop at
some point.

It seems to me like the ideal way to do this would be to have not two stages
(MVC for 256 and EX'ed MVC) but rather three cases: A loop with a
"hard-coded" or "unrolled" string of 16 MVC's that moved 4K blocks and
incremented registers by 4K on each iteration; followed by a loop of
256-byte MVCs; followed by an EX'ed MVC for 1 to 255 bytes. (Obviously each
step would be optional depending on the exact count.)

Thoughts?

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of David Crayford
Sent: Tuesday, May 31, 2011 8:32 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: What is the current feeling for MVC loop vs. MVCL?

On 1/06/2011 12:13 AM, Kirk Wolf wrote:
> The IBM C compiler would generate an MVC loop.   So, that's how IBM feels
I
> guess.
>

And when the length is a constant it generates multiple MVC instructions to
eliminate branches. Kind of like loop unrolling.

*
*char input[528];
*
*memcpy( output, input, sizeof input );
MVC  (*)void(256,r1,0),input(r4,1508)
MVC  (*)void(256,r1,256),input(r4,1764)
MVC  (*)void(16,r1,512),input(r4,2020)

And if you increase the size of the buffer it generates a loop with loop
unrolling (if that makes sense). There seems to be a HWM where it drops into
a loop.

*
*char input[1];
*
*memcpy( output, input, sizeof input );
LA   r0,5
LA   r6,2176(r4,)
@2L4 DS   0H
MVC  (*)void(256,r1,0),input(r6,0)
MVC  (*)void(256,r1,256),input(r6,256)
MVC  (*)void(256,r1,512),input(r6,512)
MVC  (*)void(256,r1,768),input(r6,768)
MVC  (*)void(256,r1,1024),input(r6,1024)
MVC  (*)void(256,r1,1280),input(r6,1280)
MVC  (*)void(256,r1,1536),input(r6,1536)
LA   r1,(*)void(,r1,1792)
LA   r6,input(,r6,1792)
BRCT r0,@2L4
MVC  (*)void(256,r1,0),input(r6,0)
MVC  (*)void(256,r1,256),input(r6,256)
MVC  (*)void(256,r1,512),input(r6,512)
MVC  (*)void(256,r1,768),input(r6,768)
MVC  (*)void(16,r1,1024),input(r6,1024)

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Jim Thomas]

Folks,

Again, pardon my interruption. Two aspects (about three words I think) 
I have to relate is ... pipeline cache and (needless to add), the way 
the code (sequencing) was written. 

Jim Thomas
617-233-4130 (mobile)
636-294-1014(res)
j...@thethomasresidence.us (Email)


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of David Crayford
Sent: Tuesday, May 31, 2011 10:32 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: What is the current feeling for MVC loop vs. MVCL?

On 1/06/2011 12:13 AM, Kirk Wolf wrote:
> The IBM C compiler would generate an MVC loop.   So, that's how IBM feels
I
> guess.
>

And when the length is a constant it generates multiple MVC instructions 
to eliminate branches. Kind of like
loop unrolling.

*
*char input[528];
*
*memcpy( output, input, sizeof input );
MVC  (*)void(256,r1,0),input(r4,1508)
MVC  (*)void(256,r1,256),input(r4,1764)
MVC  (*)void(16,r1,512),input(r4,2020)

And if you increase the size of the buffer it generates a loop with loop 
unrolling (if that makes sense). There
seems to be a HWM where it drops into a loop.

*
*char input[1];
*
*memcpy( output, input, sizeof input );
LA   r0,5
LA   r6,2176(r4,)
@2L4 DS   0H
MVC  (*)void(256,r1,0),input(r6,0)
MVC  (*)void(256,r1,256),input(r6,256)
MVC  (*)void(256,r1,512),input(r6,512)
MVC  (*)void(256,r1,768),input(r6,768)
MVC  (*)void(256,r1,1024),input(r6,1024)
MVC  (*)void(256,r1,1280),input(r6,1280)
MVC  (*)void(256,r1,1536),input(r6,1536)
LA   r1,(*)void(,r1,1792)
LA   r6,input(,r6,1792)
BRCT r0,@2L4
MVC  (*)void(256,r1,0),input(r6,0)
MVC  (*)void(256,r1,256),input(r6,256)
MVC  (*)void(256,r1,512),input(r6,512)
MVC  (*)void(256,r1,768),input(r6,768)
MVC  (*)void(16,r1,1024),input(r6,1024)


> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>
> On Tue, May 31, 2011 at 8:22 AM, Binyamin
Dissen> wrote:
>> If the move is for an unknown length but is likely to be less than 256:
>>
>> Is it worth checking the length for a specific value and proceed with MVC
>> loop
>> if small enough and MVCL if large?
>>
>> --
>> Binyamin Dissen
>> http://www.dissensoftware.com
>>
>> Director, Dissen Software, Bar&  Grill - Israel
>>
>>
>> Should you use the mailblocks package and expect a response from me,
>> you should preauthorize the dissensoftware.com domain.
>>
>> I very rarely bother responding to challenge/response systems,
>> especially those from irresponsible companies.
>>
>> --
>> 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



-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1375 / Virus Database: 1509/3671 - Release Date: 05/31/11

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[David Crayford]

On 1/06/2011 12:13 AM, Kirk Wolf wrote:

The IBM C compiler would generate an MVC loop.   So, that's how IBM feels I
guess.



And when the length is a constant it generates multiple MVC instructions 
to eliminate branches. Kind of like

loop unrolling.

*
*char input[528];
*
*memcpy( output, input, sizeof input );
MVC  (*)void(256,r1,0),input(r4,1508)
MVC  (*)void(256,r1,256),input(r4,1764)
MVC  (*)void(16,r1,512),input(r4,2020)

And if you increase the size of the buffer it generates a loop with loop 
unrolling (if that makes sense). There

seems to be a HWM where it drops into a loop.

*
*char input[1];
*
*memcpy( output, input, sizeof input );
LA   r0,5
LA   r6,2176(r4,)
@2L4 DS   0H
MVC  (*)void(256,r1,0),input(r6,0)
MVC  (*)void(256,r1,256),input(r6,256)
MVC  (*)void(256,r1,512),input(r6,512)
MVC  (*)void(256,r1,768),input(r6,768)
MVC  (*)void(256,r1,1024),input(r6,1024)
MVC  (*)void(256,r1,1280),input(r6,1280)
MVC  (*)void(256,r1,1536),input(r6,1536)
LA   r1,(*)void(,r1,1792)
LA   r6,input(,r6,1792)
BRCT r0,@2L4
MVC  (*)void(256,r1,0),input(r6,0)
MVC  (*)void(256,r1,256),input(r6,256)
MVC  (*)void(256,r1,512),input(r6,512)
MVC  (*)void(256,r1,768),input(r6,768)
MVC  (*)void(16,r1,1024),input(r6,1024)



Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Tue, May 31, 2011 at 8:22 AM, Binyamin Dissen
wrote:
If the move is for an unknown length but is likely to be less than 256:

Is it worth checking the length for a specific value and proceed with MVC
loop
if small enough and MVCL if large?

--
Binyamin Dissen
http://www.dissensoftware.com

Director, Dissen Software, Bar&  Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Jim Thomas]

Forgive me for barging in midstream ... but . 

The reasons go deeper but I have not (as of yet) seen any 'official
public' documentation so I cannot comment on it.  

$MVCL - Move more than 256 bytes of storage

z/OS V1R11.0 JES2 Macros z/OS V1R10.0-V1R11.0
SA22-7536-09

Use $MVCL to generate a MVC (move character) instruction when you need to
move more than 256 bytes of storage. Use this macro instruction in high
performance areas because multiple MVCs (as created by this macro) are
faster than using an MVCL instruction.

Jim Thomas
617-233-4130 (mobile)
636-294-1014(res)
j...@thethomasresidence.us (Email)


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Rob Scott
Sent: Tuesday, May 31, 2011 6:22 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: What is the current feeling for MVC loop vs. MVCL?

One minor thing to remember that if you are dealing with lengths that are
not a multiple of 256 bytes, then the MVC loop method is going to have to
drop thru to an executed move for those remaining bytes.  This means that
you need addressability to that target of the execute instruction and
depending on the environment where your code is executing that might be a
non-trivial or non-desirable exercise. 

Dropping through to an actual  "MVCL" to move those last remaining bytes
might be a way to avoid the "EXRx,MOVE_LAST_BIT"  :-)   

Rob Scott
Lead Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Charles Mills
Sent: 31 May 2011 23:24
To: IBM-MAIN@bama.ua.edu
Subject: Re: What is the current feeling for MVC loop vs. MVCL?

Wow! Man do I stand corrected!

Sounds like an MVC loop is well worth the bother in anything where
performance *truly* matters.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Andy Coburn
Sent: Tuesday, May 31, 2011 3:10 PM
To: IBM-MAIN@bama.ua.edu
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 
R2+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=00   
EXECUTION ENVIRONMENT: LPAR=YES VM=NO   
CPU ID FROM STSI: MANUF=IBM TYPE=2098 MODEL=R03 SERIAL=000X 
VERSION CODE FROM CONVERSION TABLE= 
ROLLING 4-HOUR AVERAGE UTILIZATION IS 23 MSUS   
LPAR  IS UNCAPPED IN A 89 MSU CEC   
ADJ FACTOR 1946 ACCUM WEIGHT 6385225 TIMES ACCUM 23219  
LPAR_NAME= LPAR_ID=0003 LPAR_SIZE=89 CEC_SIZE=89 ARCH=Z/ARCHITECTURE

--
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



-
No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1375 / Virus Database: 1509/3671 - Release Date: 05/31/11

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send

Re: What is the current feeling for MVC loop vs. MVCL?

[Steve Comstock]

On 5/31/2011 6:03 PM, Paul Gilmartin wrote:

On Tue, 31 May 2011 23:22:08 +, Rob Scott wrote:


One minor thing to remember that if you are dealing with lengths that are not a 
multiple of 256 bytes, then the MVC loop method is going to have to drop thru 
to an executed move for those remaining bytes.  This means that you need 
addressability to that target of the execute instruction and depending on the 
environment where your code is executing that might be a non-trivial or 
non-desirable exercise.


Isn't there lately, or announced for the near future, a relative
form of EX?

-- gil


The EXRL (Execute Relative Long) instruction introduced with
the z10 machines.



Our four day course "z/OS Assembler Programming Part 4: z/Architecture and z/OS"
includes this instruction, as well as all the non-privileged instructions
introduced with all the zSeries machines. See

  http://www.trainersfriend.com/Assembler_%20courses/C500descrpt.htm


--

Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

* To get a good Return on your Investment, first make an investment!
  + Training your people is an excellent investment

* Try our new tool for calculating your Return On Investment
for training dollars at
  http://www.trainersfriend.com/ROI/roi.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

Re: What is the current feeling for MVC loop vs. MVCL?

[Paul Gilmartin]

On Tue, 31 May 2011 23:22:08 +, Rob Scott wrote:

>One minor thing to remember that if you are dealing with lengths that are not 
>a multiple of 256 bytes, then the MVC loop method is going to have to drop 
>thru to an executed move for those remaining bytes.  This means that you need 
>addressability to that target of the execute instruction and depending on the 
>environment where your code is executing that might be a non-trivial or 
>non-desirable exercise.
>
Isn't there lately, or announced for the near future, a relative
form of EX?

-- gil

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Andy Coburn]

< One minor thing to remember that if you are dealing with lengths that are
< not a multiple of 256 bytes, then the MVC loop method is going to have to
< drop thru to an executed move for those remaining bytes.  This means that
< you need addressability to that target of the execute instruction and  
< depending on the environment where your code is executing that might be a
< non-trivial or non-desirable exercise. 

My MVC loop included the executed last move of the final 256 bytes, so my
timings include these instructions. In my case I had addressability to the
instructions but I agree with Rob that this might be an issue.   

Andy Coburn 

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Rob Scott]

One minor thing to remember that if you are dealing with lengths that are not a 
multiple of 256 bytes, then the MVC loop method is going to have to drop thru 
to an executed move for those remaining bytes.  This means that you need 
addressability to that target of the execute instruction and depending on the 
environment where your code is executing that might be a non-trivial or 
non-desirable exercise. 

Dropping through to an actual  "MVCL" to move those last remaining bytes might 
be a way to avoid the "EXRx,MOVE_LAST_BIT"  :-)   

Rob Scott
Lead Developer
Rocket Software
275 Grove Street * Newton, MA 02466-2272 * USA
Tel: +1.617.614.2305
Email: rsc...@rs.com
Web: www.rocketsoftware.com


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Charles Mills
Sent: 31 May 2011 23:24
To: IBM-MAIN@bama.ua.edu
Subject: Re: What is the current feeling for MVC loop vs. MVCL?

Wow! Man do I stand corrected!

Sounds like an MVC loop is well worth the bother in anything where performance 
*truly* matters.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of 
Andy Coburn
Sent: Tuesday, May 31, 2011 3:10 PM
To: IBM-MAIN@bama.ua.edu
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 
R2+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=00   
EXECUTION ENVIRONMENT: LPAR=YES VM=NO   
CPU ID FROM STSI: MANUF=IBM TYPE=2098 MODEL=R03 SERIAL=000X 
VERSION CODE FROM CONVERSION TABLE= 
ROLLING 4-HOUR AVERAGE UTILIZATION IS 23 MSUS   
LPAR  IS UNCAPPED IN A 89 MSU CEC   
ADJ FACTOR 1946 ACCUM WEIGHT 6385225 TIMES ACCUM 23219  
LPAR_NAME= LPAR_ID=0003 LPAR_SIZE=89 CEC_SIZE=89 ARCH=Z/ARCHITECTURE

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Paul Gilmartin]

On Tue, 31 May 2011 18:10:11 -0400, Andy Coburn  wrote:

>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.
>   ...
>
Is this affected by operand alignment?

Extending the topic somewhat: I understand that (model
sensitive?) there's an enormous penalty for off-boundary
RX instructions.  A frequent use of LH/STH might be
accessing RDWs where the programmer can't control the
alignment.  So, assuming half the RDWs are misaligned, is
it best to:

LH and endure the penalty

or:

XR
IC
SLL
IC

or:

MVC to an aligned buffer
LH

In the latter two cases, is it better to test the
address and LH if even?

S/370's introduction of unaligned operations seems to be
contrary to the trend du jour toward RISC architecture.

-- gil

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Chip Grantham]

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:  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:  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  
Sent by: IBM Mainframe Discussion List 
05/31/2011 05:12 PM
Please respond to
IBM Mainframe Discussion List 


To
IBM-MAIN@bama.ua.edu
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=00 
EXECUTION ENVIRONMENT: LPAR=YES VM=NO 
CPU ID FROM STSI: MANUF=IBM TYPE=2098 MODEL=R03 SERIAL=000X 
VERSION CODE FROM CONVERSION TABLE= 
ROLLING 4-HOUR AVERAGE UTILIZATION IS 23 MSUS 
LPAR  IS UNCAPPED IN A 89 MSU CEC 
ADJ FACTOR 1946 ACCUM WEIGHT 6385225 TIMES ACCUM 23219 
LPAR_NAME= 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

Re: What is the current feeling for MVC loop vs. MVCL?

[Gerhard Postpischil]

On 5/31/2011 5:22 PM, Gibney, Dave wrote:

As I am led to understand it, under the covers in the millicode MVCL
really is a MVC loop. So MVCL is at least slower by the cost of overhead
switching into the millicode environment.


On all the machines I tried it, with fixed length 256 byte moves 
versus MVCL, MVCL was faster for a total length larger than 1K 
(370 and 43x1) or 4K (more recent). Test were on an (otherwise) 
idle machine. My guess is that MVCL has less setup overhead 
compared to multiple MVCs?



That said, and if I was coding anything which I'm not these days, I'd
likely do the MVCL and be done with it unless I knew it was a very
frequently executed path in the code.


Agreed; and I make use of the updated addresses, and the padding 
is nice.


In answer to Mike Schwab: back in the seventies we had customers 
for our software using both 360 and 370 machines, and assorted 
systems (MFT, MVT, SVS, MVS). As much of the code as possible 
tested the environment and adjusted; for many cases, I used 
conditional assembly. One such case was an LMVC macro that 
either expanded an MVC loop or one MVCL.


Gerhard Postpischil
Bradford, VT

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Farley, Peter x23353]

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:IBM-MAIN@bama.ua.edu] On
> Behalf Of Andy Coburn
> Sent: Tuesday, May 31, 2011 6:10 PM
> To: IBM-MAIN@bama.ua.edu
> 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=00
> EXECUTION ENVIRONMENT: LPAR=YES VM=NO
> CPU ID FROM STSI: MANUF=IBM TYPE=2098 MODEL=R03 SERIAL=000X
> VERSION CODE FROM CONVERSION TABLE=
> ROLLING 4-HOUR AVERAGE UTILIZATION IS 23 MSUS
> LPAR  IS UNCAPPED IN A 89 MSU CEC
> ADJ FACTOR 1946 ACCUM WEIGHT 6385225 TIMES ACCUM 23219
> LPAR_NAME= 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: What is the current feeling for MVC loop vs. MVCL?

[Charles Mills]

Wow! Man do I stand corrected!

Sounds like an MVC loop is well worth the bother in anything where
performance *truly* matters.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Andy Coburn
Sent: Tuesday, May 31, 2011 3:10 PM
To: IBM-MAIN@bama.ua.edu
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 
R2+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=00   
EXECUTION ENVIRONMENT: LPAR=YES VM=NO   
CPU ID FROM STSI: MANUF=IBM TYPE=2098 MODEL=R03 SERIAL=000X 
VERSION CODE FROM CONVERSION TABLE= 
ROLLING 4-HOUR AVERAGE UTILIZATION IS 23 MSUS   
LPAR  IS UNCAPPED IN A 89 MSU CEC   
ADJ FACTOR 1946 ACCUM WEIGHT 6385225 TIMES ACCUM 23219  
LPAR_NAME= LPAR_ID=0003 LPAR_SIZE=89 CEC_SIZE=89 ARCH=Z/ARCHITECTURE

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Charles Mills]

That was the conclusion apparently last time around:
http://groups.google.com/group/bit.listserv.ibm-main/browse_thread/thread/5f
59748279c428bc/fee5e1d477452dfb 

I certainly agree with your second paragraph. It would have to be mighty
repetitive code for me to worry about this.

You could carry this to any length you wanted. If you knew you were dealing
fewer than 4096 bytes you could avoid the MVC *loop* by having a branch
table based on length/256 that took you to:

Move256to512 EQU *
 MVC   TO(256),FROM
 B ExecuteLogic
*
Move512to758 EQU *
 MVC   TO(256),FROM
 MVC   TO+256(256),FROM+256
 B ExecuteLogic
*
Move758to1024 EQU *
 MVC   TO(256),FROM
 MVC   TO+256(256),FROM+256
 MVC   TO+512(256),FROM+512
 B ExecuteLogic
*
Etc.

Charles

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf
Of Gibney, Dave
Sent: Tuesday, May 31, 2011 2:22 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: What is the current feeling for MVC loop vs. MVCL?

As I am led to understand it, under the covers in the millicode MVCL really
is a MVC loop. So MVCL is at least slower by the cost of overhead switching
into the millicode environment.

That said, and if I was coding anything which I'm not these days, I'd likely
do the MVCL and be done with it unless I knew it was a very frequently
executed path in the code.

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Andy Coburn]

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=00   
EXECUTION ENVIRONMENT: LPAR=YES VM=NO   
CPU ID FROM STSI: MANUF=IBM TYPE=2098 MODEL=R03 SERIAL=000X 
VERSION CODE FROM CONVERSION TABLE= 
ROLLING 4-HOUR AVERAGE UTILIZATION IS 23 MSUS   
LPAR  IS UNCAPPED IN A 89 MSU CEC   
ADJ FACTOR 1946 ACCUM WEIGHT 6385225 TIMES ACCUM 23219  
LPAR_NAME= 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

Re: What is the current feeling for MVC loop vs. MVCL?

[Gibney, Dave]

As I am led to understand it, under the covers in the millicode MVCL
really is a MVC loop. So MVCL is at least slower by the cost of overhead
switching into the millicode environment.

That said, and if I was coding anything which I'm not these days, I'd
likely do the MVCL and be done with it unless I knew it was a very
frequently executed path in the code.

Dave Gibney
Information Technology Services
Washington State University


> -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

Re: What is the current feeling for MVC loop vs. MVCL?

[Charles Mills]

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

Re: What is the current feeling for MVC loop vs. MVCL?

[Mike Schwab]

How about a macro to replace MVCL with a loop using the same registers
but using MVC?  Anyone ever write one?

On Tue, May 31, 2011 at 2:49 PM, Binyamin Dissen
 wrote:
> On Tue, 31 May 2011 19:23:46 +0300 Itschak Mugzach  wrote:
>
> :>I believe MVCL is less efficient as it is *interruptible* (has to update 4
> :>GPRs) while MVC does this internally, does not change GPR's values and is
> :>not interruptible.
>
> If the move is of an uncertain length, one would need to play with three
> registers in-line. And of course there is the conditional branch and possible
> last EX of an MVC.
-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Binyamin Dissen]

On Tue, 31 May 2011 19:23:46 +0300 Itschak Mugzach  wrote:

:>I believe MVCL is less efficient as it is *interruptible* (has to update 4
:>GPRs) while MVC does this internally, does not change GPR's values and is
:>not interruptible.

If the move is of an uncertain length, one would need to play with three
registers in-line. And of course there is the conditional branch and possible
last EX of an MVC.

:>On Tue, May 31, 2011 at 7:13 PM, Kirk Wolf  wrote:

:>> The IBM C compiler would generate an MVC loop.   So, that's how IBM feels I
:>> guess.

:>> Kirk Wolf
:>> Dovetailed Technologies
:>> http://dovetail.com

:>> On Tue, May 31, 2011 at 8:22 AM, Binyamin Dissen <
:>> bdis...@dissensoftware.com
:>> > wrote:

:>> > If the move is for an unknown length but is likely to be less than 256:

:>> > Is it worth checking the length for a specific value and proceed with MVC
:>> > loop
:>> > if small enough and MVCL if large?

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Rick Fochtman]

--


If the move is for an unknown length but is likely to be less than 256:

Is it worth checking the length for a specific value and proceed with MVC loop
if small enough and MVCL if large?
 


---
Unless I have to play a lot of silly games, saving and restoring some 
registers, I just use the MVCL in all cases.


Rick

--
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

Re: What is the current feeling for MVC loop vs. MVCL?

[Itschak Mugzach]

I believe MVCL is less efficient as it is *interruptible* (has to update 4
GPRs) while MVC does this internally, does not change GPR's values and is
not interruptible.

ITschak

On Tue, May 31, 2011 at 7:13 PM, Kirk Wolf  wrote:

> The IBM C compiler would generate an MVC loop.   So, that's how IBM feels I
> guess.
>
> Kirk Wolf
> Dovetailed Technologies
> http://dovetail.com
>
> On Tue, May 31, 2011 at 8:22 AM, Binyamin Dissen <
> bdis...@dissensoftware.com
> > wrote:
>
> > If the move is for an unknown length but is likely to be less than 256:
> >
> > Is it worth checking the length for a specific value and proceed with MVC
> > loop
> > if small enough and MVCL if large?
> >
> > --
> > Binyamin Dissen 
> > http://www.dissensoftware.com
> >
> > Director, Dissen Software, Bar & Grill - Israel
> >
> >
> > Should you use the mailblocks package and expect a response from me,
> > you should preauthorize the dissensoftware.com domain.
> >
> > I very rarely bother responding to challenge/response systems,
> > especially those from irresponsible companies.
> >
> > --
> > 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

Re: What is the current feeling for MVC loop vs. MVCL?

[Kirk Wolf]

The IBM C compiler would generate an MVC loop.   So, that's how IBM feels I
guess.

Kirk Wolf
Dovetailed Technologies
http://dovetail.com

On Tue, May 31, 2011 at 8:22 AM, Binyamin Dissen  wrote:

> If the move is for an unknown length but is likely to be less than 256:
>
> Is it worth checking the length for a specific value and proceed with MVC
> loop
> if small enough and MVCL if large?
>
> --
> Binyamin Dissen 
> http://www.dissensoftware.com
>
> Director, Dissen Software, Bar & Grill - Israel
>
>
> Should you use the mailblocks package and expect a response from me,
> you should preauthorize the dissensoftware.com domain.
>
> I very rarely bother responding to challenge/response systems,
> especially those from irresponsible companies.
>
> --
> 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

What is the current feeling for MVC loop vs. MVCL?

[Binyamin Dissen]

If the move is for an unknown length but is likely to be less than 256:

Is it worth checking the length for a specific value and proceed with MVC loop
if small enough and MVCL if large?

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
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