Question about Table E.1

Question about Table E.1

[Leonardo Brás]

Hello Paul,

I have been reading the book, until I stumbled on Quick Quiz 3.7,
Table E.1: Performance of Synchronization Mechanisms
on 16-CPU 2.8 GHz Intel X5550 (Nehalem) System

<Copying from source, since the PDF is a little tricky>

The first part looks like:

        Clock period            &           0.4 &           1.0 \\
        Same-CPU CAS            &          12.2 &          33.8 \\
        Same-CPU lock           &          25.6 &          71.2 \\
        Blind CAS               &          12.9 &          35.8 \\
        CAS                     &           7.0 &          19.4 \\
 
In this case, what would be the last lines "Blind CAS" and "CAS" referring to ? 

(For a second I thought it could be "In-Core Blind CAS" and "In-Core CAS" like
in Table 3.1, but that would not make sense: This "CAS" is faster than the
previous "Same-CPU CAS". )

Thanks for reading,
Leo

Re: Question about Table E.1

[Paul E. McKenney]

On Wed, Feb 08, 2023 at 12:07:20AM -0300, Leonardo Brás wrote:
> Hello Paul,
> 
> I have been reading the book, until I stumbled on Quick Quiz 3.7,
> Table E.1: Performance of Synchronization Mechanisms
> on 16-CPU 2.8 GHz Intel X5550 (Nehalem) System
> 
> <Copying from source, since the PDF is a little tricky>
> 
> The first part looks like:
> 
>         Clock period            &           0.4 &           1.0 \\
>         Same-CPU CAS            &          12.2 &          33.8 \\
>         Same-CPU lock           &          25.6 &          71.2 \\
>         Blind CAS               &          12.9 &          35.8 \\
>         CAS                     &           7.0 &          19.4 \\
>  
> In this case, what would be the last lines "Blind CAS" and "CAS" referring to ? 
> 
> (For a second I thought it could be "In-Core Blind CAS" and "In-Core CAS" like
> in Table 3.1, but that would not make sense: This "CAS" is faster than the
> previous "Same-CPU CAS". )

I was surprised myself, but those measurements are quite real.  My best
guess is that the two threads in the core are able to overlap their
accesses, while the single CPU must do everything sequentially.

Strange, but whatever the reason, true!  ;-)

							Thanx, Paul

Re: Question about Table E.1

[Leonardo Brás]

On Tue, 2023-02-07 at 19:41 -0800, Paul E. McKenney wrote:
> On Wed, Feb 08, 2023 at 12:07:20AM -0300, Leonardo Brás wrote:
> > Hello Paul,
> > 
> > I have been reading the book, until I stumbled on Quick Quiz 3.7,
> > Table E.1: Performance of Synchronization Mechanisms
> > on 16-CPU 2.8 GHz Intel X5550 (Nehalem) System
> > 
> > <Copying from source, since the PDF is a little tricky>
> > 
> > The first part looks like:
> > 
> >         Clock period            &           0.4 &           1.0 \\
> >         Same-CPU CAS            &          12.2 &          33.8 \\
> >         Same-CPU lock           &          25.6 &          71.2 \\
> >         Blind CAS               &          12.9 &          35.8 \\
> >         CAS                     &           7.0 &          19.4 \\
> >  
> > In this case, what would be the last lines "Blind CAS" and "CAS" referring to ? 
> > 
> > (For a second I thought it could be "In-Core Blind CAS" and "In-Core CAS" like
> > in Table 3.1, but that would not make sense: This "CAS" is faster than the
> > previous "Same-CPU CAS". )
> 
> I was surprised myself, but those measurements are quite real.  My best
> guess is that the two threads in the core are able to overlap their
> accesses, while the single CPU must do everything sequentially.
> 
> Strange, but whatever the reason, true!  ;-)

Yeah, even more strange is that in this case Blind CAS was actually slower than
CAS. Anyway, your suggestion on overlapping accesses make sense.

I want to suggest a change, but it's easier to discuss this over a patch.

> 
> 							Thanx, Paul

Thank you!
Leo

Re: Question about Table E.1

[Leonardo Brás]

On Tue, 2023-02-07 at 19:41 -0800, Paul E. McKenney wrote:
> On Wed, Feb 08, 2023 at 12:07:20AM -0300, Leonardo Brás wrote:
> > Hello Paul,
> > 
> > I have been reading the book, until I stumbled on Quick Quiz 3.7,
> > Table E.1: Performance of Synchronization Mechanisms
> > on 16-CPU 2.8 GHz Intel X5550 (Nehalem) System
> > 
> > <Copying from source, since the PDF is a little tricky>
> > 
> > The first part looks like:
> > 
> >         Clock period            &           0.4 &           1.0 \\
> >         Same-CPU CAS            &          12.2 &          33.8 \\
> >         Same-CPU lock           &          25.6 &          71.2 \\
> >         Blind CAS               &          12.9 &          35.8 \\
> >         CAS                     &           7.0 &          19.4 \\
> >  
> > In this case, what would be the last lines "Blind CAS" and "CAS" referring to ? 
> > 
> > (For a second I thought it could be "In-Core Blind CAS" and "In-Core CAS" like
> > in Table 3.1, but that would not make sense: This "CAS" is faster than the
> > previous "Same-CPU CAS". )
> 
> I was surprised myself, but those measurements are quite real.  My best
> guess is that the two threads in the core are able to overlap their
> accesses, while the single CPU must do everything sequentially.

IMHO This phrase would look great as a footnote for this page, clearing any
question like mine. What do you think about it?

> 
> Strange, but whatever the reason, true!  ;-)
> 
> 							Thanx, Paul

Re: Question about Table E.1

[Akira Yokosawa]

Hi,

On Tue, 7 Feb 2023 19:41:02 -0800, Paul E. McKenney wrote:
> On Wed, Feb 08, 2023 at 12:07:20AM -0300, Leonardo Brás wrote:
>> Hello Paul,
>>
>> I have been reading the book, until I stumbled on Quick Quiz 3.7,
>> Table E.1: Performance of Synchronization Mechanisms
>> on 16-CPU 2.8 GHz Intel X5550 (Nehalem) System
>>
>> <Copying from source, since the PDF is a little tricky>
>>
>> The first part looks like:
>>
>>         Clock period            &           0.4 &           1.0 \\
>>         Same-CPU CAS            &          12.2 &          33.8 \\
>>         Same-CPU lock           &          25.6 &          71.2 \\
>>         Blind CAS               &          12.9 &          35.8 \\
>>         CAS                     &           7.0 &          19.4 \\
>>  
>> In this case, what would be the last lines "Blind CAS" and "CAS" referring to ? 
>>
>> (For a second I thought it could be "In-Core Blind CAS" and "In-Core CAS" like
>> in Table 3.1, but that would not make sense: This "CAS" is faster than the
>> previous "Same-CPU CAS". )
> 
> I was surprised myself, but those measurements are quite real.  My best
> guess is that the two threads in the core are able to overlap their
> accesses, while the single CPU must do everything sequentially.

