On Fri, 20 Aug 2021 13:04:47 -0700, Paul E. McKenney wrote:
> On Fri, Aug 20, 2021 at 07:43:03PM +0900, Akira Yokosawa wrote:
>> On Thu, 19 Aug 2021 19:54:28 -0700, Paul E. McKenney wrote:
>>> On Fri, Aug 20, 2021 at 08:43:13AM +0900, Akira Yokosawa wrote:
>>>> On Thu, 19 Aug 2021 10:29:40 -0700, Paul E. McKenney wrote:
>>>>> On Thu, Aug 19, 2021 at 07:54:30PM +0900, Akira Yokosawa wrote:
>> [...]
>>>>>> Three uses of "than" in a sentence might be confusing, though.
>>>>>>
>>>>>> Paul might have an idea of a less-confusing sentence.
>>>>>
>>>>> Three "than"s in one sentence is a bit excessive, now that you guys
>>>>> mention it.
>>>>>
>>>>> How about this?
>>>>>
>>>>> In practice, there are a lot more 28-CPU systems than there are
>>>>> 448-CPU systems.
>>>>>
>>>>> I do not believe that the "more than"s are really adding much here.
>>>>
>>>> Well, the question part reads:
>>>>
>>>>> The dangers of extrapolating from 28 CPUs to 448 CPUs was made quite
>>>>> clear in Section 10.2.3. But why should extrapolating up from 448 CPUs be
>>>>> any safer?
>>>>
>>>> So, the point is "extrapolating up from 448 CPUs".
>>>> Hence you used "more than"s in the answer, didn't you?
>>>
>>> Right you are, and thank you for checking this!
>>>
>>> There are several possibilities:
>>>
>>> In practice, there are a lot more systems with in excess of
>>> 28~CPUs than there are systems with in excess of 448 CPUs.
>>>
>>> Or:
>>>
>>> In practice, there are only a very few systems with more than
>>> 448 CPUs, while there is a huge number having more than 28 CPUs.
>>>
>>> Or perhaps rework the full answer:
>>>
>>> In theory, it isn't any safer, and a useful exercise would be
>>> to run these programs on larger systems.
>>> In practice, there are only a very few systems with more than
>>> 448 CPUs, in contrast to the huge number having more than 28 CPUs.
>>> This means that although it is dangerous to extrapolate beyond
>>> 448 CPUs, there is very little need to do so.
>>> In addition, other testing has shown that RCU read-side primitives
>>> offer consistent performance and scalability up to at least 1024 CPUs.
>>>
>>> Thoughts?
>>
>> The fully reworked answer looks much clearer for me.
>
> OK, I started from there.
>
>> Besides, I'd like to suggest some changes around QQ 10.9.
>>
>> As there is no mention of extrapolation before this QQ in this section,
>> the question of "But why should extrapolating up from 448 CPUs be any
>> safer?" looks kind of abrupt.
>> A plain yes/no question would be smoother.
>>
>> Also, the transition of discussion on Figure 10.12 (update performance)
>> to that on Figure 10.11 (lookup performance) in the preceding paragraphs
>> is not evident and I got lost for a while when I reread this section.
>>
>> How about the following change?
>>
>> diff --git a/datastruct/datastruct.tex b/datastruct/datastruct.tex
>> index adb102d4..9e386e99 100644
>> --- a/datastruct/datastruct.tex
>> +++ b/datastruct/datastruct.tex
>> @@ -941,6 +941,7 @@ pointers.
>> Of course, all three of these implementations beat global locking.
>>
>> It is quite possible that the differences in lookup performance
>> +(\cref{fig:datastruct:Read-Side RCU-Protected Hash-Table Performance For Schroedinger's Zoo in the Presence of Updates})
>> are affected by the differences in update rates.
>> One way to check this is to artificially throttle the update rates of
>> per-bucket locking and hazard pointers to match that of RCU\@.
>> @@ -958,7 +959,7 @@ not recommended for production use.
>> The dangers of extrapolating from 28 CPUs to 448 CPUs was
>> made quite clear in
>> \cref{sec:datastruct:Hash-Table Performance}.
>> - But why should extrapolating up from 448 CPUs be any safer?
>> + Would extrapolating up from 448 CPUs be any safer?
>> }\QuickQuizAnswer{
>> In theory, it isn't any safer, and a useful exercise would be
>> to run these programs on larger systems.
>
> I took this and also made more changes to the answer. Does the following
> seem reasonable?
Looks good to me!
Thanks, Akira
>
> Thanx, Paul
>
> ------------------------------------------------------------------------
>
> commit 279d626e3bcdd555031dc757441b06792ea58d38
> Author: Paul E. McKenney <paulmck@xxxxxxxxxx>
> Date: Fri Aug 20 13:00:56 2021 -0700
>
> datastruct: Expand on dangers of extrapolation
>
> This commit clarifies and expands on QQ10.9, which covers the dangers
> of extrapolation. This commit also includes a change in wording of the
> question suggested by Akira Yokosawa.
>
> Reported-by: Zhouyi Zhou <zhouzhouyi@xxxxxxxxx>
> Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxx>
>
> diff --git a/datastruct/datastruct.tex b/datastruct/datastruct.tex
> index adb102d4..c3700332 100644
> --- a/datastruct/datastruct.tex
> +++ b/datastruct/datastruct.tex
> @@ -955,17 +955,26 @@ usually be reliable enough for benchmarking purposes, it is absolutely
> not recommended for production use.
>
> \QuickQuiz{
> - The dangers of extrapolating from 28 CPUs to 448 CPUs was
> + The dangers of extrapolating from 28~CPUs to 448~CPUs was
> made quite clear in
> \cref{sec:datastruct:Hash-Table Performance}.
> - But why should extrapolating up from 448 CPUs be any safer?
> + Would extrapolating up from 448~CPUs be any safer?
> }\QuickQuizAnswer{
> - In theory, it isn't any safer, and a useful exercise would be
> + In theory, no, it isn't any safer, and a useful exercise would be
> to run these programs on larger systems.
> - In practice, there are a lot more systems with more than 28~CPUs
> - than there are systems with more than 448 CPUs.
> + In practice, there are only a very few systems with more than
> + 448~CPUs, in contrast to the huge number having more than 28~CPUs.
> + This means that although it is dangerous to extrapolate beyond
> + 448~CPUs, there is very little need to do so.
> +
> In addition, other testing has shown that RCU read-side primitives
> - offer consistent performance and scalability up to at least 1024 CPUs.
> + offer consistent performance and scalability up to at least 1024~CPUs.
> + However, is useful to review
> + \cref{fig:datastruct:Read-Only RCU-Protected Hash-Table Performance For Schr\"odinger's Zoo at 448 CPUs; Varying Table Size}
> + and its associated commentary.
> + You see, unlike the 448-CPU system that provided this data,
> + the system enjoying linear scalability up to 1024~CPUs boasted
> + excellent memory bandwidth.
> }\QuickQuizEnd
>
> % @@@ Testing strategy. Summarize hashtorture, add QQ for additional
>
