Re: The speed of the 64 bit code
It seems to me that LMD would only be required if in AMODE 64 and needing to restore the base register for the storage location where the low halves are stored. JES2 (1.7 and 1.9, at least) uses LMD routinely in it's $SAVE macro and in the subroutine called by the $RETURN macro. These two macros are used by the vast majority of subroutines. Since this code all runs in AMODE 31, I don't understand why they don't use the LMH/LM sequence recommended. Bill "Jim Mulder" wrote in message news:. .. > > That's why LMD has the following Programming Note: > > 3. The combination of a LOAD MULTIPLE instruction > and a LOAD MULTIPLE HIGH instruction > provides equal or better performance than a > LOAD MULTIPLE DISJOINT instruction for the > same register range. LOAD MULTIPLE DIS- > JOINT is for use when the second or fourth operand > must be addressed by means of one of the > registers loaded. > > 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 -- 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: The speed of the 64 bit code
Jim Mulder wrote: That's why LMD has the following Programming Note: 3. The combination of a LOAD MULTIPLE instruction and a LOAD MULTIPLE HIGH instruction provides equal or better performance than a LOAD MULTIPLE DISJOINT instruction for the same register range. LOAD MULTIPLE DIS- JOINT is for use when the second or fourth operand must be addressed by means of one of the registers loaded. Yeah. Once you restore the high-halves in 64-bit mode using LMH, you're potentially unable to issue the LM to restore the low halves--and vice versa. We had to do some slightly "tricky" stuff to do what we needed to do without LMD. It was well worth it. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 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: The speed of the 64 bit code
IBM Mainframe Discussion List wrote on 04/15/2009 01:05:34 PM: > >> We did that and found *one* instruction that was so slow, and > executed so often, it brought our product to its "knees". > >> > > > > Please name and shame the instruction > > > > LMD. We used it in an unstack routine, that had been updated to support > AMODE(64) execution, without understanding just how slow it was (and how > often we executed it). Code got into the field for early testing and > customers complained. A product called STROBE pointed to the 64-byte > block containing this instruction. We replaced it with other > instructions and the problem was resolved. That's why LMD has the following Programming Note: 3. The combination of a LOAD MULTIPLE instruction and a LOAD MULTIPLE HIGH instruction provides equal or better performance than a LOAD MULTIPLE DISJOINT instruction for the same register range. LOAD MULTIPLE DIS- JOINT is for use when the second or fourth operand must be addressed by means of one of the registers loaded. 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: The speed of the 64 bit code
Daniel McLaughlin wrote: HIS? Honeywell Information Systems running GECOS? z/OS Hardware Instrumentation Services. (Also mentioned in my SHARE in Austin z10 User Experience.) -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 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: The speed of the 64 bit code
Rob Scott wrote: Ed OK, I will bite... We did that and found *one* instruction that was so slow, and executed so often, it brought our product to its "knees". Please name and shame the instruction LMD. We used it in an unstack routine, that had been updated to support AMODE(64) execution, without understanding just how slow it was (and how often we executed it). Code got into the field for early testing and customers complained. A product called STROBE pointed to the 64-byte block containing this instruction. We replaced it with other instructions and the problem was resolved. Unfortunately, instruction timing is a moving target. In recent years, some other instructions we use have become very slow. For example, EX/NOPR has gone from 15 times as slow as LA on z9 to 95 times as slow as LA on z10. (See my SHARE in Austin z10 User Experience for details.) -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 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: The speed of the 64 bit code
Rob, I will put in my guess here: MVCL I have had all too many encounters with that one lately during batch application CPU-time reduction efforts. Peter > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Rob Scott > Sent: Wednesday, April 15, 2009 12:34 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: The speed of the 64 bit code > > Ed > > OK, I will bite... > > >We did that and found *one* instruction that was so slow, and executed so > often, it brought our product to its "knees". > > Please name and shame the instruction 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: The speed of the 64 bit code
Ed OK, I will bite... >We did that and found *one* instruction that was so slow, and executed so >often, it brought our product to its "knees". Please name and shame the instruction Rob Scott 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-m...@bama.ua.edu] On Behalf Of Edward Jaffe Sent: 15 April 2009 16:08 To: IBM-MAIN@bama.ua.edu Subject: Re: The speed of the 64 bit code Miklos Szigetvari wrote: > We have converted our complex C++ document generation application to > 64 bit mode. > With different test cases, we see the average CPU time is about 4% > higher in 64 bit mode as in 32, This is not an altogether unexpected outcome. There are many possible reasons: your programs and data areas might be larger--thus taking longer to load/move/page, address translation involving a region 3rd will be slower than segment-only translation (imagine what would happen with region 2nd--stay below 4TB!), and so forth. All code might not be apples to apples either. For example, if any service you're calling uses BAKR for 64-bit callers, yet traditional STM/LAM, STAM/LAM, for 31-bit callers, it will run noticeably slower. It might be worth using HIS or a commercial execution analyzer product to look for program "hot spots". We did that and found *one* instruction that was so slow, and executed so often, it brought our product to its "knees". Replacing that one instruction with a multi-instruction equivalent made the performance problem disappear. (Of course, this was an assembler language program. You might not have as much control with C++ over such things. But, the analysis can still be valuable.) -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 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 -- 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: The speed of the 64 bit code
HIS? Honeywell Information Systems running GECOS? Daniel McLaughlin Z-Series Systems Programmer Information & Communications Technology Crawford & Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 cell: 770-666-7969 email: daniel_mclaugh...@us.crawco.com web: www.crawfordandcompany.com Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- 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: The speed of the 64 bit code
Que'est-que c'est "HIS"? Horrible name to Google for, of course. I'm guessing it's a HIStogram generator of some sort? On Wed, Apr 15, 2009 at 11:08 AM, Edward Jaffe wrote: > Miklos Szigetvari wrote: >> >> We have converted our complex C++ document generation application to 64 >> bit mode. >> With different test cases, we see the average CPU time is about 4% >> higher in 64 bit mode as in 32, > > This is not an altogether unexpected outcome. There are many possible > reasons: your programs and data areas might be larger--thus taking longer to > load/move/page, address translation involving a region 3rd will be slower > than segment-only translation (imagine what would happen with region > 2nd--stay below 4TB!), and so forth. All code might not be apples to apples > either. For example, if any service you're calling uses BAKR for 64-bit > callers, yet traditional STM/LAM, STAM/LAM, for 31-bit callers, it will run > noticeably slower. > > It might be worth using HIS or a commercial execution analyzer product to > look for program "hot spots". We did that and found *one* instruction that > was so slow, and executed so often, it brought our product to its "knees". > Replacing that one instruction with a multi-instruction equivalent made the > performance problem disappear. (Of course, this was an assembler language > program. You might not have as much control with C++ over such things. But, > the analysis can still be valuable.) > > -- > Edward E Jaffe > Phoenix Software International, Inc > 5200 W Century Blvd, Suite 800 > Los Angeles, CA 90045 > 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 > -- 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: The speed of the 64 bit code
Miklos Szigetvari wrote: We have converted our complex C++ document generation application to 64 bit mode. With different test cases, we see the average CPU time is about 4% higher in 64 bit mode as in 32, This is not an altogether unexpected outcome. There are many possible reasons: your programs and data areas might be larger--thus taking longer to load/move/page, address translation involving a region 3rd will be slower than segment-only translation (imagine what would happen with region 2nd--stay below 4TB!), and so forth. All code might not be apples to apples either. For example, if any service you're calling uses BAKR for 64-bit callers, yet traditional STM/LAM, STAM/LAM, for 31-bit callers, it will run noticeably slower. It might be worth using HIS or a commercial execution analyzer product to look for program "hot spots". We did that and found *one* instruction that was so slow, and executed so often, it brought our product to its "knees". Replacing that one instruction with a multi-instruction equivalent made the performance problem disappear. (Of course, this was an assembler language program. You might not have as much control with C++ over such things. But, the analysis can still be valuable.) -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 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
The speed of the 64 bit code
Hi We have converted our complex C++ document generation application to 64 bit mode. With different test cases, we see the average CPU time is about 4% higher in 64 bit mode as in 32, but there are test cases, the CPU usage is 8-10% less, so here the 64 bit code faster as the 32 bit code. Any explanation about this ? . -- Miklos Szigetvari Development Team ISIS Information Systems Gmbh tel: (+43) 2236 27551 570 Fax: (+43) 2236 21081 E-mail: miklos.szigetv...@isis-papyrus.com Info: i...@isis-papyrus.com Hotline: +43-2236-27551-111 Visit our Website: http://www.isis-papyrus.com --- This e-mail is only intended for the recipient and not legally binding. Unauthorised use, publication, reproduction or disclosure of the content of this e-mail is not permitted. This email has been checked for known viruses, but ISIS accepts no responsibility for malicious or inappropriate content. --- -- 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
