[PATCH] SMPDesign: Remove duplicate item

[PATCH] SMPDesign: Remove duplicate item

[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

Re: [PATCH] SMPDesign: Remove duplicate item

[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,

Re: [PATCH] SMPDesign: Remove duplicate item

[Alan Huang]

>> -	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,

Re: [PATCH] SMPDesign: Remove duplicate item

[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
> 
[...]

Re: [PATCH] SMPDesign: Remove duplicate item

[Alan Huang]

> 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
>> 
> [...]