Paul, do you remember how you obtained the data set?
There are several data sets under CodeSamples/cpu/data/, but I don't
see the one corresponds to the table.

The code for collecting these data was added in CodeSamples/cpu/
by commit 81989d7483e2 ("cpu: Reproduce the old cache-to-cache
latency measurement code") in 2020. And the next commit 2fc05ca07edc
("api-pthreads.h: Use clock_gettime() and check sched_setaffinity()")
improved the stability of reproduced code.

This table was first added in commit 38fd945ff401 ("Fill out CPU
chapter, including adding Nehalem data.") in 2009.
The data have never been updated since.

I'm kind of suspecting the "7.0 us" which surprised you at the time
might have been an outlier due to some disturbance discussed in
Appendix A.3 "What Time Is It?".

I'm not sure, just guessing...

        Thanks, Akira

> 
> Strange, but whatever the reason, true!  ;-)
> 
> 							Thanx, Paul

Re: Question about Table E.1

[Akira Yokosawa]

On Wed, 8 Feb 2023 17:47:31 +0900, Akira Yokosawa wrote:
> Hi,
> 
> On Tue, 7 Feb 2023 19:41:02 -0800, Paul E. McKenney wrote:
>> On Wed, Feb 08, 2023 at 12:07:20AM -0300, Leonardo Brás wrote:
>>> Hello Paul,
>>>
>>> I have been reading the book, until I stumbled on Quick Quiz 3.7,
>>> Table E.1: Performance of Synchronization Mechanisms
>>> on 16-CPU 2.8 GHz Intel X5550 (Nehalem) System
>>>
>>> <Copying from source, since the PDF is a little tricky>
>>>
>>> The first part looks like:
>>>
>>>         Clock period            &           0.4 &           1.0 \\
>>>         Same-CPU CAS            &          12.2 &          33.8 \\
>>>         Same-CPU lock           &          25.6 &          71.2 \\
>>>         Blind CAS               &          12.9 &          35.8 \\
>>>         CAS                     &           7.0 &          19.4 \\
>>>  
>>> In this case, what would be the last lines "Blind CAS" and "CAS" referring to ? 
>>>
>>> (For a second I thought it could be "In-Core Blind CAS" and "In-Core CAS" like
>>> in Table 3.1, but that would not make sense: This "CAS" is faster than the
>>> previous "Same-CPU CAS". )
>>
>> I was surprised myself, but those measurements are quite real.  My best
>> guess is that the two threads in the core are able to overlap their
>> accesses, while the single CPU must do everything sequentially.
> 
> Paul, do you remember how you obtained the data set?
> There are several data sets under CodeSamples/cpu/data/, but I don't
> see the one corresponds to the table.
> 
> The code for collecting these data was added in CodeSamples/cpu/
> by commit 81989d7483e2 ("cpu: Reproduce the old cache-to-cache
> latency measurement code") in 2020. And the next commit 2fc05ca07edc
> ("api-pthreads.h: Use clock_gettime() and check sched_setaffinity()")
> improved the stability of reproduced code.
> 
> This table was first added in commit 38fd945ff401 ("Fill out CPU
> chapter, including adding Nehalem data.") in 2009.
> The data have never been updated since.
> 
> I'm kind of suspecting the "7.0 us" which surprised you at the time
I mean,                      "7.0 ns"

        Thanks, Akira

> might have been an outlier due to some disturbance discussed in
> Appendix A.3 "What Time Is It?".
> 
> I'm not sure, just guessing...
> 
>         Thanks, Akira
> 
>>
>> Strange, but whatever the reason, true!  ;-)
>>
>> 							Thanx, Paul

Re: Question about Table E.1

[Paul E. McKenney]

On Wed, Feb 08, 2023 at 07:26:58PM +0900, Akira Yokosawa wrote:
> On Wed, 8 Feb 2023 17:47:31 +0900, Akira Yokosawa wrote:
> > Hi,
> > 
> > On Tue, 7 Feb 2023 19:41:02 -0800, Paul E. McKenney wrote:
> >> On Wed, Feb 08, 2023 at 12:07:20AM -0300, Leonardo Brás wrote:
> >>> Hello Paul,
> >>>
> >>> I have been reading the book, until I stumbled on Quick Quiz 3.7,
> >>> Table E.1: Performance of Synchronization Mechanisms
> >>> on 16-CPU 2.8 GHz Intel X5550 (Nehalem) System
> >>>
> >>> <Copying from source, since the PDF is a little tricky>
> >>>
> >>> The first part looks like:
> >>>
> >>>         Clock period            &           0.4 &           1.0 \\
> >>>         Same-CPU CAS            &          12.2 &          33.8 \\
> >>>         Same-CPU lock           &          25.6 &          71.2 \\
> >>>         Blind CAS               &          12.9 &          35.8 \\
> >>>         CAS                     &           7.0 &          19.4 \\
> >>>  
> >>> In this case, what would be the last lines "Blind CAS" and "CAS" referring to ? 
> >>>
> >>> (For a second I thought it could be "In-Core Blind CAS" and "In-Core CAS" like
> >>> in Table 3.1, but that would not make sense: This "CAS" is faster than the
> >>> previous "Same-CPU CAS". )
> >>
> >> I was surprised myself, but those measurements are quite real.  My best
> >> guess is that the two threads in the core are able to overlap their
> >> accesses, while the single CPU must do everything sequentially.
> > 
> > Paul, do you remember how you obtained the data set?
> > There are several data sets under CodeSamples/cpu/data/, but I don't
> > see the one corresponds to the table.
> > 
> > The code for collecting these data was added in CodeSamples/cpu/
> > by commit 81989d7483e2 ("cpu: Reproduce the old cache-to-cache
> > latency measurement code") in 2020. And the next commit 2fc05ca07edc
> > ("api-pthreads.h: Use clock_gettime() and check sched_setaffinity()")
> > improved the stability of reproduced code.
> > 
> > This table was first added in commit 38fd945ff401 ("Fill out CPU
> > chapter, including adding Nehalem data.") in 2009.
> > The data have never been updated since.
> > 
> > I'm kind of suspecting the "7.0 us" which surprised you at the time
> I mean,                      "7.0 ns"
> 
>         Thanks, Akira
> 
> > might have been an outlier due to some disturbance discussed in
> > Appendix A.3 "What Time Is It?".
> > 
> > I'm not sure, just guessing...

My surprise caused me to beat on it, and it was persistent.

But I cannot find the raw data, either, so maybe I should delete that
table.  Though I really do like the fact that it is surprising, based
on a hope that it convinces readers to expect the unexpected.

							Thanx, Paul

> >         Thanks, Akira
> > 
> >>
> >> Strange, but whatever the reason, true!  ;-)
> >>
> >> 							Thanx, Paul

Re: Question about Table E.1

[Akira Yokosawa]

On Wed, 8 Feb 2023 14:15:22 -0800, Paul E. McKenney wrote:
> On Wed, Feb 08, 2023 at 07:26:58PM +0900, Akira Yokosawa wrote:
>> On Wed, 8 Feb 2023 17:47:31 +0900, Akira Yokosawa wrote:
>>> Hi,
>>>
>>> On Tue, 7 Feb 2023 19:41:02 -0800, Paul E. McKenney wrote:
>>>> On Wed, Feb 08, 2023 at 12:07:20AM -0300, Leonardo Brás wrote:
>>>>> Hello Paul,
>>>>>
>>>>> I have been reading the book, until I stumbled on Quick Quiz 3.7,
>>>>> Table E.1: Performance of Synchronization Mechanisms
>>>>> on 16-CPU 2.8 GHz Intel X5550 (Nehalem) System
>>>>>
>>>>> <Copying from source, since the PDF is a little tricky>
>>>>>
>>>>> The first part looks like:
>>>>>
>>>>>         Clock period            &           0.4 &           1.0 \\
>>>>>         Same-CPU CAS            &          12.2 &          33.8 \\
>>>>>         Same-CPU lock           &          25.6 &          71.2 \\
>>>>>         Blind CAS               &          12.9 &          35.8 \\
>>>>>         CAS                     &           7.0 &          19.4 \\
>>>>>  
>>>>> In this case, what would be the last lines "Blind CAS" and "CAS" referring to ? 
>>>>>
>>>>> (For a second I thought it could be "In-Core Blind CAS" and "In-Core CAS" like
>>>>> in Table 3.1, but that would not make sense: This "CAS" is faster than the
>>>>> previous "Same-CPU CAS". )
>>>>
>>>> I was surprised myself, but those measurements are quite real.  My best
>>>> guess is that the two threads in the core are able to overlap their
>>>> accesses, while the single CPU must do everything sequentially.
>>>
>>> Paul, do you remember how you obtained the data set?
>>> There are several data sets under CodeSamples/cpu/data/, but I don't
>>> see the one corresponds to the table.
>>>
>>> The code for collecting these data was added in CodeSamples/cpu/
>>> by commit 81989d7483e2 ("cpu: Reproduce the old cache-to-cache
>>> latency measurement code") in 2020. And the next commit 2fc05ca07edc
>>> ("api-pthreads.h: Use clock_gettime() and check sched_setaffinity()")
>>> improved the stability of reproduced code.
>>>
>>> This table was first added in commit 38fd945ff401 ("Fill out CPU
>>> chapter, including adding Nehalem data.") in 2009.
>>> The data have never been updated since.
>>>
>>> I'm kind of suspecting the "7.0 us" which surprised you at the time
>> I mean,                      "7.0 ns"
>>
>>         Thanks, Akira
>>
>>> might have been an outlier due to some disturbance discussed in
>>> Appendix A.3 "What Time Is It?".
>>>
>>> I'm not sure, just guessing...
> 
> My surprise caused me to beat on it, and it was persistent.

I see.  So the "outlier" was the microarchitecture of that
X5550 (Nehalem), I guess.
I'd love to reproduce the behavior if at all possible.

> 
> But I cannot find the raw data, either, so maybe I should delete that
> table.  Though I really do like the fact that it is surprising, based
> on a hope that it convinces readers to expect the unexpected.

That episode would be a good Quick Quiz if the Answer to QQz
could have a nested QQz inside it.
Unfortunately that is not possible...

        Thanks, Akira

> 
> 							Thanx, Paul
> 
>>>         Thanks, Akira
>>>
>>>>
>>>> Strange, but whatever the reason, true!  ;-)
>>>>
>>>> 							Thanx, Paul

Re: Question about Table E.1

[Akira Yokosawa]

On Thu, 9 Feb 2023 08:49:46 +0900, Akira Yokosawa wrote:
> On Wed, 8 Feb 2023 14:15:22 -0800, Paul E. McKenney wrote:
>> My surprise caused me to beat on it, and it was persistent.
> 
> I see.  So the "outlier" was the microarchitecture of that
> X5550 (Nehalem), I guess.
> I'd love to reproduce the behavior if at all possible.
> 
>>
>> But I cannot find the raw data, either, so maybe I should delete that
>> table.  Though I really do like the fact that it is surprising, based
>> on a hope that it convinces readers to expect the unexpected.
> 
> That episode would be a good Quick Quiz if the Answer to QQz
> could have a nested QQz inside it.
> Unfortunately that is not possible...

On second thought, it should be possible to put a QQz next to QQz 3.7
citing Table E.1 in the Quiz part.

Let me try and produce a PoC patch.

        Thanks, Akira

> 
>         Thanks, Akira
> 
>>
>> 							Thanx, Paul
>>
>>>>         Thanks, Akira
>>>>
>>>>>
>>>>> Strange, but whatever the reason, true!  ;-)
>>>>>
>>>>> 							Thanx, Paul

[PATCH -perfbook] cpu: PoC of A QQz citing table in answer to another QQz (was Re: Question about Table E.1)

[Akira Yokosawa]

Subject: [PATCH -perfbook] cpu: Add a QQz citing table E.1

An email thread started from a question from Leo [1] stimulated
me to add a QQz on Paul's experience back in 2009.

Link: [1] https://www.spinics.net/lists/perfbook/msg03824.html
Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
---
I wrote:
> On second thought, it should be possible to put a QQz next to QQz 3.7
> citing Table E.1 in the Quiz part.
> 
> Let me try and produce a PoC patch.

Something like this?

I couldn't make the QQz next to QQz 3.7 due to the

  \QuickQuizLabel{\QspeedOfLightAtoms}

just below QQz 3.7.
If you put the label in the middle of

\QuickQuizSeries{
 ...
}

, you will get build errors in -nq builds. 

Instead, I added it next to QQz 3.8 (or the end of Section 3.2.2).
It looks still relevant there.

The wording of the Quiz and its Answer is just a stub.
Paul, feel free to rewrite them as you like.

        Thanks, Akira
--
 cpu/overheads.tex | 24 +++++++++++++++++++++---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/cpu/overheads.tex b/cpu/overheads.tex
index 0d8270bf6e17..cff847cdadbf 100644
--- a/cpu/overheads.tex
+++ b/cpu/overheads.tex
@@ -485,10 +485,11 @@ cycles, as shown in the ``Global Comms'' row.
 %     page 6/76 'Leading Interconnect, Leading Performance'
 % Needs updating...
 
-\QuickQuiz{
+\QuickQuizSeries{%
+\QuickQuizB{
 	These numbers are insanely large!
 	How can I possibly get my head around them?
-}\QuickQuizAnswer{
+}\QuickQuizAnswerB{
 	Get a roll of toilet paper.
 	In the USA, each roll will normally have somewhere around
 	350--500 sheets.
@@ -516,7 +517,24 @@ cycles, as shown in the ``Global Comms'' row.
 	You might wish to avoid disabling interrupts across that many
 	cache misses.\footnote{
 		Kudos to Matthew Wilcox for this holding-breath analogy.}
-}\QuickQuizEnd
+}\QuickQuizEndB
+%
+\QuickQuizE{
+	\Cref{tab:cpu:Performance of Synchronization Mechanisms on 16-CPU 2.8GHz Intel X5550 (Nehalem) System}
+	in the answer to \QuickQuizARef{\QspeedOfLightAtoms} says that
+	In-Core CAS is faster than both of Same-CPU CAS and In-Core Blind CAS\@.
+	What is happening there?
+}\QuickQuizAnswerE{
+	I \emph{was} surprised by the data I obtained and did a rigorous
+	check of their validity.
+	I got the same result persistently.
+	One theory that might explain the observation would be:
+	The two threads in the core are able to overlap their accesses,
+	while the single CPU must do everything sequentially.
+	Unfortunately, there seems to be no public documentation explaining
+	why the Intel X5550 (Nehalem) system behaved like that.
+}\QuickQuizEndE
+}                 % End of \QuickQuizSeries
 
 \subsection{Hardware Optimizations}
 \label{sec:cpu:Hardware Optimizations}

base-commit: 14440e232cc1b2580dc1a73f873dc29fe3aea02b
-- 
2.25.1

Re: [PATCH -perfbook] cpu: PoC of A QQz citing table in answer to another QQz (was Re: Question about Table E.1)

[Leonardo Brás]

On Fri, 2023-02-10 at 00:12 +0900, Akira Yokosawa wrote:
> Subject: [PATCH -perfbook] cpu: Add a QQz citing table E.1
> 
> An email thread started from a question from Leo [1] stimulated
> me to add a QQz on Paul's experience back in 2009.
> 
> Link: [1] https://www.spinics.net/lists/perfbook/msg03824.html
> Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
> ---
> I wrote:
> > On second thought, it should be possible to put a QQz next to QQz 3.7
> > citing Table E.1 in the Quiz part.
> > 
> > Let me try and produce a PoC patch.
> 
> Something like this?
> 
> I couldn't make the QQz next to QQz 3.7 due to the
> 
>   \QuickQuizLabel{\QspeedOfLightAtoms}
> 
> just below QQz 3.7.
> If you put the label in the middle of
> 
> \QuickQuizSeries{
>  ...
> }
> 
> , you will get build errors in -nq builds. 
> 
> Instead, I added it next to QQz 3.8 (or the end of Section 3.2.2).
> It looks still relevant there.
> 
> The wording of the Quiz and its Answer is just a stub.
> Paul, feel free to rewrite them as you like.
> 
>         Thanks, Akira
> --
>  cpu/overheads.tex | 24 +++++++++++++++++++++---
>  1 file changed, 21 insertions(+), 3 deletions(-)
> 
> diff --git a/cpu/overheads.tex b/cpu/overheads.tex
> index 0d8270bf6e17..cff847cdadbf 100644
> --- a/cpu/overheads.tex
> +++ b/cpu/overheads.tex
> @@ -485,10 +485,11 @@ cycles, as shown in the ``Global Comms'' row.
>  %     page 6/76 'Leading Interconnect, Leading Performance'
>  % Needs updating...
>  
> -\QuickQuiz{
> +\QuickQuizSeries{%
> +\QuickQuizB{
>  	These numbers are insanely large!
>  	How can I possibly get my head around them?
> -}\QuickQuizAnswer{
> +}\QuickQuizAnswerB{
>  	Get a roll of toilet paper.
>  	In the USA, each roll will normally have somewhere around
>  	350--500 sheets.
> @@ -516,7 +517,24 @@ cycles, as shown in the ``Global Comms'' row.
>  	You might wish to avoid disabling interrupts across that many
>  	cache misses.\footnote{
>  		Kudos to Matthew Wilcox for this holding-breath analogy.}
> -}\QuickQuizEnd
> +}\QuickQuizEndB
> +%
> +\QuickQuizE{
> +	\Cref{tab:cpu:Performance of Synchronization Mechanisms on 16-CPU 2.8GHz Intel X5550 (Nehalem) System}
> +	in the answer to \QuickQuizARef{\QspeedOfLightAtoms} says that
> +	In-Core CAS is faster than both of Same-CPU CAS and In-Core Blind CAS\@.
> +	What is happening there?
> +}\QuickQuizAnswerE{
> +	I \emph{was} surprised by the data I obtained and did a rigorous
> +	check of their validity.
> +	I got the same result persistently.
> +	One theory that might explain the observation would be:
> +	The two threads in the core are able to overlap their accesses,
> +	while the single CPU must do everything sequentially.
> +	Unfortunately, there seems to be no public documentation explaining
> +	why the Intel X5550 (Nehalem) system behaved like that.
> +}\QuickQuizEndE
> +}                 % End of \QuickQuizSeries
>  
>  \subsection{Hardware Optimizations}
>  \label{sec:cpu:Hardware Optimizations}
> 
> base-commit: 14440e232cc1b2580dc1a73f873dc29fe3aea02b

Tested on Gitlab:
https://gitlab.com/linux-kernel/perfbook/-/pipelines/774642106

Observations for this PDF:
QQz 3.7 has the mentioned table.
QQz 3.9 has the comment on the table.
'Question + link' to QQz 3.9 appears in Chapter 3, on the page after 'question +
link' to QQz 3.7.

Is that the desired output?

(It feels a little 'misplaced', TBH. The best place would be just after QQz 3.7,
but looking into your comments, it seems it was not possible.)


Anyway, if the desired output was achieved:

Tested-by: Leonardo Bras <leobras@redhat.com>
Reviewed-by: Leonardo Bras <leobras@redhat.com>


Best regards,
Leo

Re: [PATCH -perfbook] cpu: PoC of A QQz citing table in answer to another QQz (was Re: Question about Table E.1)

[Akira Yokosawa]

On Sat, 11 Feb 2023 05:49:49 -0300, Leonardo Brás wrote:
> On Fri, 2023-02-10 at 00:12 +0900, Akira Yokosawa wrote:
>> Subject: [PATCH -perfbook] cpu: Add a QQz citing table E.1
>>
>> An email thread started from a question from Leo [1] stimulated
>> me to add a QQz on Paul's experience back in 2009.
>>
>> Link: [1] https://www.spinics.net/lists/perfbook/msg03824.html
>> Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
>> ---
>> I wrote:
>>> On second thought, it should be possible to put a QQz next to QQz 3.7
>>> citing Table E.1 in the Quiz part.
>>>
>>> Let me try and produce a PoC patch.
>>
>> Something like this?
>>
>> I couldn't make the QQz next to QQz 3.7 due to the
>>
>>   \QuickQuizLabel{\QspeedOfLightAtoms}
>>
>> just below QQz 3.7.
>> If you put the label in the middle of
>>
>> \QuickQuizSeries{
>>  ...
>> }
>>
>> , you will get build errors in -nq builds. 
>>
>> Instead, I added it next to QQz 3.8 (or the end of Section 3.2.2).
>> It looks still relevant there.
>>
>> The wording of the Quiz and its Answer is just a stub.
>> Paul, feel free to rewrite them as you like.
>>
>>         Thanks, Akira
>> --
>>  cpu/overheads.tex | 24 +++++++++++++++++++++---
>>  1 file changed, 21 insertions(+), 3 deletions(-)
>>
...
> 
> Tested on Gitlab:
> https://gitlab.com/linux-kernel/perfbook/-/pipelines/774642106

Thank you for testing!

> 
> Observations for this PDF:
> QQz 3.7 has the mentioned table.
> QQz 3.9 has the comment on the table.
> 'Question + link' to QQz 3.9 appears in Chapter 3, on the page after 'question +
> link' to QQz 3.7.
> 
> Is that the desired output?
> 
> (It feels a little 'misplaced', TBH. The best place would be just after QQz 3.7,
> but looking into your comments, it seems it was not possible.)

I think I have figured out the way for placing it next to QQz 3.7.

Will post a v2 after testing on my side.

        Thanks, Akira

> 
> 
> Anyway, if the desired output was achieved:
> 
> Tested-by: Leonardo Bras <leobras@redhat.com>
> Reviewed-by: Leonardo Bras <leobras@redhat.com>
> 
> 
> Best regards,
> Leo

[PATCH -perfbook v2] cpu: Add a QQz on table E.1

[Akira Yokosawa]

An email thread started from a question from Leo [1] stimulated
me to add a QQz on Paul's experience back in 2009.

As \QuickQuizLabel{} inside \QuickQuizSeries{} doesn't work in
-nq builds, define \QuickQuizLabelRel{}{} and put it in front
of the series.

Link: [1] https://www.spinics.net/lists/perfbook/msg03824.html
Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
Cc: Leonardo Brás <leobras.c@gmail.com>
---
v2: Place new QQz next to QQz 3.7

--
 cpu/overheads.tex | 28 +++++++++++++++++++++++-----
 qqz.sty           | 16 ++++++++++++++++
 2 files changed, 39 insertions(+), 5 deletions(-)

diff --git a/cpu/overheads.tex b/cpu/overheads.tex
index 0d8270bf6e17..a89c71158bf9 100644
--- a/cpu/overheads.tex
+++ b/cpu/overheads.tex
@@ -290,12 +290,15 @@ nanoseconds, or more than seven hundred clock cycles.
 A CAS operation consumes almost a full microsecond, or almost two
 thousand clock cycles.
 
-\QuickQuiz{
+\QuickQuizLabelRel{\QspeedOfLightAtoms}{1} % cann't put label inside QQSeries
+
+\QuickQuizSeries{%
+\QuickQuizB{
 	Surely the hardware designers could be persuaded to improve
 	this situation!
 	Why have they been content with such abysmal performance
 	for these single-instruction operations?
-}\QuickQuizAnswer{
+}\QuickQuizAnswerB{
 	The hardware designers \emph{have} been working on this
 	problem, and have consulted with no less a luminary than
 	the late physicist Stephen Hawking.
@@ -423,9 +426,24 @@ thousand clock cycles.
 	\Cref{sec:cpu:Hardware Free Lunch?}
 	looks at what else hardware designers might be
 	able to do to ease the plight of parallel programmers.
-}\QuickQuizEnd
-
-\QuickQuizLabel{\QspeedOfLightAtoms}
+}\QuickQuizEndB
+%
+\QuickQuizE{
+	\Cref{tab:cpu:Performance of Synchronization Mechanisms on 16-CPU 2.8GHz Intel X5550 (Nehalem) System}
+	in the answer to \QuickQuizARef{\QspeedOfLightAtoms} says that
+	In-Core CAS is faster than both of Same-CPU CAS and In-Core Blind CAS\@.
+	What is happening there?
+}\QuickQuizAnswerE{
+	I \emph{was} surprised by the data I obtained and did a rigorous
+	check of their validity.
+	I got the same result persistently.
+	One theory that might explain the observation would be:
+	The two threads in the core are able to overlap their accesses,
+	while the single CPU must do everything sequentially.
+	Unfortunately, there seems to be no public documentation explaining
+	why the Intel X5550 (Nehalem) system behaved like that.
+}\QuickQuizEndE
+}                 % End of \QuickQuizSeries
 
 \begin{table}
 \rowcolors{1}{}{lightgray}
diff --git a/qqz.sty b/qqz.sty
index a3a9f22d1ba9..5c7eb5340194 100644
--- a/qqz.sty
+++ b/qqz.sty
@@ -156,6 +156,11 @@
 
 % To create a macro referencing the previously defined quick quiz:
 %	\QuickQuizLabel{\QQname}
+%
+% When labeling a QQz inside \QuickQuizSeries{}, use
+%	\QuickQuizLabelRel{\QQname}{rel}
+% in front of the series.
+%
 % To reference the macro in the text:
 %	\QuickQuizRef{\QQname}
 % To reference the answer of the macro in the text:
@@ -166,6 +171,11 @@
 \newcommand{\QuickQuizLabel}[1]{
 	\edef#1{\thechapter.\thequickquizctrP}
 }
+\newcommand{\QuickQuizLabelRel}[2]{
+        \addtocounter{quickquizctrP}{#2}
+	\QuickQuizLabel{#1}
+	\addtocounter{quickquizctrP}{-#2}
+}
 \newcommand{\QuickQuizRef}[1]{%
 	\hyperref[QQ.#1]{Quick Quiz~#1}%
 }
@@ -176,6 +186,12 @@
 \newcommand{\QuickQuizLabel}[1]{
 	\edef#1{\thechapter.\thequickquizctr}
 }
+\newcommand{\QuickQuizLabelRel}[2]{
+        \addtocounter{quickquizctr}{#2}
+	\QuickQuizLabel{#1}
+	\addtocounter{quickquizctr}{-#2}
+}
+
 \newcommand{\QuickQuizRef}[1]{%
 	\hyperref[QQ.#1]{Quick Quiz~#1}%
 }

base-commit: 14440e232cc1b2580dc1a73f873dc29fe3aea02b
-- 
2.25.1

Re: [PATCH -perfbook v2] cpu: Add a QQz on table E.1

[Paul E. McKenney]

On Sun, Feb 12, 2023 at 09:42:07AM +0900, Akira Yokosawa wrote:
> An email thread started from a question from Leo [1] stimulated
> me to add a QQz on Paul's experience back in 2009.
> 
> As \QuickQuizLabel{} inside \QuickQuizSeries{} doesn't work in
> -nq builds, define \QuickQuizLabelRel{}{} and put it in front
> of the series.
> 
> Link: [1] https://www.spinics.net/lists/perfbook/msg03824.html
> Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
> Cc: Leonardo Brás <leobras.c@gmail.com>

Queued and pushed, thank you!

							Thanx, Paul

> ---
> v2: Place new QQz next to QQz 3.7
> 
> --
>  cpu/overheads.tex | 28 +++++++++++++++++++++++-----
>  qqz.sty           | 16 ++++++++++++++++
>  2 files changed, 39 insertions(+), 5 deletions(-)
> 
> diff --git a/cpu/overheads.tex b/cpu/overheads.tex
> index 0d8270bf6e17..a89c71158bf9 100644
> --- a/cpu/overheads.tex
> +++ b/cpu/overheads.tex
> @@ -290,12 +290,15 @@ nanoseconds, or more than seven hundred clock cycles.
>  A CAS operation consumes almost a full microsecond, or almost two
>  thousand clock cycles.
>  
> -\QuickQuiz{
> +\QuickQuizLabelRel{\QspeedOfLightAtoms}{1} % cann't put label inside QQSeries
> +
> +\QuickQuizSeries{%
> +\QuickQuizB{
>  	Surely the hardware designers could be persuaded to improve
>  	this situation!
>  	Why have they been content with such abysmal performance
>  	for these single-instruction operations?
> -}\QuickQuizAnswer{
> +}\QuickQuizAnswerB{
>  	The hardware designers \emph{have} been working on this
>  	problem, and have consulted with no less a luminary than
>  	the late physicist Stephen Hawking.
> @@ -423,9 +426,24 @@ thousand clock cycles.
>  	\Cref{sec:cpu:Hardware Free Lunch?}
>  	looks at what else hardware designers might be
>  	able to do to ease the plight of parallel programmers.
> -}\QuickQuizEnd
> -
> -\QuickQuizLabel{\QspeedOfLightAtoms}
> +}\QuickQuizEndB
> +%
> +\QuickQuizE{
> +	\Cref{tab:cpu:Performance of Synchronization Mechanisms on 16-CPU 2.8GHz Intel X5550 (Nehalem) System}
> +	in the answer to \QuickQuizARef{\QspeedOfLightAtoms} says that
> +	In-Core CAS is faster than both of Same-CPU CAS and In-Core Blind CAS\@.
> +	What is happening there?
> +}\QuickQuizAnswerE{
> +	I \emph{was} surprised by the data I obtained and did a rigorous
> +	check of their validity.
> +	I got the same result persistently.
> +	One theory that might explain the observation would be:
> +	The two threads in the core are able to overlap their accesses,
> +	while the single CPU must do everything sequentially.
> +	Unfortunately, there seems to be no public documentation explaining
> +	why the Intel X5550 (Nehalem) system behaved like that.
> +}\QuickQuizEndE
> +}                 % End of \QuickQuizSeries
>  
>  \begin{table}
>  \rowcolors{1}{}{lightgray}
> diff --git a/qqz.sty b/qqz.sty
> index a3a9f22d1ba9..5c7eb5340194 100644
> --- a/qqz.sty
> +++ b/qqz.sty
> @@ -156,6 +156,11 @@
>  
>  % To create a macro referencing the previously defined quick quiz:
>  %	\QuickQuizLabel{\QQname}
> +%
> +% When labeling a QQz inside \QuickQuizSeries{}, use
> +%	\QuickQuizLabelRel{\QQname}{rel}
> +% in front of the series.
> +%
>  % To reference the macro in the text:
>  %	\QuickQuizRef{\QQname}
>  % To reference the answer of the macro in the text:
> @@ -166,6 +171,11 @@
>  \newcommand{\QuickQuizLabel}[1]{
>  	\edef#1{\thechapter.\thequickquizctrP}
>  }
> +\newcommand{\QuickQuizLabelRel}[2]{
> +        \addtocounter{quickquizctrP}{#2}
> +	\QuickQuizLabel{#1}
> +	\addtocounter{quickquizctrP}{-#2}
> +}
>  \newcommand{\QuickQuizRef}[1]{%
>  	\hyperref[QQ.#1]{Quick Quiz~#1}%
>  }
> @@ -176,6 +186,12 @@
>  \newcommand{\QuickQuizLabel}[1]{
>  	\edef#1{\thechapter.\thequickquizctr}
>  }
> +\newcommand{\QuickQuizLabelRel}[2]{
> +        \addtocounter{quickquizctr}{#2}
> +	\QuickQuizLabel{#1}
> +	\addtocounter{quickquizctr}{-#2}
> +}
> +
>  \newcommand{\QuickQuizRef}[1]{%
>  	\hyperref[QQ.#1]{Quick Quiz~#1}%
>  }
> 
> base-commit: 14440e232cc1b2580dc1a73f873dc29fe3aea02b
> -- 
> 2.25.1
> 
> 

Re: [PATCH -perfbook v2] cpu: Add a QQz on table E.1

[Akira Yokosawa]

On Sun, 12 Feb 2023 16:28:56 -0800, Paul E. McKenney wrote:
> On Sun, Feb 12, 2023 at 09:42:07AM +0900, Akira Yokosawa wrote:
>> An email thread started from a question from Leo [1] stimulated
>> me to add a QQz on Paul's experience back in 2009.
>>
>> As \QuickQuizLabel{} inside \QuickQuizSeries{} doesn't work in
>> -nq builds, define \QuickQuizLabelRel{}{} and put it in front
>> of the series.
>>
>> Link: [1] https://www.spinics.net/lists/perfbook/msg03824.html
>> Signed-off-by: Akira Yokosawa <akiygmail.com>
>> Cc: Leonardo Brás <leobras.c@gmail.com>
> 
> Queued and pushed, thank you!

Paul, can you revert c82369bef3f6 ("cpu: Add a QQz citing table E.1")?

Patch v2 happens to have no conflict with v1 and you have applied
both of them!

Now we have the same Quizzes of QQz 3.8 and QQz 3.10.

c82369bef3f6 can be reverted cleanly.

        Thanks, Akira

> 
> 							Thanx, Paul
> 
>> ---
>> v2: Place new QQz next to QQz 3.7
>>
>> --
>>  cpu/overheads.tex | 28 +++++++++++++++++++++++-----
>>  qqz.sty           | 16 ++++++++++++++++
>>  2 files changed, 39 insertions(+), 5 deletions(-)
>>
>> diff --git a/cpu/overheads.tex b/cpu/overheads.tex
>> index 0d8270bf6e17..a89c71158bf9 100644
>> --- a/cpu/overheads.tex
>> +++ b/cpu/overheads.tex
>> @@ -290,12 +290,15 @@ nanoseconds, or more than seven hundred clock cycles.
>>  A CAS operation consumes almost a full microsecond, or almost two
>>  thousand clock cycles.
>>  
>> -\QuickQuiz{
>> +\QuickQuizLabelRel{\QspeedOfLightAtoms}{1} % cann't put label inside QQSeries
>> +
>> +\QuickQuizSeries{%
>> +\QuickQuizB{
>>  	Surely the hardware designers could be persuaded to improve
>>  	this situation!
>>  	Why have they been content with such abysmal performance
>>  	for these single-instruction operations?
>> -}\QuickQuizAnswer{
>> +}\QuickQuizAnswerB{
>>  	The hardware designers \emph{have} been working on this
>>  	problem, and have consulted with no less a luminary than
>>  	the late physicist Stephen Hawking.
>> @@ -423,9 +426,24 @@ thousand clock cycles.
>>  	\Cref{sec:cpu:Hardware Free Lunch?}
>>  	looks at what else hardware designers might be
>>  	able to do to ease the plight of parallel programmers.
>> -}\QuickQuizEnd
>> -
>> -\QuickQuizLabel{\QspeedOfLightAtoms}
>> +}\QuickQuizEndB
>> +%
>> +\QuickQuizE{
>> +	\Cref{tab:cpu:Performance of Synchronization Mechanisms on 16-CPU 2.8GHz Intel X5550 (Nehalem) System}
>> +	in the answer to \QuickQuizARef{\QspeedOfLightAtoms} says that
>> +	In-Core CAS is faster than both of Same-CPU CAS and In-Core Blind CAS\@.
>> +	What is happening there?
>> +}\QuickQuizAnswerE{
>> +	I \emph{was} surprised by the data I obtained and did a rigorous
>> +	check of their validity.
>> +	I got the same result persistently.
>> +	One theory that might explain the observation would be:
>> +	The two threads in the core are able to overlap their accesses,
>> +	while the single CPU must do everything sequentially.
>> +	Unfortunately, there seems to be no public documentation explaining
>> +	why the Intel X5550 (Nehalem) system behaved like that.
>> +}\QuickQuizEndE
>> +}                 % End of \QuickQuizSeries
>>  
>>  \begin{table}
>>  \rowcolors{1}{}{lightgray}
>> diff --git a/qqz.sty b/qqz.sty
>> index a3a9f22d1ba9..5c7eb5340194 100644
>> --- a/qqz.sty
>> +++ b/qqz.sty
>> @@ -156,6 +156,11 @@
>>  
>>  % To create a macro referencing the previously defined quick quiz:
>>  %	\QuickQuizLabel{\QQname}
>> +%
>> +% When labeling a QQz inside \QuickQuizSeries{}, use
>> +%	\QuickQuizLabelRel{\QQname}{rel}
>> +% in front of the series.
>> +%
>>  % To reference the macro in the text:
>>  %	\QuickQuizRef{\QQname}
>>  % To reference the answer of the macro in the text:
>> @@ -166,6 +171,11 @@
>>  \newcommand{\QuickQuizLabel}[1]{
>>  	\edef#1{\thechapter.\thequickquizctrP}
>>  }
>> +\newcommand{\QuickQuizLabelRel}[2]{
>> +        \addtocounter{quickquizctrP}{#2}
>> +	\QuickQuizLabel{#1}
>> +	\addtocounter{quickquizctrP}{-#2}
>> +}
>>  \newcommand{\QuickQuizRef}[1]{%
>>  	\hyperref[QQ.#1]{Quick Quiz~#1}%
>>  }
>> @@ -176,6 +186,12 @@
>>  \newcommand{\QuickQuizLabel}[1]{
>>  	\edef#1{\thechapter.\thequickquizctr}
>>  }
>> +\newcommand{\QuickQuizLabelRel}[2]{
>> +        \addtocounter{quickquizctr}{#2}
>> +	\QuickQuizLabel{#1}
>> +	\addtocounter{quickquizctr}{-#2}
>> +}
>> +
>>  \newcommand{\QuickQuizRef}[1]{%
>>  	\hyperref[QQ.#1]{Quick Quiz~#1}%
>>  }
>>
>> base-commit: 14440e232cc1b2580dc1a73f873dc29fe3aea02b
>> -- 
>> 2.25.1
>>
>>

Re: [PATCH -perfbook v2] cpu: Add a QQz on table E.1

[Paul E. McKenney]

On Mon, Feb 13, 2023 at 10:54:09AM +0900, Akira Yokosawa wrote:
> On Sun, 12 Feb 2023 16:28:56 -0800, Paul E. McKenney wrote:
> > On Sun, Feb 12, 2023 at 09:42:07AM +0900, Akira Yokosawa wrote:
> >> An email thread started from a question from Leo [1] stimulated
> >> me to add a QQz on Paul's experience back in 2009.
> >>
> >> As \QuickQuizLabel{} inside \QuickQuizSeries{} doesn't work in
> >> -nq builds, define \QuickQuizLabelRel{}{} and put it in front
> >> of the series.
> >>
> >> Link: [1] https://www.spinics.net/lists/perfbook/msg03824.html
> >> Signed-off-by: Akira Yokosawa <akiygmail.com>
> >> Cc: Leonardo Brás <leobras.c@gmail.com>
> > 
> > Queued and pushed, thank you!
> 
> Paul, can you revert c82369bef3f6 ("cpu: Add a QQz citing table E.1")?
> 
> Patch v2 happens to have no conflict with v1 and you have applied
> both of them!
> 
> Now we have the same Quizzes of QQz 3.8 and QQz 3.10.
> 
> c82369bef3f6 can be reverted cleanly.

Apologies for my confusion!  I have revered c82369bef3f6 as you
suggested.

							Thanx, Paul

>         Thanks, Akira
> 
> > 
> > 							Thanx, Paul
> > 
> >> ---
> >> v2: Place new QQz next to QQz 3.7
> >>
> >> --
> >>  cpu/overheads.tex | 28 +++++++++++++++++++++++-----
> >>  qqz.sty           | 16 ++++++++++++++++
> >>  2 files changed, 39 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/cpu/overheads.tex b/cpu/overheads.tex
> >> index 0d8270bf6e17..a89c71158bf9 100644
> >> --- a/cpu/overheads.tex
> >> +++ b/cpu/overheads.tex
> >> @@ -290,12 +290,15 @@ nanoseconds, or more than seven hundred clock cycles.
> >>  A CAS operation consumes almost a full microsecond, or almost two
> >>  thousand clock cycles.
> >>  
> >> -\QuickQuiz{
> >> +\QuickQuizLabelRel{\QspeedOfLightAtoms}{1} % cann't put label inside QQSeries
> >> +
> >> +\QuickQuizSeries{%
> >> +\QuickQuizB{
> >>  	Surely the hardware designers could be persuaded to improve
> >>  	this situation!
> >>  	Why have they been content with such abysmal performance
> >>  	for these single-instruction operations?
> >> -}\QuickQuizAnswer{
> >> +}\QuickQuizAnswerB{
> >>  	The hardware designers \emph{have} been working on this
> >>  	problem, and have consulted with no less a luminary than
> >>  	the late physicist Stephen Hawking.
> >> @@ -423,9 +426,24 @@ thousand clock cycles.
> >>  	\Cref{sec:cpu:Hardware Free Lunch?}
> >>  	looks at what else hardware designers might be
> >>  	able to do to ease the plight of parallel programmers.
> >> -}\QuickQuizEnd
> >> -
> >> -\QuickQuizLabel{\QspeedOfLightAtoms}
> >> +}\QuickQuizEndB
> >> +%
> >> +\QuickQuizE{
> >> +	\Cref{tab:cpu:Performance of Synchronization Mechanisms on 16-CPU 2.8GHz Intel X5550 (Nehalem) System}
> >> +	in the answer to \QuickQuizARef{\QspeedOfLightAtoms} says that
> >> +	In-Core CAS is faster than both of Same-CPU CAS and In-Core Blind CAS\@.
> >> +	What is happening there?
> >> +}\QuickQuizAnswerE{
> >> +	I \emph{was} surprised by the data I obtained and did a rigorous
> >> +	check of their validity.
> >> +	I got the same result persistently.
> >> +	One theory that might explain the observation would be:
> >> +	The two threads in the core are able to overlap their accesses,
> >> +	while the single CPU must do everything sequentially.
> >> +	Unfortunately, there seems to be no public documentation explaining
> >> +	why the Intel X5550 (Nehalem) system behaved like that.
> >> +}\QuickQuizEndE
> >> +}                 % End of \QuickQuizSeries
> >>  
> >>  \begin{table}
> >>  \rowcolors{1}{}{lightgray}
> >> diff --git a/qqz.sty b/qqz.sty
> >> index a3a9f22d1ba9..5c7eb5340194 100644
> >> --- a/qqz.sty
> >> +++ b/qqz.sty
> >> @@ -156,6 +156,11 @@
> >>  
> >>  % To create a macro referencing the previously defined quick quiz:
> >>  %	\QuickQuizLabel{\QQname}
> >> +%
> >> +% When labeling a QQz inside \QuickQuizSeries{}, use
> >> +%	\QuickQuizLabelRel{\QQname}{rel}
> >> +% in front of the series.
> >> +%
> >>  % To reference the macro in the text:
> >>  %	\QuickQuizRef{\QQname}
> >>  % To reference the answer of the macro in the text:
> >> @@ -166,6 +171,11 @@
> >>  \newcommand{\QuickQuizLabel}[1]{
> >>  	\edef#1{\thechapter.\thequickquizctrP}
> >>  }
> >> +\newcommand{\QuickQuizLabelRel}[2]{
> >> +        \addtocounter{quickquizctrP}{#2}
> >> +	\QuickQuizLabel{#1}
> >> +	\addtocounter{quickquizctrP}{-#2}
> >> +}
> >>  \newcommand{\QuickQuizRef}[1]{%
> >>  	\hyperref[QQ.#1]{Quick Quiz~#1}%
> >>  }
> >> @@ -176,6 +186,12 @@
> >>  \newcommand{\QuickQuizLabel}[1]{
> >>  	\edef#1{\thechapter.\thequickquizctr}
> >>  }
> >> +\newcommand{\QuickQuizLabelRel}[2]{
> >> +        \addtocounter{quickquizctr}{#2}
> >> +	\QuickQuizLabel{#1}
> >> +	\addtocounter{quickquizctr}{-#2}
> >> +}
> >> +
> >>  \newcommand{\QuickQuizRef}[1]{%
> >>  	\hyperref[QQ.#1]{Quick Quiz~#1}%
> >>  }
> >>
> >> base-commit: 14440e232cc1b2580dc1a73f873dc29fe3aea02b
> >> -- 
> >> 2.25.1
> >>
> >>