>> - 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@xxxxxxxxx> 写道：
>
> Hi Alan,
>
> On Tue, 11 Apr 2023 12:28:05 -0400, Alan Huang wrote:
>> Signed-off-by: Alan Huang <mmpgouride@xxxxxxxxx>
>> ---
>> 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,
