Typos in perfbook section 5.6 and table 9.7

Typos in perfbook section 5.6 and table 9.7

[Motohiro Kanda]

Hi,

I enjoy the book so much and am making a Japanese translation here.
https://sites.google.com/site/kandamotohiro/perfbook

I think I have found 2 typos in perfbook. Latest git repo also has these bugs.

5.6 Parallel Counting Discussion
on page 82, in file count.tex says,

"The per-thread
variable implementation (count_stat.c) is significantly faster on updates than
the array-based implementation (count_end.c), but is slower at reads"

But it should read

per-thread variable implementation(count_end.c)
and
array-based implementation (count_stat.c)

And according to table 5.1,
array-based implementation has 408 ns vs.
per-thread variable implementation has 389 ns.

so, per-thread variable implementation is a little faster, not slower
at 1 core read.



Table 9.7  Which Deferred Technique to Choose?
on page 228 in file whichtochoose.tex says,

Sequence Locks has "Y" on Updates and Readers Progress Concurrently

But it should be N because on page 229, it says

sequence locking does not permit updates and readers to make forward
progress concurrently

--
Kanda Motohiro

Re: Typos in perfbook section 5.6 and table 9.7

[Paul E. McKenney]

On Thu, Oct 09, 2014 at 10:47:56PM +0900, Motohiro Kanda wrote:
> Hi,
> 
> I enjoy the book so much and am making a Japanese translation here.
> https://sites.google.com/site/kandamotohiro/perfbook

Very good!  I have added this translation to the FAQ.

> I think I have found 2 typos in perfbook. Latest git repo also has these bugs.
> 
> 5.6 Parallel Counting Discussion
> on page 82, in file count.tex says,
> 
> "The per-thread
> variable implementation (count_stat.c) is significantly faster on updates than
> the array-based implementation (count_end.c), but is slower at reads"
> 
> But it should read
> 
> per-thread variable implementation(count_end.c)
> and
> array-based implementation (count_stat.c)
> 
> And according to table 5.1,
> array-based implementation has 408 ns vs.
> per-thread variable implementation has 389 ns.
> 
> so, per-thread variable implementation is a little faster, not slower
> at 1 core read.

Good catch!  This sentence now reads as follows:

	The per-thread-variable implementation (count_end.c)
	is significantly faster on updates than the array-based
	implementation (count_stat.c), but is slower at reads on large
	numbers of cores, and suffers severe lock contention when there
	are many parallel readers.

> Table 9.7  Which Deferred Technique to Choose?
> on page 228 in file whichtochoose.tex says,
> 
> Sequence Locks has "Y" on Updates and Readers Progress Concurrently
> 
> But it should be N because on page 229, it says
> 
> sequence locking does not permit updates and readers to make forward
> progress concurrently

And reference counting, hazard pointers, and RCU should all say "Y".

I have made these changes with your Reported-by.

							Thanx, Paul

> --
> Kanda Motohiro
> --
> To unsubscribe from this list: send the line "unsubscribe perfbook" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>