* [PATCH] SMPDesign: Remove duplicate item @ 2023-04-11 16:28 Alan Huang 2023-04-12 0:16 ` Akira Yokosawa 0 siblings, 1 reply; 5+ messages in thread From: Alan Huang @ 2023-04-11 16:28 UTC (permalink / raw) To: paulmck, akiyks; +Cc: perfbook, Alan Huang Signed-off-by: Alan Huang <mmpgouride@gmail.com> --- SMPdesign/criteria.tex | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/SMPdesign/criteria.tex b/SMPdesign/criteria.tex index d3d84506..bc4d3a77 100644 --- a/SMPdesign/criteria.tex +++ b/SMPdesign/criteria.tex @@ -145,7 +145,7 @@ parallel program. The larger the gap between the number of CPUs and the actual speedup, the less efficiently the CPUs will be used. - Similarly, the greater the desired efficiency, the smaller + Similarly, the greater the desired efficiency, the bigger the achievable speedup. \item If the available synchronization primitives have high overhead compared to the critical sections @@ -157,11 +157,6 @@ parallel program. using asymmetric primitives (see \cref{chp:Deferred Processing}), or by using a coarse-grained design such as \IXh{code}{locking}. -\item If the critical sections have high overhead compared - to the primitives guarding them, the best way - to improve speedup is to increase parallelism - by moving to reader/writer locking, \IXh{data}{locking}, asymmetric, - or data ownership. \item If the critical sections have high overhead compared to the primitives guarding them and the data structure being guarded is read much more often than modified, -- 2.34.1 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] SMPDesign: Remove duplicate item 2023-04-11 16:28 [PATCH] SMPDesign: Remove duplicate item Alan Huang @ 2023-04-12 0:16 ` Akira Yokosawa 2023-04-12 1:15 ` Alan Huang 0 siblings, 1 reply; 5+ messages in thread From: Akira Yokosawa @ 2023-04-12 0:16 UTC (permalink / raw) To: Alan Huang; +Cc: perfbook, paulmck, Akira Yokosawa Hi Alan, On Tue, 11 Apr 2023 12:28:05 -0400, Alan Huang wrote: > Signed-off-by: Alan Huang <mmpgouride@gmail.com> > --- > SMPdesign/criteria.tex | 7 +------ > 1 file changed, 1 insertion(+), 6 deletions(-) > > diff --git a/SMPdesign/criteria.tex b/SMPdesign/criteria.tex > index d3d84506..bc4d3a77 100644 > --- a/SMPdesign/criteria.tex > +++ b/SMPdesign/criteria.tex > @@ -145,7 +145,7 @@ parallel program. > The larger the gap between the number of CPUs > and the actual speedup, the less efficiently the > CPUs will be used. > - Similarly, the greater the desired efficiency, the smaller > + Similarly, the greater the desired efficiency, the bigger > the achievable speedup. I might not be fully woken up, but this change doesn't make sense to me. > \item If the available synchronization primitives have > high overhead compared to the critical sections > @@ -157,11 +157,6 @@ parallel program. > using asymmetric primitives > (see \cref{chp:Deferred Processing}), > or by using a coarse-grained design such as \IXh{code}{locking}. > -\item If the critical sections have high overhead compared > - to the primitives guarding them, the best way > - to improve speedup is to increase parallelism > - by moving to reader/writer locking, \IXh{data}{locking}, asymmetric, > - or data ownership. You mean, this and the next item says the same thing? I don't think so. Item 4: If the critical sections have high overhead compared to the primitives guarding them, the best way to improve ^^^^^^^ speedup is to increase parallelism by moving to reader/writer ^^^^^^^ locking, data locking, asymmetric, or data ownership. ^^^^^^^^^^^^^ ^^^^^^^^^^^^^^ Item 5: If the critical sections have high overhead compared to the primitives guarding them and the data structure being ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ guarded is read much more often than modified, the best way ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ to increase parallelism is to move to reader/writer locking or asymmetric primitives. Are you sure they are duplicates ??? Thanks, Akira > \item If the critical sections have high overhead compared > to the primitives guarding them and the data structure > being guarded is read much more often than modified, ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] SMPDesign: Remove duplicate item 2023-04-12 0:16 ` Akira Yokosawa @ 2023-04-12 1:15 ` Alan Huang 2023-04-12 2:51 ` Akira Yokosawa 0 siblings, 1 reply; 5+ messages in thread From: Alan Huang @ 2023-04-12 1:15 UTC (permalink / raw) To: Akira Yokosawa; +Cc: perfbook, paulmck >> - Similarly, the greater the desired efficiency, the smaller >> + Similarly, the greater the desired efficiency, the bigger >> the achievable speedup. > > I might not be fully woken up, but this change doesn't make > sense to me. The original sentence means (to me) If we get greater efficiency use of CPUs, we get smaller speedup. If I misunderstood, please correct me. > If the critical sections have high overhead compared to > the primitives guarding them, the best way to improve > ^^^^^^^ > speedup is to increase parallelism by moving to reader/writer > ^^^^^^^ > locking, data locking, asymmetric, or data ownership. > ^^^^^^^^^^^^^ ^^^^^^^^^^^^^^ > > Item 5: > > If the critical sections have high overhead compared to > the primitives guarding them and the data structure being > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > guarded is read much more often than modified, the best way > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > to increase parallelism is to move to reader/writer locking > or asymmetric primitives. > > Are you sure they are duplicates ??? If the critical sections have high overhead compared to the primitives guarding them, It means that the overhead of primitives is relative small, but the aim of data locking and data ownership is to reduce the overhead of primitives. Thanks, Alan > 2023年4月12日 上午8:16，Akira Yokosawa <akiyks@gmail.com> 写道： > > Hi Alan, > > On Tue, 11 Apr 2023 12:28:05 -0400, Alan Huang wrote: >> Signed-off-by: Alan Huang <mmpgouride@gmail.com> >> --- >> SMPdesign/criteria.tex | 7 +------ >> 1 file changed, 1 insertion(+), 6 deletions(-) >> >> diff --git a/SMPdesign/criteria.tex b/SMPdesign/criteria.tex >> index d3d84506..bc4d3a77 100644 >> --- a/SMPdesign/criteria.tex >> +++ b/SMPdesign/criteria.tex >> @@ -145,7 +145,7 @@ parallel program. >> The larger the gap between the number of CPUs >> and the actual speedup, the less efficiently the >> CPUs will be used. >> - Similarly, the greater the desired efficiency, the smaller >> + Similarly, the greater the desired efficiency, the bigger >> the achievable speedup. > > I might not be fully woken up, but this change doesn't make > sense to me. > >> \item If the available synchronization primitives have >> high overhead compared to the critical sections >> @@ -157,11 +157,6 @@ parallel program. >> using asymmetric primitives >> (see \cref{chp:Deferred Processing}), >> or by using a coarse-grained design such as \IXh{code}{locking}. >> -\item If the critical sections have high overhead compared >> - to the primitives guarding them, the best way >> - to improve speedup is to increase parallelism >> - by moving to reader/writer locking, \IXh{data}{locking}, asymmetric, >> - or data ownership. > > You mean, this and the next item says the same thing? > I don't think so. > > Item 4: > > If the critical sections have high overhead compared to > the primitives guarding them, the best way to improve > ^^^^^^^ > speedup is to increase parallelism by moving to reader/writer > ^^^^^^^ > locking, data locking, asymmetric, or data ownership. > ^^^^^^^^^^^^^ ^^^^^^^^^^^^^^ > > Item 5: > > If the critical sections have high overhead compared to > the primitives guarding them and the data structure being > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > guarded is read much more often than modified, the best way > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > to increase parallelism is to move to reader/writer locking > or asymmetric primitives. > > Are you sure they are duplicates ??? > > Thanks, Akira > >> \item If the critical sections have high overhead compared >> to the primitives guarding them and the data structure >> being guarded is read much more often than modified, ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] SMPDesign: Remove duplicate item 2023-04-12 1:15 ` Alan Huang @ 2023-04-12 2:51 ` Akira Yokosawa 2023-04-12 10:40 ` Alan Huang 0 siblings, 1 reply; 5+ messages in thread From: Akira Yokosawa @ 2023-04-12 2:51 UTC (permalink / raw) To: Alan Huang; +Cc: perfbook, paulmck, Akira Yokosawa On Wed, 12 Apr 2023 09:15:12 +0800, Alan Huang wrote: >>> - Similarly, the greater the desired efficiency, the smaller >>> + Similarly, the greater the desired efficiency, the bigger >>> the achievable speedup. >> >> I might not be fully woken up, but this change doesn't make >> sense to me. > > The original sentence means (to me) If we get greater efficiency use of CPUs, > we get smaller speedup. > > If I misunderstood, please correct me. My version of interpretation of the sentence: Similarly, if our goal is greater efficiency, we might end up in a smaller speedup in the end. One extreme approach for the greatest efficiency might be not to parallelize at all, to use a single CPU, and to get a negative speedup (i.e., speed down). > >> If the critical sections have high overhead compared to >> the primitives guarding them, the best way to improve >> ^^^^^^^ >> speedup is to increase parallelism by moving to reader/writer >> ^^^^^^^ >> locking, data locking, asymmetric, or data ownership. >> ^^^^^^^^^^^^^ ^^^^^^^^^^^^^^ >> >> Item 5: >> >> If the critical sections have high overhead compared to >> the primitives guarding them and the data structure being >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> guarded is read much more often than modified, the best way >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> to increase parallelism is to move to reader/writer locking >> or asymmetric primitives. >> >> Are you sure they are duplicates ??? > > > If the critical sections have high overhead compared to the primitives guarding them, > It means that the overhead of primitives is relative small, but the aim of data locking and data ownership > is to reduce the overhead of primitives. Well, I think Paul's motivation of special casing read-mostly data comes from his expertise in RCU. I'd like to respect his motivation. Anyway, this list is more of a guideline of approaches to parallel-programming design considerations. Why do you want it to be so precise ??? Thanks, Akira > > Thanks, > Alan > [...] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] SMPDesign: Remove duplicate item 2023-04-12 2:51 ` Akira Yokosawa @ 2023-04-12 10:40 ` Alan Huang 0 siblings, 0 replies; 5+ messages in thread From: Alan Huang @ 2023-04-12 10:40 UTC (permalink / raw) To: Akira Yokosawa, paulmck; +Cc: perfbook > One extreme approach for the greatest efficiency might be not to > parallelize at all, to use a single CPU, and to get a negative > speedup (i.e., speed down). But we can also get the greatest efficiency using data ownership under the maximum degree of parallelism. > Anyway, this list is more of a guideline of approaches to > parallel-programming design considerations. Got it. Thanks, Alan > 2023年4月12日 上午10:51，Akira Yokosawa <akiyks@gmail.com> 写道： > > On Wed, 12 Apr 2023 09:15:12 +0800, Alan Huang wrote: >>>> - Similarly, the greater the desired efficiency, the smaller >>>> + Similarly, the greater the desired efficiency, the bigger >>>> the achievable speedup. >>> >>> I might not be fully woken up, but this change doesn't make >>> sense to me. >> >> The original sentence means (to me) If we get greater efficiency use of CPUs, >> we get smaller speedup. >> >> If I misunderstood, please correct me. > > My version of interpretation of the sentence: > > Similarly, if our goal is greater efficiency, we might end up > in a smaller speedup in the end. > > One extreme approach for the greatest efficiency might be not to > parallelize at all, to use a single CPU, and to get a negative > speedup (i.e., speed down). > >> >>> If the critical sections have high overhead compared to >>> the primitives guarding them, the best way to improve >>> ^^^^^^^ >>> speedup is to increase parallelism by moving to reader/writer >>> ^^^^^^^ >>> locking, data locking, asymmetric, or data ownership. >>> ^^^^^^^^^^^^^ ^^^^^^^^^^^^^^ >>> >>> Item 5: >>> >>> If the critical sections have high overhead compared to >>> the primitives guarding them and the data structure being >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> guarded is read much more often than modified, the best way >>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >>> to increase parallelism is to move to reader/writer locking >>> or asymmetric primitives. >>> >>> Are you sure they are duplicates ??? >> >> >> If the critical sections have high overhead compared to the primitives guarding them, >> It means that the overhead of primitives is relative small, but the aim of data locking and data ownership >> is to reduce the overhead of primitives. > > Well, I think Paul's motivation of special casing read-mostly > data comes from his expertise in RCU. > > I'd like to respect his motivation. > > Anyway, this list is more of a guideline of approaches to > parallel-programming design considerations. > Why do you want it to be so precise ??? > > Thanks, Akira > >> >> Thanks, >> Alan >> > [...] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-04-12 10:40 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2023-04-11 16:28 [PATCH] SMPDesign: Remove duplicate item Alan Huang 2023-04-12 0:16 ` Akira Yokosawa 2023-04-12 1:15 ` Alan Huang 2023-04-12 2:51 ` Akira Yokosawa 2023-04-12 10:40 ` Alan Huang
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.