<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 20, 2015 at 6:58 AM, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A thing that explains a great deal of these anomalies, but not all of it, has<br>
something to do with function addresses. There are hypotheses that it might<br>
have to do with the branch predictor and its cache. We made a test targeting<br>
exactly that idea: pick a fast path function that seems to be most susceptible<br>
to unexpected changes, pad it with x nops before the function start and N-x<br>
nops after the function end. We never execute those nops, but changing x<br>
changes the function start address while keeping everything else in the whole<br>
binary in the same place.<br>
<br>
The results were mind-boggling: depending on the function starting address, the<br>
src_8888_8888 L1 test of lowlevel-blt-bench went either 355 Mpx/s or 470 Mpx/s.<br>
There does not seem to be any predictable pattern on which addresses are "fast"<br>
and which are "slow". Obviously this will screw up our benchmarks, because a<br>
change in an unrelated function may cause another function's address to shift,<br>
and therefore change its performance. See [1] for the plot.<br>
<br>
[1] The plot of alignment vs. performance<br>
<a href="https://git.collabora.com/cgit/user/pq/pixman-benchmarking.git/plain/octave/figures/fig-src-8888-8888-L1.pdf" rel="noreferrer" target="_blank">https://git.collabora.com/cgit/user/pq/pixman-benchmarking.git/plain/octave/figures/fig-src-8888-8888-L1.pdf</a><br></blockquote><div><br></div><div>Could this be whether some "bad" instruction ends up next to or split by a cache line boundary? That would produce a random-looking plot, though it really is a plot of the location of the bad instructions in the measured function.<br><br></div><div>If this really is a problem then the ideal fix is for the compiler to insert NOP instructions in order to move the bad instructions away from the locations that make them bad. Yike.<br><br></div></div></div></div>