Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both
On 6/6/2016 6:26 AM, Jerry Callen wrote: This is by no means "real world" code, and I would never call it a "benchmark". However, I do believe it correctly illustrates the difference in performance between various synchronization mechanisms in its admittedly limited set of test cases. It's an excellent test and quite representative of many real-world cases in my experience. Generally, only servers will have hundreds of units of work and if that's the scenario in which Pause/Release/Transfer becomes most useful, due to reduced local lock contention, then that's *absolutely* worth knowing! But, it's also worth knowing just how fast WAIT/POST really is for more simplistic use cases! Thanks for taking the time to publish your results in this forum... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both
In the interest of full disclosure, the code is now available on github: https://github.com/zorts/pause_release As noted way back in my original posting, the code is unauthorized, uses only TCBs, and ping-pongs between two tasks. I'm running this code on a moderately loaded z13, native z/OS 2.2 LPAR with many CPUs and zIIPs (though, since it's unauthorized, this code is only using CPUs). I believe the ping-pong nature of the test explains why the impact of the "fast" wait/post code has relatively little impact on the measured performance; the inner loop is so small that an actual WAIT or POST is required for every iteration. This is by no means "real world" code, and I would never call it a "benchmark". However, I do believe it correctly illustrates the difference in performance between various synchronization mechanisms in its admittedly limited set of test cases. It's great that this has stimulated the discussion it has; I've learned a lot. -- Jerry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both
On 6/4/2016 2:31 PM, Greg Dyck wrote: On 6/4/2016 6:34 AM, Ed Jaffe wrote: So, the local lock is obtained in only a subset of Pause/Release scenarios? Ed, The local lock is *never* obtained for single PET Pause/Release processing. That's great to know! That makes Pause/Release/Transfer extremely attractive for scenarios in which many units of work might be running concurrently in the address space. Minimizing local lock contention in such scenarios is key to getting things done... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both
On 6/4/2016 6:34 AM, Ed Jaffe wrote: So, the local lock is obtained in only a subset of Pause/Release scenarios? Ed, The local lock is *never* obtained for single PET Pause/Release processing. For multiple PET Pause/Release it is obtained to serialize creation of an address space related CPOOL which only occurs once for the address space each time a new started task or batch step jobstep task created, which is essentially never in the big picture. Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both
On 6/4/2016 5:55 AM, Peter Relson wrote: It is still thought that, for many cases, pause/release is more efficient than wait/post (not just more effective), primarily due to the reduction in local lock usage which can be a significant difference-maker in application performance. So, the local lock is obtained in only a subset of Pause/Release scenarios? Thanks. That's the kind of useful information I was hoping you might be able to provide. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both
>...led to believe... >...sentence is especially misleading. It suggests the primary use ... As I read the wording that was quoted: I do not see a comparison of the pause/release group of services to the wait/post services. I do not see a "suggestion". I see a valid example. An "example" is not a "suggestion". It is still thought that, for many cases, pause/release is more efficient than wait/post (not just more effective), primarily due to the reduction in local lock usage which can be a significant difference-maker in application performance. I still do not recall seeing an answer to my question of whether the tests were for authorized or unauthorized use of post. And it is inconceivable to me that use of "CS" would be only 33% faster than use of the service. Presumably that means that the CS was done only occasionally. I have forgotten by now: was there a detailed description of what the "benchmark" was doing? 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: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.
On 3 June 2016 at 13:30, Ed Jaffe wrote: > I really think the focus should be on the obvious advantages of using PETs > over ECBs and/or ease of coding in routines that might be executed in either > task or SRB mode. (We love not having to dual-path things.) To say nothing of cross-memory mostly just looking after itself in a safe way. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.
On 6/3/2016 5:59 AM, Peter Relson wrote: I don't view that as saying anything about wait/post. It is simply saying that transfer can be faster than pause plus release (i.e, not using transfer). With all due respect, most developers who read the following are led to believe that the "new" Pause/Release/Transfer services are _more_ efficient than "legacy" alternatives: Pause, Release, and Transfer (IEAVPSE, IEAVRLS, IEAVXFR, and IEA4PSE, IEA4RLS, IEA4XFR for 64-bit addressing mode ) are callable services that enable you to synchronize task or SRB processing with minimal overhead. If you have, for example, an application that requires two tasks to trade control back and forth, these services provide efficient transfers of control. That last sentence is especially misleading. It suggests the primary use case is synchronizing two tasks (aka TCBs) in an "efficient" manner when customer-written benchmarks suggest the tasks will be synchronized using techniques that are probably less efficient than WAIT/POST. If those benchmarks are wrong, please say so... I really think the focus should be on the obvious advantages of using PETs over ECBs and/or ease of coding in routines that might be executed in either task or SRB mode. (We love not having to dual-path things.) -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.
>I wouldn't call it "deprecated", but this does suggest that the "transfer" >feature of pause elements avoids dispatching overhead and therefore >*MIGHT* be faster: > https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaa800/pausrel.htm I don't view that as saying anything about wait/post. It is simply saying that transfer can be faster than pause plus release (i.e, not using transfer). 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: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.
On 6/2/2016 8:42 AM, Jerry Callen wrote: Yes, that's clear. What always gets my knickers twisted is when you can RESET the ECB and be sure you don't lose an event. If you always reset the ECB immediately after waking up, and before you start checking your work queues, you should never have a problem. For example (pseudo code using IBM's standard HLASM SPMs - which we use): DO INF,LABEL=Main Do for work WAIT on ECB Wait for work reset the ECB Reset the ECB DO INFDo for requests pull request from queue Pull request from queue DOEXIT if no more requestsExit if no more requests DOEXIT if terminate request, Exit if shutdown request DO=Main.. . . Invoke proper work handler Call proper work handler . ENDDO , EndDo for requests ENDDO , LABEL=MainEndDo for work -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.
I think the concern was over a FAST POST, which can be safely done using a simple CS instruction. This can be done because the system WAIT process uses a CS to set the WAIT indicator bit and RB address in the ECB. Either your code sets the POST bit or their code sets the WAIT bit depending on who gets there first. See example code in the Authorizer Assembler Services Guide on about pg. 54 Chris Blaicher Technical Architect Mainframe Development Syncsort Incorporated 50 Tice Boulevard, Woodcliff Lake, NJ 07677 P: 201-930-8234 | M: 512-627-3803 E: cblaic...@syncsort.com www.syncsort.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jerry Callen Sent: Thursday, June 2, 2016 11:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both. Edward Jaffe wrote: > Stated as simply as I can: If the POST bit is already on, why call the > WAIT service in the first place? All it's gonna do is immediately return. Yes, that's clear. What always gets my knickers twisted is when you can RESET the ECB and be sure you don't lose an event. I think I've convinced myself that, in this simple ping-pong case, just testing the post bit will work. Maybe I'll run THAT test, too. This is why I prefer data parallel programming to thread parallel programming; it makes my head hurt less. -- Jerry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ATTENTION: - The information contained in this message (including any files transmitted with this message) may contain proprietary, trade secret or other confidential and/or legally privileged information. Any pricing information contained in this message or in any files transmitted with this message is always confidential and cannot be shared with any third parties without prior written approval from Syncsort. This message is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any use, disclosure, copying or distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and/or Syncsort and destroy all copies of this message in your possession, custody or control. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.
Edward Jaffe wrote: > Stated as simply as I can: If the POST bit is already on, why call the > WAIT service in the first place? All it's gonna do is immediately return. Yes, that's clear. What always gets my knickers twisted is when you can RESET the ECB and be sure you don't lose an event. I think I've convinced myself that, in this simple ping-pong case, just testing the post bit will work. Maybe I'll run THAT test, too. This is why I prefer data parallel programming to thread parallel programming; it makes my head hurt less. -- Jerry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.
I *think* TMMYECB,X'40' JONOWAIT WAIT MYECB NOWAIT EQU * is foolproof, with no need for any sort of "interlock." Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jerry Callen Sent: Thursday, June 02, 2016 6:54 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both. Edward Jaffe wrote: > And, in the absence of contention, WAIT/POST in > professionally-developed software becomes orders of magnitude faster > since everyone knows to skip the WAIT if the post bit is on and to > attempt a "quick" POST of the ECB (using CS) if the wait bit is off. I understand the "quick POST" trick w/CS, but bypassing WAIT? I can see how that would work for something like waiting on I/O completion, but for trading control back and forth, I think it requires (for example) an auxiliary counter (and CDS to update both the ECB and the counter simultaneously). Am I missing something? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.
On 6/2/2016 6:54 AM, Jerry Callen wrote: I understand the "quick POST" trick w/CS, but bypassing WAIT? I can see how that would work for something like waiting on I/O completion, but for trading control back and forth, I think it requires (for example) an auxiliary counter (and CDS to update both the ECB and the counter simultaneously). Am I missing something? Stated as simply as I can: If the POST bit is already on, why call the WAIT service in the first place? All it's gonna do is immediately return. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.
Edward Jaffe wrote: > And, in the absence of contention, WAIT/POST in professionally-developed > software becomes orders of magnitude faster since everyone knows to skip > the WAIT if the post bit is on and to attempt a "quick" POST of the ECB > (using CS) if the wait bit is off. I understand the "quick POST" trick w/CS, but bypassing WAIT? I can see how that would work for something like waiting on I/O completion, but for trading control back and forth, I think it requires (for example) an auxiliary counter (and CDS to update both the ECB and the counter simultaneously). Am I missing something? -- Jerry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.
...and here we go. The results differ somewhat from the previously posted results; I just ran these, and the machine is somewhat quieter than before. Clearly the "fast POST" trick is worthwhile - though it didn't make as much difference as I expected. Relative performance: total CPU ECB 1.00 ECB No Fast Post 1.59 Pause/Resume 3.93 Transfer and Pause2.86 Transfer with separate Pause 4.05 Relative performance: elapsed ECB 1.00 ECB No Fast Post 1.60 Pause/Resume 5.24 Transfer and Pause3.91 Transfer with separate Pause 5.35 -- Jerry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.
Peter Relson wrote: >>I agree the reference materials _imply_ that WAIT/POST are deprecated >>and that Pause/Release/Transfer should be used when possible. >If you have a concrete reference, please provide it. WAIT/POST is in no >way deprecated. I wouldn't call it "deprecated", but this does suggest that the "transfer" feature of pause elements avoids dispatching overhead and therefore *MIGHT* be faster: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaa800/pausrel.htm "The Transfer service can both release a paused task or SRB and pass control directly to the released task or SRB. The Transfer service can also pause the task or SRB that calls the service. Thus, Transfer enables quick dispatches, saving the overhead of work search. It also allows two dispatchable units to trade control back and forth with minimal overhead." That's actually the main reason I ran my test; I wanted to see if this really made a difference (in the context of my admittedly unrealistic, TCB-only test). That's why there are 4 test scenarios: wait/post, pause/release, transfer, and transfer/pause. (And, as I've mentioned in another response, there should be a 5th: wait/post WITHOUT the "fast post" trick.) -- Jerry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.
> And, in the absence of contention, WAIT/POST in professionally-developed > software becomes orders of magnitude faster since everyone knows to skip the > WAIT if the post bit is on and to attempt a "quick" POST of the ECB (using > CS) if the wait bit is off. And my timing code did just that; it's such an inherent piece of the idiom that it didn't occur to me to disable the "quick POST" for this test. So my timings are, arguably, completely wrong. If I get a chance, I'll re-test. -- Jerry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.
On 5/30/2016 3:38 PM, Peter Relson wrote: Keep in mind that a simple run showing repeated use of a service likely does not provide overly meaningful information about the actual performance effect of a service, since "in the absence of any contention" is often not "real world". And, in the absence of contention, WAIT/POST in professionally-developed software becomes orders of magnitude faster since everyone knows to skip the WAIT if the post bit is on and to attempt a "quick" POST of the ECB (using CS) if the wait bit is off. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.
>I agree the reference materials _imply_ that WAIT/POST are deprecated >and that Pause/Release/Transfer should be used when possible. I If you have a concrete reference, please provide it. WAIT/POST is in no way deprecated. One thing that is true is that Pause/Release avoids contributing to local lock contention. This can make a significant difference to application performance in some cases. And the use of Wait/Post might, if not done properly, can introduce a system integrity exposure (Pause/Release is not prone to this misuse). "Properly" may require (for example) not using XM Post (it largely depends on who owns the ECB storage and who owns the waiting work unit). Keep in mind that a simple run showing repeated use of a service likely does not provide overly meaningful information about the actual performance effect of a service, since "in the absence of any contention" is often not "real world". I'm also curious whether the runs were with respect to an authorized invocation of wait/post vs an unauthorized invocation. FWIW, SSRBs are not in ECSA. They are partly in ESQA and a related structure is in HV common. They persist until the end of the work unit that needed one. 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: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.
Out of curiosity, has anyone ever compare WAIT and POST with the LINKAGE=SYSTEM operand as opposed to without? Art Celestini At 05:44 PM 5/26/2016, Ed Jaffe wrote: >On 5/26/2016 10:29 AM, Jerry Callen wrote: >>Here are the results: >> >>Relative performance: total CPU >>ECB 1.0 >>Pause/Resume 4.30 >>Transfer and Pause3.25 >>Transfer with separate Pause 4.55 >> >>Relative performance: elapsed >>ECB 1.0 >>Pause/Resume 6.06 >>Transfer and Pause4.75 >>Transfer with separate Pause 6.28 > >Great benchmark! If you're ever looking for a job and we happen to have an >opening... ;-) > >We ran a similar benchmark back in 2007 and discovered -- in addition to the >great info you've provided -- that suspending or pausing SRBs is slower than >suspending or pausing TCBs. We guessed the extra overhead was due to the fact >that SRBs, unlike TCBs, have no control block and therefore must acquire an >SSRB from ECSA, populate it with data from LCCA, PSA or whatever before >suspending, and return it upon waking up. > >I agree the reference materials _imply_ that WAIT/POST are deprecated and that >Pause/Release/Transfer should be used when possible. I believe that the issues >surrounding ownership and management of the ECB storage played a larger role >in those recommendation than raw performance did. > >-- >Edward E Jaffe >Phoenix Software International, Inc >831 Parkview Drive North >El Segundo, CA 90245 >http://www.phoenixsoftware.com/ > > == Art Celestini Celestini Development Services Phone: 201-670-1674Wyckoff, NJ = http://celestini.com = Mail sent to the "From" address used in this post will be rejected by our server. Please send off- list email to: ibmmaincelestinicom. == -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.
On 5/26/2016 10:29 AM, Jerry Callen wrote: Here are the results: Relative performance: total CPU ECB 1.0 Pause/Resume 4.30 Transfer and Pause3.25 Transfer with separate Pause 4.55 Relative performance: elapsed ECB 1.0 Pause/Resume 6.06 Transfer and Pause4.75 Transfer with separate Pause 6.28 Great benchmark! If you're ever looking for a job and we happen to have an opening... ;-) We ran a similar benchmark back in 2007 and discovered -- in addition to the great info you've provided -- that suspending or pausing SRBs is slower than suspending or pausing TCBs. We guessed the extra overhead was due to the fact that SRBs, unlike TCBs, have no control block and therefore must acquire an SSRB from ECSA, populate it with data from LCCA, PSA or whatever before suspending, and return it upon waking up. I agree the reference materials _imply_ that WAIT/POST are deprecated and that Pause/Release/Transfer should be used when possible. I believe that the issues surrounding ownership and management of the ECB storage played a larger role in those recommendation than raw performance did. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.
Greg Dyck wrote: > No one every said that Pause/Release was faster or consumed the same > amount of CPU as WAIT/POST, or that they should be used as a universal > replacement for WAIT/POST. They should be used where they provide value. The reason I wrote the test is that the documentation is unclear as to performance, and suggests that TRANSFER, in particular, might be faster than WAIT/POST. From the 2.2 Assembler Services Guide: === If you have, for example, an application that requires two or more tasks to trade control back and forth, these services provide efficient transfers of control. [...] The Transfer service can both release a paused task and pass control directly to the released task. The Transfer service can also pause the task that calls the service. Thus, Transfer enables quick dispatches, saving the overhead of work search. It also allows two tasks to trade control back and forth with minimal overhead. === Aside from earlier comments here in IBM-MAIN, I had no particular preconceptions regarding the performance, which is why I wrote the tests. Both services are easy to use, so there was no compelling advantage to either on that score. -- Jerry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.
On 5/26/2016 10:29 AM, Jerry Callen wrote: I wrote a simple test program to compare the performance of WAIT/POST and pause elements. The program has two tasks and simply ping-pongs back and forth between them (no overlapped execution). Each task has a synchronization gadget, either an ECB or a pause element. The tasks use each other's synchronization gadget to just transfer control back and forth between each other in a loop. This is a pretty unrealistic test (in terms of being like anything "real" code would do), but it does illustrate the relative performance of the two synchronization methods. This is like comparing using a back-hoe to dig a hole to plant a flower vs using a trowel. No one every said that Pause/Release was faster or consumed the same amount of CPU as WAIT/POST, or that they should be used as a universal replacement for WAIT/POST. They should be used where they provide value. Pause/Release can be used in environments where WAIT/POST can not be used. They support being issued by SRBs. They support being issued in cross-memory mode. The processing does not have any special case paths for more simple cases. As such, they are not light-weight services. WAIT/POST within a single address space is much more limited. Because of those limitations it is a light-weight service, and that is why you see the results that you see. Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.
He said z13 & z/OS2.2. Sent from my BlackBerry 10 smartphone on the Bell network. Original Message From: michelbutz Sent: Thursday, May 26, 2016 13:35 To: IBM-MAIN@LISTSERV.UA.EDU Reply To: IBM Mainframe Discussion List Subject: Re: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both. Can you tell us the following What type of processor The work load What version of z/OS these are relevant factors Sent from my iPhone > On May 26, 2016, at 1:29 PM, Jerry Callen wrote: > > (A very delayed follow-up on a thread from yesteryear...) > > tl;dr: In unauthorized code, ECBs are much faster than pause elements. > > I wrote a simple test program to compare the performance of WAIT/POST and > pause elements. The program has two tasks and simply ping-pongs back and > forth between them (no overlapped execution). Each task has a synchronization > gadget, either an ECB or a pause element. The tasks use each other's > synchronization gadget to just transfer control back and forth between each > other in a loop. This is a pretty unrealistic test (in terms of being like > anything "real" code would do), but it does illustrate the relative > performance of the two synchronization methods. > > Note that this unauthorized code, and tasks, not SRBs This means that all of > the synchronization primitives used SVCs, not branch entry points. The code > is 64-bit C++ compiled with xlC using -q64 and thread_create() to create the > tasks. The code is running on a z13, native LPAR, z/OS 2.2. > > The mechanisms I tested are: > > * ECBs: each task just alternates between a WAIT on its own ECB and a POST of > the other task's ECB. > * Pause elements with Pause (iea4pse) and Release (iea4rls) taking the role > of WAIT and POST. > * Pause elements using Transfer (iea4xfr) in "transfer and pause" mode (one > call to do both). > * Pause elements using Transfer (iea4xfr) in "just transfer" mode followed by > Pause (iea4pse). > > Here are the results: > > Relative performance: total CPU > ECB 1.0 > Pause/Resume 4.30 > Transfer and Pause 3.25 > Transfer with separate Pause 4.55 > > Relative performance: elapsed > ECB 1.0 > Pause/Resume 6.06 > Transfer and Pause 4.75 > Transfer with separate Pause 6.28 > > -- Jerry > > -- > 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: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.
Can you tell us the following What type of processor The work load What version of z/OS these are relevant factors Sent from my iPhone > On May 26, 2016, at 1:29 PM, Jerry Callen wrote: > > (A very delayed follow-up on a thread from yesteryear...) > > tl;dr: In unauthorized code, ECBs are much faster than pause elements. > > I wrote a simple test program to compare the performance of WAIT/POST and > pause elements. The program has two tasks and simply ping-pongs back and > forth between them (no overlapped execution). Each task has a synchronization > gadget, either an ECB or a pause element. The tasks use each other's > synchronization gadget to just transfer control back and forth between each > other in a loop. This is a pretty unrealistic test (in terms of being like > anything "real" code would do), but it does illustrate the relative > performance of the two synchronization methods. > > Note that this unauthorized code, and tasks, not SRBs This means that all of > the synchronization primitives used SVCs, not branch entry points. The code > is 64-bit C++ compiled with xlC using -q64 and thread_create() to create the > tasks. The code is running on a z13, native LPAR, z/OS 2.2. > > The mechanisms I tested are: > > * ECBs: each task just alternates between a WAIT on its own ECB and a POST of > the other task's ECB. > * Pause elements with Pause (iea4pse) and Release (iea4rls) taking the role > of WAIT and POST. > * Pause elements using Transfer (iea4xfr) in "transfer and pause" mode (one > call to do both). > * Pause elements using Transfer (iea4xfr) in "just transfer" mode followed by > Pause (iea4pse). > > Here are the results: > > Relative performance: total CPU > ECB 1.0 > Pause/Resume 4.30 > Transfer and Pause3.25 > Transfer with separate Pause 4.55 > > Relative performance: elapsed > ECB 1.0 > Pause/Resume 6.06 > Transfer and Pause4.75 > Transfer with separate Pause 6.28 > > -- Jerry > > -- > 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: SUSPEND/RESUME is slower than WAIT/POST. PAUSE/RELEASE is slower than both.
(A very delayed follow-up on a thread from yesteryear...) tl;dr: In unauthorized code, ECBs are much faster than pause elements. I wrote a simple test program to compare the performance of WAIT/POST and pause elements. The program has two tasks and simply ping-pongs back and forth between them (no overlapped execution). Each task has a synchronization gadget, either an ECB or a pause element. The tasks use each other's synchronization gadget to just transfer control back and forth between each other in a loop. This is a pretty unrealistic test (in terms of being like anything "real" code would do), but it does illustrate the relative performance of the two synchronization methods. Note that this unauthorized code, and tasks, not SRBs This means that all of the synchronization primitives used SVCs, not branch entry points. The code is 64-bit C++ compiled with xlC using -q64 and thread_create() to create the tasks. The code is running on a z13, native LPAR, z/OS 2.2. The mechanisms I tested are: * ECBs: each task just alternates between a WAIT on its own ECB and a POST of the other task's ECB. * Pause elements with Pause (iea4pse) and Release (iea4rls) taking the role of WAIT and POST. * Pause elements using Transfer (iea4xfr) in "transfer and pause" mode (one call to do both). * Pause elements using Transfer (iea4xfr) in "just transfer" mode followed by Pause (iea4pse). Here are the results: Relative performance: total CPU ECB 1.0 Pause/Resume 4.30 Transfer and Pause3.25 Transfer with separate Pause 4.55 Relative performance: elapsed ECB 1.0 Pause/Resume 6.06 Transfer and Pause4.75 Transfer with separate Pause 6.28 -- Jerry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
