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
