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@xxxxxxxxxx> 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@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
