Re: [PATCH-perfbook] Fix a little grammar mistake

[Zhouyi Zhou <zhouzhouyi@gmail.com>]

Thank you Paul and thank you Akira

The new edition is even more superior. I revised our Chinese Edition
accordingly.

Best Wishes
Zhouyi

On Sat, Aug 21, 2021 at 4:04 AM Paul E. McKenney <paulmck@kernel.org> 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?
>
>                                                         Thanx, Paul
>
> ------------------------------------------------------------------------
>
> commit 279d626e3bcdd555031dc757441b06792ea58d38
> Author: Paul E. McKenney <paulmck@kernel.org>
> 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@gmail.com>
>     Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
>
> 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