<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On 19 May 2017, at 23:59, Rafael Avila de Espindola <<a href="mailto:rafael.espindola@gmail.com" class="">rafael.espindola@gmail.com</a>> wrote:</div>
<div class=""><br class="">
<blockquote type="cite" class="">================<br class="">
Comment at: docs/Benchmarking.rst:25<br class="">
+ mount -t tmpfs -o size=<XX>g none dir_to_mount<br class="">
+<br class="">
+Linux<br class="">
----------------<br class="">
At <a href="http://lnt.llvm.org/quickstart.html#running-tests" class="">http://lnt.llvm.org/quickstart.html#running-tests</a>, there are a few hints under number 3 on how to reduce noise and cope with the remaining noise better when you use LNT for benchmarking.
Would it be useful to have a pointer here to there?<br class="">
Maybe some of the hints there might also make sense to have here?<br class="">
Or maybe some of them should just be moved here, and there can be a pointer from there to here?<br class="">
</blockquote>
<br class="">
Some are lnt specific. I think that document should refer to this one<br class="">
for non lnt specific issues.<br class="">
</div>
</blockquote>
<div><br class="">
</div>
<div>Makes sense to me.</div>
<div><br class="">
</div>
<div>The non-lnt-specific issues that are mentioned there that I think aren't mentioned here are:</div>
<ul class="simple" style="font-family: sans-serif; orphans: 2; text-align: justify; widows: 2; background-color: rgb(255, 255, 255);">
<li style="text-align: justify; line-height: 20.8px;" class=""><i class="">When running under linux: Make lnt use linux perf to get more accurate timing for short-running benchmarks (<code class="literal docutils" style="background-color: rgb(236, 240, 243); padding: 0px 1px;"><span class="pre">--use-perf=1</span></code>)</i><br class="">
Making this LNT-independent: make sure you use a high resolution timer, e.g. linux perf under linux.</li></ul>
<ul class="simple" style="font-family: sans-serif; orphans: 2; text-align: justify; widows: 2; background-color: rgb(255, 255, 255);">
<li style="text-align: justify; line-height: 20.8px;" class=""><i class="">Make sure each program gets run multiple times, so that LNT has a higher chance of recognizing which programs are inherently noisy (<code class="literal docutils" style="background-color: rgb(236, 240, 243); padding: 0px 1px;"><span class="pre">--multisample=5</span></code>)<br class="">
</i>Making this LNT-independent: Make sure to run the benchmark multiple times to be able to recognize noise. This may be pretty obvious, but it may be worth spelling it out in the introduction?<br class="">
<br class="">
</li><li style="text-align: justify; line-height: 20.8px;" class=""><i class="">Disable frequency scaling / turbo boost. In case of thermal throttling it can skew the results.</i><br class="">
You mention this already in the linux-specific part, but maybe it's worthwhile to state this in a OS-independent way in the "general" section?<br class="">
<br class="">
</li><li style="text-align: justify; line-height: 20.8px;" class=""><i class="">Disable as many processes or services as possible on the target system.</i><br class="">
I don't think this is explicitly suggested yet in the document?</li></ul>
<br class="">
<blockquote type="cite" class="">
<div class=""><br class="">
<blockquote type="cite" class="">================<br class="">
Comment at: docs/Benchmarking.rst:29-31<br class="">
+* Disable address space randomization::<br class="">
+<br class="">
+ echo 0 > /proc/sys/kernel/randomize_va_space<br class="">
----------------<br class="">
Results will be less noisy with address space randomization turned off, but I continue to think that incorrectly skews experiment results.<br class="">
If you recommend this, maybe you also need to recommend to align all functions to a reasonably large offset so that small code changes in one function have less of a probability of affecting code layout and the associated performance impact in another function?<br class="">
</blockquote>
<br class="">
Any time we reduce noise, it is possible that we start measuring<br class="">
something we are not accounting for.<br class="">
<br class="">
I think the correct way to avoid this is to introduce variance, but in a<br class="">
reproducible way. For example, having a linker option to randomize the<br class="">
section layout given a seed would help to find if a patch improves<br class="">
performance in most layouts. That would be a generalization of<br class="">
reordering .o files suggested in<br class="">
<a href="https://www.cis.upenn.edu/~cis501/papers/producing-wrong-data.pdf" class="">https://www.cis.upenn.edu/~cis501/papers/producing-wrong-data.pdf</a>.<br class="">
<br class="">
In any case, for this patch I would like to stay focused on lowering<br class="">
the noise.<br class="">
</div>
</blockquote>
<div><br class="">
</div>
<div>OK, it makes sense to me to keep this focussed on lowering noise. I still think it'd be worthwhile in the introduction to have 1 or 2 sentences explaining this and e.g. refer to that Mytkowicz paper, so that hopefully the number of times people come to
the wrong conclusion on their compiler patch due to measurement bias is reduced. Just to make sure more people understand that even though they have low noise levels, their measurements may still not allow them to come to definite conclusions.</div>
<div><br class="">
</div>
<div>Thanks,</div>
<div><br class="">
</div>
<div>Kristof</div>
<div><br class="">
</div>
</div>
<br class="">
</body>
</html>