Question on updated Figure 5.1 "Atomic Increment Scalability on Kaby Lake"

[Akira Yokosawa <akiyks@gmail.com>]

Hello Palik,

I'm looking at Figure 5.1 of perfbook which was updated by commit
3b62f67a76e1 ("Regenerating the atomic counter graph on a more
modern CPU"), and wondering the time to increment at x = 1 looks
too small.

As is described in the Answer to Quick Quiz 5.8, atomic increment
should take a bit longer than the ideal non-atomic increment even
when the number of updaters is 1.

Or on Kaby Lake, some special optimization results in almost no
cost in this case? If that is the case, the Quick Quiz needs update...

Also, the horizontal dashed line should be closer to the x-axis,
I suppose. The time of the ideal non-atomic increment is embedded on
line 44 of CodeSamples/count/plots.sh as "8.81772".
You might need to use a proper value for Kaby Lake (should be near
zero) instead.

If I understand the circumstances right, raw data for the previous
version of the graph reside in
CodeSamples/count/data/count_atomic:u.2009.05.03a.dat.

Can you share the corresponding raw data on Kaby Lake?

Also, in the above mentioned commit, atomic125.{eps|png} were
overwritten accidentally. They were graphs of 125-thread case,
and should not have been updated IMO. They are not used in perfbook
at the moment, but I'd like to have the original ones in the repository.

If you could share the raw data for Kaby Lake, I'd be happy to fix
these issues for you. 

I'm not blaming any of you. I could blame the ad-hoc design of plots.sh,
but it was written by Paul for his own use. Such scripts tend to be
ad-hoc. ;-)  I might be able to improve the script.

        Thanks, Akira