Re: Dataspace versus common area above the bar
The hardware designer Jim Mulder quotes says begin extract I assume the AMODE(31) and AMODE(64) he is referring to only affects the addressing mode, but the exact same instruction sequences are used in both cases. If different code sequences are being used, then all bets are off. /end extract thus disposing neatly of a straw man. It is of course possible to write snippets of code using only modal instructions in such a way that the exact same instruction sequences are used in both cases; but it is almost never appropriate to do so; and I did not do, or say that I had done, that. Let me also take this opportunity to respond to Kenneth Wilkerson, who has a weakness for the sententious. He informs us that algorithms are more important than code sequences. I think it may be conceded out of hand that binary search is faster than linear search and again that linear search of an ordered list implemented as a glb-seeking or lub-seeking one followed by a test of any bound found for equality is faster that the two-tests-per-iteration schemes my students sometimes come up with. (Knuth pointed this out many years ago.) More generally, logarithmic-time schemes are faster than polynomial-time ones, etc., etc . It is nevertheless possible to implement algorithms correctly but badly, and coding effects and algorithmic effects are often difficult or even impossible to disentangle. As sometimes happens here, we are talking at cross purposes and generating more heat than light in doing so. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
This thread has been curiously silent about one characteristic of routines/instructions executed above the bar. Unsurprisingly, they are measurably faster than their analogues executed below it. z/Architecture is 64-bit architecture From subsequent appends, I know that, despite what John wrote, he was not referring to RMODE. It is not true that instructions executed above the bar execute faster than the same instructions executed below the bar As Jim Mulder wrote, if you are using the same instructions, AMODE does not matter. As far as I recall (and I'm not even sure it is still true), there is one instruction that was implemented to be faster in AMODE 64 than AMODE 31. That is LG. And, similarly (or conversely), L is faster in AMODE 31. There is (or at least was) special hardware implemented to help. I've heard it referred to as a load bypass. The fact that z/Architecture is a 64-bit architecture (actually, I'd say it's a hybrid architecture in that regard) has relatively little relevance to the speed. For example, STM is faster in saving 4-byte regs than STMG is in saving 8-byte regs. To a significant extent, it's just a question of the amount of data being moved. Getting back to the OP's original question, many find programming AMODE 64 to be simpler than programming AR mode. If using most high level languages this would be true if for no other reason than that many such languages do not even support AR mode. Still, it is a fact that there likely are a lot more services in z/OS that support AR mode callers (and parameter data in data spaces) than that support AMODE 64 callers (let alone data above the bar). That's not something to be proud of, but it is a practical reality. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
On 1/22/2014 12:57 AM, Itschak Mugzach wrote: 64 bit addressing execution is faster if less access to real memory is required to fetch the next instruction. This is what quadword promise, is'It? the performance gain is also depend on the logic of the program (if commands sequenced well with less brunch instructions). ITschak Yes, I can see where brunch would slow things down. Almost makes one sleepy now ... :-) -Steve On Wed, Jan 22, 2014 at 5:30 AM, Jim Mulder d10j...@us.ibm.com wrote: One caveat to that statement is as follows, from the POps: The performance of CDSG on some models may be significantly slower than that of CSG. WHEN QUADWORD CONSISTENCY IS NOT REQUIRED BY THE PROGRAM, alternate code sequences should be used. (my caps) CDSG was implemented in millicode on the z900, z800, z990, z890, and z9 machines. It was moved to hardware on the z10 and later machines. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
On Wed, Jan 22, 2014 at 6:58 AM, Steve Comstock st...@trainersfriend.comwrote: On 1/22/2014 12:57 AM, Itschak Mugzach wrote: 64 bit addressing execution is faster if less access to real memory is required to fetch the next instruction. This is what quadword promise, is'It? the performance gain is also depend on the logic of the program (if commands sequenced well with less brunch instructions). ITschak Yes, I can see where brunch would slow things down. Almost makes one sleepy now ... :-) -Steve Ah, our machine is old and so doesn't implement the brunch instruction. But it seems to have a coffee break sequence in the microcode. I.e. it is knee capped. GRIN/ -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
Well, I don't know about your coffee, but if the next instruction is not in the high speed buffer... it is time for a coffee break for your processor ;-) On Wed, Jan 22, 2014 at 3:53 PM, John McKown john.archie.mck...@gmail.comwrote: On Wed, Jan 22, 2014 at 6:58 AM, Steve Comstock st...@trainersfriend.com wrote: On 1/22/2014 12:57 AM, Itschak Mugzach wrote: 64 bit addressing execution is faster if less access to real memory is required to fetch the next instruction. This is what quadword promise, is'It? the performance gain is also depend on the logic of the program (if commands sequenced well with less brunch instructions). ITschak Yes, I can see where brunch would slow things down. Almost makes one sleepy now ... :-) -Steve Ah, our machine is old and so doesn't implement the brunch instruction. But it seems to have a coffee break sequence in the microcode. I.e. it is knee capped. GRIN/ -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
I detect here a hint of confusion: The choice of 64-bit memory addressing is independent of the choice of size of individual data objects and independent of the width of internal hardware data paths either within the processor or to/from memory or I/O channels. The only thing to which 64-bit addressing is directly related is the total amount of storage that may be addressed. Even before z-architecture and the introduction of 64-bit addressing there were z-architecture-predecessor machines with only 31-bit addressing that employed 128-bit in parallel or possibly even wider internal data transfers between real memory and high-speed cache in order to achieve the desired performance. The frequency of access to real memory and number of bytes transferred per access to and from the processor and to and from high speed cache is mainly a cost-performance hardware design issue for a specific hardware model and not tied to the number of bits in a memory address. I would expect the fetch time for the same sequence of instructions on the same model processor to be independent of run-time address mode. Joel C. Ewing On 01/22/2014 01:57 AM, Itschak Mugzach wrote: 64 bit addressing execution is faster if less access to real memory is required to fetch the next instruction. This is what quadword promise, is'It? the performance gain is also depend on the logic of the program (if commands sequenced well with less brunch instructions). ITschak On Wed, Jan 22, 2014 at 5:30 AM, Jim Mulder d10j...@us.ibm.com wrote: One caveat to that statement is as follows, from the POps: The performance of CDSG on some models may be significantly slower than that of CSG. WHEN QUADWORD CONSISTENCY IS NOT REQUIRED BY THE PROGRAM, alternate code sequences should be used. (my caps) CDSG was implemented in millicode on the z900, z800, z990, z890, and z9 machines. It was moved to hardware on the z10 and later machines. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- Joel C. Ewing,Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
On 22/01/2014 23:35, John Gilmore wrote: It is of course possible to write snippets of code using only modal instructions in such a way that the exact same instruction sequences are used in both cases; but it is almost never appropriate to do so; and I did not do, or say that I had done, that. Your original statement was one characteristic of routines/instructions executed above the bar [is] they are measurably faster than their analogues executed below it. I think most people would assume that you were referring to the same code, and the critical point was whether it was above/below the bar - or at most the AMODE or RMODE. If you are saying you can write faster code using 64 bit instructions I would expect it is possible. I would also expect it is possible to write slower code. Measured differences are not necessarily inherent characteristics of 64 bit instructions if the code is changed. With code changes, a few percent change in speed could easily be caused by e.g. a resulting difference in branch prediction rather than inherently faster instructions. You can't draw a conclusion about what made the code faster. As the hardware person said, All bets are off. In fact, I suspect (but don't actually know) that real-world code might be slightly slower using 64 bit instructions because larger data and operands make less effective use of processor cache. I think it may be conceded out of hand that binary search is faster than linear search Even that I'm not sure is universally true. I suspect processor branch prediction is difficult for binary search, so a linear search where branches are predictable may be better for small lists. Where the cutoff is I don't know. I have seen a (non-z/OS) example where randomizing the data to defeat branch prediction made the same code take 6x longer. One hypothesis to test might be that linear search would be faster if the average number of comparisons was less than ~5 times the number required for binary search. Comparing the speed of actual instructions is not very useful. The sequence of instructions is more important, and specifically their effect on processor cache, pipeline and branch prediction (plus other factors I'm sure). Regards Andrew Rowley -- and...@blackhillsoftware.com +61 413 302 386 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
That's not something to be proud of, but it is a practical reality. IMHO, that's likewise not something to be ashamed of. It simply proves that the large majority of application have no need for storage above the bar. It's mainly something for programs and subsystems that gain performance boosts by being able to keep more data in storage. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
I'd just like to thank you all for the superb responses you given to my question. It really has been a great help. Bye for now, John. On 21 January 2014 00:43, Kenneth Wilkerson redb...@austin.rr.com wrote: Because I've used memory objects for so long, I have not had a reason for IARVSERV. I read both the description in the macro reference and in the authorized assembler guide and there seems to be a ton of restrictions and quirks (such as TPROT). The most notable restriction is the sharing limit of 16 pages for an unauthorized address space. However, this limit can be changed. But because of the ESQA considerations created because the page tables can map different virtual address for the shared pages, I'm not sure what would be a practical limit. It does appear to address guard and to some extent page protection . It also offers the ability to share 31 bit storage with 24 bit applications (a key point). Shared and common memory objects do not have any of IARVSERV restrictions and do not change my conclusion that performance is NOT the reason to convert to a memory object. It's the advanced functionality. One reason I use a common memory object is so I can avoid using CSA and SQA particularly for code. With the 16 page restriction it would be impractical to share code with IARVSERV. And common data spaces cannot execute code. There are no limits to the flexibility offered by memory objects. I can share any number of pages. With shared memory objects I can determine which address spaces have access and which do not. With common memory I can create my own CSA and even SQA with some restrictions. As Jim affirmed, there is probably little if any performance difference between data spaces and memory objects. Chose the one best suited to your architecture. Kenneth -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Monday, January 20, 2014 4:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Fw: Dataspace versus common area above the bar Memory objects are much more flexible than data spaces. Data spaces are limited to 2GB. Memory objects are only limited by the auxiliary storage. Memory objects can be guarded and can also be page protected. Data spaces cannot. Code can execute in memory object but not in data spaces. I started using memory objects 10 years ago and have nearly forgotten how to use a data space. Guard pages and protected pages can be created in data spaces using IARV64 with TAGET_VIEW=HIDDEN and TARGET_VIEW=READONLY I meant IARVSERV, not IARV64 Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- John Blythe Reid, Técnico de Sistemas de z/OS y de Sistemas Transaccionales, Barcelona, España. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
One other consideration is that a data space is limited to a size of 2GB, but virtual storage above the bar can be MUCH, MUCH larger. Bill Fairchild Nolensville, TN - Original Message - From: John Blythe Reid johnblyther...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, January 20, 2014 9:02:55 AM Subject: Re: Dataspace versus common area above the bar -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
More on flexibility: Storage above the bar can be set to specific storage keys when being acquired, and can use page table entries that map 1MB per entry rather than 4KB per entry. Bill Fairchild Nolensville, TN - Original Message - From: Kenneth Wilkerson redb...@austin.rr.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Monday, January 20, 2014 5:43:10 PM Subject: Re: Dataspace versus common area above the bar Because I've used memory objects for so long, I have not had a reason for IARVSERV. I read both the description in the macro reference and in the authorized assembler guide and there seems to be a ton of restrictions and quirks (such as TPROT). The most notable restriction is the sharing limit of 16 pages for an unauthorized address space. However, this limit can be changed. But because of the ESQA considerations created because the page tables can map different virtual address for the shared pages, I'm not sure what would be a practical limit. It does appear to address guard and to some extent page protection . It also offers the ability to share 31 bit storage with 24 bit applications (a key point). Shared and common memory objects do not have any of IARVSERV restrictions and do not change my conclusion that performance is NOT the reason to convert to a memory object. It's the advanced functionality. One reason I use a common memory object is so I can avoid using CSA and SQA particularly for code. With the 16 page restriction it would be impractical to share code with IARVSERV. And common data spaces cannot execute code. There are no limits to the flexibility offered by memory objects. I can share any number of pages. With shared memory objects I can determine which address spaces have access and which do not. With common memory I can create my own CSA and even SQA with some restrictions. As Jim affirmed, there is probably little if any performance difference between data spaces and memory objects. Chose the one best suited to your architecture. Kenneth -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Monday, January 20, 2014 4:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Fw: Dataspace versus common area above the bar Memory objects are much more flexible than data spaces. Data spaces are limited to 2GB. Memory objects are only limited by the auxiliary storage. Memory objects can be guarded and can also be page protected. Data spaces cannot. Code can execute in memory object but not in data spaces. I started using memory objects 10 years ago and have nearly forgotten how to use a data space. Guard pages and protected pages can be created in data spaces using IARV64 with TAGET_VIEW=HIDDEN and TARGET_VIEW=READONLY I meant IARVSERV, not IARV64 Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
This thread has been curiously silent about one characteristic of routines/instructions executed above the bar. Unsurprisingly, they are measurably faster than their analogues executed below it. z/Architecture is 64-bit architecture This is not, of course, their only or even their most important merit. Statesmanlike discussion of the relative merits of data spaces and memory objects is, at best, moot. The future, if there is one, is above the bar, for both data and executables. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
On Tue, 21 Jan 2014 15:42:20 -0500, John Gilmore wrote: This thread has been curiously silent about one characteristic of routines/instructions executed above the bar. Unsurprisingly, they are measurably faster than their analogues executed below it. z/Architecture is 64-bit architecture Is this true even for a small program in 64-bit mode when the program and its data reside entirely below the bar vis-a-vis the same program and data residing above the bar? This is not, of course, their only or even their most important merit. Statesmanlike discussion of the relative merits of data spaces and memory objects is, at best, moot. The future, if there is one, is above the bar, for both data and executables. This is tantamount to saying, The future, if there is one, for z/OS... But, it's taking steps in that direction. z/OS software technology trails decades behind z/OS hardware technology. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
On Tue, Jan 21, 2014 at 2:42 PM, John Gilmore jwgli...@gmail.com wrote: This thread has been curiously silent about one characteristic of routines/instructions executed above the bar. Unsurprisingly, they are measurably faster than their analogues executed below it. z/Architecture is 64-bit architecture That is surprising. Are you saying that if I run an AMODE(64) routine which is physically loaded above the bar and the identical program again physically loaded below the bar, that the fact that the instructions executed are above the bar causes the hardware to execute them faster? That is a mind boggling thing as Bo Pilgrim used to say. This is not, of course, their only or even their most important merit. Statesmanlike discussion of the relative merits of data spaces and memory objects is, at best, moot. The future, if there is one, is above the bar, for both data and executables. I will definitely agree with that. John Gilmore, Ashland, MA 01721 - USA -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
No, I was saying, I thought, something very different. To be clear, the execution of an AMODE(64) routine using the instructions natural to it, is in general faster than the execution of anits AMODE(31) or, a fortiori, AMODE(24) functional equivalent. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
Thanks for the clarification. That makes sense to me. The hardware is not masking off the unused bits. I totally misread the first paragraph. I also wonder if an AGR is faster than a simple AG. Unless the CPU has both 64 and 32 bit ALUs, it would make sense that the native 64 bit would be faster. On Tue, Jan 21, 2014 at 3:40 PM, John Gilmore jwgli...@gmail.com wrote: No, I was saying, I thought, something very different. To be clear, the execution of an AMODE(64) routine using the instructions natural to it, is in general faster than the execution of anits AMODE(31) or, a fortiori, AMODE(24) functional equivalent. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
No, I was saying, I thought, something very different. To be clear, the execution of an AMODE(64) routine using the instructions natural to it, is in general faster than the execution of anits AMODE(31) or, a fortiori, AMODE(24) functional equivalent. AMODE does not affect performance. Can you explain which instructions you think are faster than some functional equivalent, and why you think they are faster? Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
On 2014-01-21 15:42, John Gilmore wrote: This thread has been curiously silent about one characteristic of routines/instructions executed above the bar. Unsurprisingly, they are measurably faster than their analogues executed below it. z/Architecture is 64-bit architecture One caveat to that statement is as follows, from the POps: The performance of CDSG on some models may be significantly slower than that of CSG. WHEN QUADWORD CONSISTENCY IS NOT REQUIRED BY THE PROGRAM, alternate code sequences should be used. (my caps) There are situations where serializing updates to data areas in 64-bit storage do require quadword consistency, while the same algorithm using 31-bit storage would only require doubleword consistency. Having said that, the OP did not mention any need to update his tables. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
I think it is the new instructions that don't use base or index registers, instead a +/- 32K offset. On Tue, Jan 21, 2014 at 5:02 PM, Jim Mulder d10j...@us.ibm.com wrote: No, I was saying, I thought, something very different. To be clear, the execution of an AMODE(64) routine using the instructions natural to it, is in general faster than the execution of anits AMODE(31) or, a fortiori, AMODE(24) functional equivalent. AMODE does not affect performance. Can you explain which instructions you think are faster than some functional equivalent, and why you think they are faster? Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
I think it is the new instructions that don't use base or index registers, instead a +/- 32K offset. functional equivalent, and why you think they are faster? AMODE does not affect performance. Can you explain which instructions you think are faster than some Relative addressing instructions were introduced in ESA/390, on the 9672 Generation 2 processors. They are not in general faster than their base/index addressing counterparts, as long as Address Generation Interlocks are avoided by loading registers far enough in advance of their use as a base or index register. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
One caveat to that statement is as follows, from the POps: The performance of CDSG on some models may be significantly slower than that of CSG. WHEN QUADWORD CONSISTENCY IS NOT REQUIRED BY THE PROGRAM, alternate code sequences should be used. (my caps) CDSG was implemented in millicode on the z900, z800, z990, z890, and z9 machines. It was moved to hardware on the z10 and later machines. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
64 bit addressing execution is faster if less access to real memory is required to fetch the next instruction. This is what quadword promise, is'It? the performance gain is also depend on the logic of the program (if commands sequenced well with less brunch instructions). ITschak On Wed, Jan 22, 2014 at 5:30 AM, Jim Mulder d10j...@us.ibm.com wrote: One caveat to that statement is as follows, from the POps: The performance of CDSG on some models may be significantly slower than that of CSG. WHEN QUADWORD CONSISTENCY IS NOT REQUIRED BY THE PROGRAM, alternate code sequences should be used. (my caps) CDSG was implemented in millicode on the z900, z800, z990, z890, and z9 machines. It was moved to hardware on the z10 and later machines. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
On Mon, Jan 20, 2014 at 3:38 AM, John Blythe Reid johnblyther...@gmail.comwrote: Hello, I just wanted to sound people out about converting a dataspace to a common area above the bar. The main interest is the effect it would have on CPU usage. To put it into context, the dataspace is used for a set of tables which are used by the application programs. There are around eight thousand tables currently occupying about a gigabyte of virtual storage. This is a large installation with excess of 700 million transactions per month plus a heavy batch load. The application programs make extensive use of these tables. Whenever an application program needs an element of one of the tables it calls a standard assembler module which uses access register mode to search the table in the dataspace and then returns the requested element to the application program. If the set of tables were placed above the bar then access register mode would not be needed as the tables would be directly addressable in 64 bit addressing mode. It all seems much simpler so, at first sight, it would be expected to use less CPU. A reduction in CPU would be the main justification for doing the conversion. I would be very interested on anyone's opinion on this subject. Regards, John. That's an interesting question. And it triggered some more questions in my mind. First, is your entire application written in AMODE(64)? If not, doesn't that means that your assembler routine would be switching AMODEs to/from AMODE(64) and the caller's AMODE on each call? Do you cache the ALET for your data space somewhere easy to retrieve? What about the 64 bit address of the AMODE(64) table? It is cached somewhere? Or, in either case, does the caller supply the address/ALET to the assember routine. I guess the main question that occurs to me is: How much difference is there between doing two SAC instructions (to change the enable/disable dual address mode) between doing a BASSM and BSM (to change AMODEs)? I also wonder if there is any difference in speed in fetching some data from a Data Space versus the home address space? -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
Hi John, No, all the applications are AMODE(31). The assembler routine currently temporarily changes to AR mode on each call to access the dataspace. The ALET is stored in the CSA when the dataspace is created so the assembler routine picks it up from there. if we go ahead and put the tables above the bar then the 64 bit address of the start of the tables would similarly be stored in the CSA. Yes, that's what I'm wondering: whether the fact that the assembler routine, which is in the home address space, is scanning tables in the dataspace is more costly than if those same tables were above the bar in the same home address space. The fact that each memory address resolution when accessing the dataspace involves displacement+base+access register and the DAT uses a different segment/page table to get to the real address makes me think it should be faster using a 64 bit address in the home address, but that's just a feeling. I'd be interested in anyone else's experience on this. Regards, John. On 20 January 2014 15:03, John McKown john.archie.mck...@gmail.com wrote: On Mon, Jan 20, 2014 at 3:38 AM, John Blythe Reid johnblyther...@gmail.comwrote: Hello, I just wanted to sound people out about converting a dataspace to a common area above the bar. The main interest is the effect it would have on CPU usage. To put it into context, the dataspace is used for a set of tables which are used by the application programs. There are around eight thousand tables currently occupying about a gigabyte of virtual storage. This is a large installation with excess of 700 million transactions per month plus a heavy batch load. The application programs make extensive use of these tables. Whenever an application program needs an element of one of the tables it calls a standard assembler module which uses access register mode to search the table in the dataspace and then returns the requested element to the application program. If the set of tables were placed above the bar then access register mode would not be needed as the tables would be directly addressable in 64 bit addressing mode. It all seems much simpler so, at first sight, it would be expected to use less CPU. A reduction in CPU would be the main justification for doing the conversion. I would be very interested on anyone's opinion on this subject. Regards, John. That's an interesting question. And it triggered some more questions in my mind. First, is your entire application written in AMODE(64)? If not, doesn't that means that your assembler routine would be switching AMODEs to/from AMODE(64) and the caller's AMODE on each call? Do you cache the ALET for your data space somewhere easy to retrieve? What about the 64 bit address of the AMODE(64) table? It is cached somewhere? Or, in either case, does the caller supply the address/ALET to the assember routine. I guess the main question that occurs to me is: How much difference is there between doing two SAC instructions (to change the enable/disable dual address mode) between doing a BASSM and BSM (to change AMODEs)? I also wonder if there is any difference in speed in fetching some data from a Data Space versus the home address space? -- Wasn't there something about a PASCAL programmer knowing the value of everything and the Wirth of nothing? Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- John Blythe Reid, Técnico de Sistemas de z/OS y de Sistemas Transaccionales, Barcelona, España. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
On 2014-01-20 04:38, John Blythe Reid wrote: I just wanted to sound people out about converting a dataspace to a common area above the bar. The main interest is the effect it would have on CPU usage. To put it into context, the dataspace is used for a set of tables which are used by the application programs. There are around eight thousand tables currently occupying about a gigabyte of virtual storage. This is a large installation with excess of 700 million transactions per month plus a heavy batch load. The application programs make extensive use of these tables. Whenever an application program needs an element of one of the tables it calls a standard assembler module which uses access register mode to search the table in the dataspace and then returns the requested element to the application program. If the set of tables were placed above the bar then access register mode would not be needed as the tables would be directly addressable in 64 bit addressing mode. It all seems much simpler so, at first sight, it would be expected to use less CPU. A reduction in CPU would be the main justification for doing the conversion. I would be very interested on anyone's opinion on this subject. Regards, John. I did some tests of a very similar scenario, expecting to see a significant performance gain. The actual results showed a reduction in CPU usage of about 1-2%. We decided that the gain was small enough that we were better off continuing to enjoy the data isolation provided by the data space. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
Hi John: My advise is to benchmark ... And it might be different on different machines. So if 64-bit runs better in your current machine, don't through away your old AR code, because it might be useful in your DR site or a new machine. My advise is to benchmark because I found myself more than once with the wrong assumption. If you choose to benchmark, try to keep your benchmark as close as possible to the real workload ... Toy systems behave different than real ones. Mauri. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
A reasonable question might be do you expect installations to need this data to grow? If so and the growth is enough it might well be ARCHITECTURALLY better to move to 64 bit at some point. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, 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: Mauri Kanter itzuv...@013.net.il To: IBM-MAIN@listserv.ua.edu Date: 20/01/2014 16:27 Subject:Re: Dataspace versus common area above the bar Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu Hi John: My advise is to benchmark ... And it might be different on different machines. So if 64-bit runs better in your current machine, don't through away your old AR code, because it might be useful in your DR site or a new machine. My advise is to benchmark because I found myself more than once with the wrong assumption. If you choose to benchmark, try to keep your benchmark as close as possible to the real workload ... Toy systems behave different than real ones. Mauri. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN 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...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
Almost 10 years ago, I converted an application using 7 data spaces into one using a single shared memory object. As Gord has pointed out, the CPU advantage was negligible though I feel it is very difficult to benchmark the effect. The real advantage was a reduction in error rates because of the management of the 7 alets and the inadvertent use of an alet where it was not needed. As far as isolation is concerned, memory objects are just as isolated and much more manageable than data spaces. Basing isolation of a common data space on the alet value is no more isolation than basing the isolation of a common memory object on the amode. Memory objects are much more flexible than data spaces. Data spaces are limited to 2GB. Memory objects are only limited by the auxiliary storage. Memory objects can be guarded and can also be page protected. Data spaces cannot. Code can execute in memory object but not in data spaces. I started using memory objects 10 years ago and have nearly forgotten how to use a data space. So the question is not a question of CPU performance but a question of do you have an application that is architected or can be architected to take advantage of the advanced features offered by memory objects? In my current application, I use local, shared and common memory objects. I place most (about 70%) of the code in one these common memory objects and page protect them. I can't think of any instance where I would chose a data space over a memory object. Kenneth -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gord Tomlin Sent: Monday, January 20, 2014 10:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Dataspace versus common area above the bar On 2014-01-20 04:38, John Blythe Reid wrote: I just wanted to sound people out about converting a dataspace to a common area above the bar. The main interest is the effect it would have on CPU usage. To put it into context, the dataspace is used for a set of tables which are used by the application programs. There are around eight thousand tables currently occupying about a gigabyte of virtual storage. This is a large installation with excess of 700 million transactions per month plus a heavy batch load. The application programs make extensive use of these tables. Whenever an application program needs an element of one of the tables it calls a standard assembler module which uses access register mode to search the table in the dataspace and then returns the requested element to the application program. If the set of tables were placed above the bar then access register mode would not be needed as the tables would be directly addressable in 64 bit addressing mode. It all seems much simpler so, at first sight, it would be expected to use less CPU. A reduction in CPU would be the main justification for doing the conversion. I would be very interested on anyone's opinion on this subject. Regards, John. I did some tests of a very similar scenario, expecting to see a significant performance gain. The actual results showed a reduction in CPU usage of about 1-2%. We decided that the gain was small enough that we were better off continuing to enjoy the data isolation provided by the data space. -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
I just wanted to sound people out about converting a dataspace to a common area above the bar. The main interest is the effect it would have on CPU usage. To put it into context, the dataspace is used for a set of tables which are used by the application programs. There are around eight thousand tables currently occupying about a gigabyte of virtual storage. This is a large installation with excess of 700 million transactions per month plus a heavy batch load. The application programs make extensive use of these tables. Whenever an application program needs an element of one of the tables it calls a standard assembler module which uses access register mode to search the table in the dataspace and then returns the requested element to the application program. If the set of tables were placed above the bar then access register mode would not be needed as the tables would be directly addressable in 64 bit addressing mode. It all seems much simpler so, at first sight, it would be expected to use less CPU. A reduction in CPU would be the main justification for doing the conversion. As long as there is no ALB miss, the hardware performance for a data space storage access is no different than for non-data space. Converting from data space to memory object would save you the instructions for setting ARs, and possibly AGIs if the setting of an AR is too close to the use of the AR in address generation, and possibly an ALB miss each time your routine is called. Since the ALB miss may result in cache misses during ART, that is probably the most significant effect. However, all of that is probably next to nothing compared to the cache misses when you access the tables, and that will not be affected by data space vs. memory object. HIS sampler data (available on z10 and newer machines) is the best way to determine how much time you are spending in this code. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
Memory objects are much more flexible than data spaces. Data spaces are limited to 2GB. Memory objects are only limited by the auxiliary storage. Memory objects can be guarded and can also be page protected. Data spaces cannot. Code can execute in memory object but not in data spaces. I started using memory objects 10 years ago and have nearly forgotten how to use a data space. Guard pages and protected pages can be created in data spaces using IARV64 with TAGET_VIEW=HIDDEN and TARGET_VIEW=READONLY Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dataspace versus common area above the bar
Because I've used memory objects for so long, I have not had a reason for IARVSERV. I read both the description in the macro reference and in the authorized assembler guide and there seems to be a ton of restrictions and quirks (such as TPROT). The most notable restriction is the sharing limit of 16 pages for an unauthorized address space. However, this limit can be changed. But because of the ESQA considerations created because the page tables can map different virtual address for the shared pages, I'm not sure what would be a practical limit. It does appear to address guard and to some extent page protection . It also offers the ability to share 31 bit storage with 24 bit applications (a key point). Shared and common memory objects do not have any of IARVSERV restrictions and do not change my conclusion that performance is NOT the reason to convert to a memory object. It's the advanced functionality. One reason I use a common memory object is so I can avoid using CSA and SQA particularly for code. With the 16 page restriction it would be impractical to share code with IARVSERV. And common data spaces cannot execute code. There are no limits to the flexibility offered by memory objects. I can share any number of pages. With shared memory objects I can determine which address spaces have access and which do not. With common memory I can create my own CSA and even SQA with some restrictions. As Jim affirmed, there is probably little if any performance difference between data spaces and memory objects. Chose the one best suited to your architecture. Kenneth -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jim Mulder Sent: Monday, January 20, 2014 4:13 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Fw: Dataspace versus common area above the bar Memory objects are much more flexible than data spaces. Data spaces are limited to 2GB. Memory objects are only limited by the auxiliary storage. Memory objects can be guarded and can also be page protected. Data spaces cannot. Code can execute in memory object but not in data spaces. I started using memory objects 10 years ago and have nearly forgotten how to use a data space. Guard pages and protected pages can be created in data spaces using IARV64 with TAGET_VIEW=HIDDEN and TARGET_VIEW=READONLY I meant IARVSERV, not IARV64 Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
