On 22 Mar 2007 09:46:56 -0700, in bit.listserv.ibm-main you wrote: >On Wed, 21 Mar 2007 17:23:35 -0500, Rick Fochtman wrote: > >>------------------------<snip>-------------------- >>We're on a z9BC. >> >>We've got some other code changes in the process that I'm trying to >>isolate from the ARITH(EXTEND) impact to see if this is really 30% >>attributable to the ARITH option change. I'd still be interested in >>hearing what others have experienced in reality. We seem to be in the >>upper range of IBM's performance impact analysis. Are you ???
If all intermediate results expand to 63 digits, the multiple instructions to handle the computation can get messy. I would like to see an execute like instruction for packed data that would allow the ability to increase field sizes to at least 32 bytes. >>-----------------------<unsnip>----------------------- >>I'm curious: how much difference in overall run time either with or >>without the "RENT" compiler option? >> > >I don't know. I'm trying to arrange to recompile without EXTEND and test. I'll >see if I can throw in a RENT/NORENT test too. I would hope they're all >compiled RENT now (I'd expect best results from RENT), but it's in >development right now so it's hard to say how the programs are compiled or >even if they're compiled with a consistent set of options. > NORENT may allow the Working Storage Section to be in the programs CSECT thus all VALUE clauses would become DC at compile rather than an additional GETMAIN for the Working Storage Section followed by individual moves to initialize all fields with VALUE clauses at execution time. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
