Oh, now i see what Bernd was talking about, sorry guys , old age Scott ford www.identityforge.com
On May 16, 2012, at 4:53 PM, Scott Ford <[email protected]> wrote: > Guys, > > A little lost on the point of this thread , not trying be rude or flippant , > just I see a lot about performance, is it valid with today's hardware and > software, yes there is time sensitive events and software and hardware. > > Scott ford > www.identityforge.com > > On May 16, 2012, at 4:35 PM, Mike Schwab <[email protected]> wrote: > >> The Hercules group did some testing comparing MVCL to MVC. >> If both source and destination had the same alignment to a double word >> boundary, you could move 8 bytes, then increment the 4 registers to >> reflect this, before being interuptable. If they aligned differently >> between boundaries, each 8 bytes would do this twice. >> >> Whereas an MVC would do 256 bytes or less without interupting or >> touching registers, and was much faster. >> >> Of course, emulation is much different from hardware, ie, updating all >> 4 registers at once. >> >> On Wed, May 16, 2012 at 2:41 PM, Bernd Oppolzer >> <[email protected]> wrote: >>> First, I would like to thank you for starting this thread. >>> >>> I posted it to the performance people of my customer, and they told me, that >>> they just found a similar problem with EP PL/1 3.9, that is: the PLIMOVE >>> calls >>> don't generate MVCLs any more, as in previous releases, but series of MVCs >>> and loops. Even when the length of PLIMOVE is - for example - 8000 bytes. >>> They discovered it, because one of the PLIMOVE locations showed up in a >>> Strobe report. >>> >>> I asked them to test using a ASSEMBLER program, if the MVC loop is faster, >>> but they told me, that even with lengths around 500 or 600, the MVCL >>> solution is faster >>> - this is on a z196. I have still to confirm this. >>> >>> If this turns out to be true, this sounds like a bug, and we will try to >>> convince IBM to go back to >>> the previous solution. If we compile our modules during normal service using >>> EP PL/1 3.9, >>> our system will get slower and slower, because PLIMOVE is widely used. >>> This is not acceptable. >>> >>> Because the PLIMOVEs are generated by a site-specific macro called PLICOPY, >>> I already thought about calling a short ASSEMBLER routine (with minimal >>> linkage conventions) >>> doing the transfer using MVCL instead of CALL PLIMOVE. The applications need >>> not >>> to be changed, because the PLICOPY syntax stays the same. Maybe this could >>> still be >>> faster than doing the MVC loop. >>> >>> Kind regards >>> >>> Bernd >> >> >> -- >> 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 [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
