I would like to add: with the previous compiler, CALL PLIMOVE enabled us to force the generation of MVCL.
Using, for example CALL PLIMOVE (ADDR (target), ADDR (source), length); the compiler generated MVCL, but coding target = source; (if applicable), or BY-NAME-assignments, the compile generated MVCs etc. Now, with V3.9, the compiler generates the same in the two cases, that is MVCs or MVC loops, so we have no possibility to force the generation of MVCL. AFAIK, my co-workers didn't play with the ARCH options, so far. TUNE is TUNE(2), again AFAIK. I have other projects at the moment, so I had not much time so far to investigate this. But remember: the problem showed up by a Strobe Report, so it seems to be significant. But: if PLIMOVE does no better than a simple assignment, using PLIMOVE seems to make no sense to me. In a certain way, this problem is somewhat different from the first problem in this thread. Robert complained about the optimizer doing a bad job, that is: some instructions are generated that are useless, and others are questionable. But here we have a simple instruction of the HLL (PLIMOVE) which I expect to be implemented using the best instructions the machine provides. If this turns out not to be the case, this is IMHO simply a bug, not only a flaw of the optimizer. The programmer already did some kind of optimization him- or herself, when he or she decided to use PLIMOVE. He or she may well expect that the compiler generates the best available machine instruction for this HLL instruction. Kind regards Bernd Am Mittwoch, 16. Mai 2012 21:41 schrieb Bernd Oppolzer: > 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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
