<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 31, 2017 at 11:08 AM, Rafael Avila de Espindola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Right now performance tracking in lld is a manual and very laborious<br>
process.<br>
<br>
I decided to take some time off main development to automate it a<br>
bit.<br>
<br>
The current state is that we have a bunch of test in<br>
<a href="https://s3-us-west-2.amazonaws.com/linker-tests/lld-speed-test.tar.xz" rel="noreferrer" target="_blank">https://s3-us-west-2.<wbr>amazonaws.com/linker-tests/<wbr>lld-speed-test.tar.xz</a>. Each<br>
test is a program that lld can link (clang, chrome, firefox, etc).<br>
<br>
Right now there is just a hackish run.sh that links every program with<br>
two versions of lld to compare the performance. Some programs are also<br>
linked in different modes. For example, we compare chrome with and<br>
without icf.<br>
<br>
I want to improve this in two ways:<br>
<br>
* Make the directory structure uniform. What I am currently prototyping<br>
  is that each program is its own directory and it can have multiple<br>
  response*.txt files. Each response file is an independent test. The<br>
  reason for allowing multiple response files is to allow for variants:<br>
  * response.txt<br>
  * response-icf.txt<br>
  * response-gc.txt<br></blockquote><div><br></div><div>One thing I'd like to make sure is to be able to run these response files with gold. Last time I tried, I tried something like</div><div><br></div><div>  $ cp `which ld.gold` ld.gold</div><div>  $ fakechroot chroot . ./ld.gold @response.txt</div><div><br></div><div>and that worked in most cases, but it failed for a few response files and I had to fix them by hand.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Instead of just comparing lld's run time, parse and save various<br>
  metrics to a database.<br>
<br>
The database hierarchy would be:<br>
<br>
So for each llvm revision there will be multiple benchmarks (chrome,<br>
chrome-icf, clang).<br>
<br>
For each benchmark, there will be multiple metrics (lld runtime, branches,<br>
output size, etc).<br>
<br>
Some output metrics will include multiple measurements. The output size<br>
should always be the same, but we can have multiple runs with slightly<br>
different time for example.<br>
<br>
Not too surprisingly, the above structure is remarkably similar to what lnt<br>
uses:<br>
<a href="http://llvm.org/docs/lnt/importing_data.html#importing-data-in-a-text-file" rel="noreferrer" target="_blank">http://llvm.org/docs/lnt/<wbr>importing_data.html#importing-<wbr>data-in-a-text-file</a><br>
<br>
So my idea is to first write a python script that runs all the<br>
benchmarks in the above structure and submits the results to a lnt<br>
server. This would replace the existing run.sh.<br>
<br>
For comparing just two revisions locally, this will be a bit more work.<br>
<br>
But it should allow us to setup a bot that continually submits lld<br>
performance results.<br>
<br>
For those working on lld, does the above sound like a good idea?<br></blockquote><div><br></div><div>Yes, that'd be pretty helpful.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For those working on lnt, is it a good match for the above? The main use<br>
case I would like is to build graphs of various metrics over llvm<br>
revisions. For example:<br>
<br>
* chrome's output size over the last 1000 llvm revisions.<br>
* firefox link time (with error bars) over that last 1000 llvm revisions.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div>