llvm dev - Feb 2018 - New LLD performance builder

Galina Kistanova <gkistanova at gmail.com> writes:
> Hello Rafael,
>
>> It seems the produced lld binary is not being statically linked.
>
> Hm. It should. But it seems couple config params are missing. Fixed. Thanks
> for catching this!
>
>> Is lld-speed-test in a tmpfs?
>
> Correct.
> All the benchmarking tips from https://www.llvm.org/docs/Benchmarking.html
> have been applied to that bot.
>
>> Is lld-benchmark.py a copy of lld/utils/benchmark.py?
>
> Correct. Modulo few local changes for more verbose printing to be
"bot"
> friendly. Didn't decided yet if this is something we want in
> lld/utils/benchmark.py.
Interesting. Looks like the runs got faster, but they are still
clustered in three or four different groups. Looking at instructions
makes it even more visible:

http://lnt.llvm.org/db_default/v4/link/graph?highlight_run=426&plot.9=1.9.6

Is there anything else running on the machine while the tests are run?

Cheers,
Rafael

Yep. They are still clustered.
>  Is there anything else running on the machine while the tests are run?
Not much. The usual buildslave stuff - buildbot, ssh server, some light
network services, snmp client, but that's pretty much it. 20 hardware
threads are designated for this.

The test runs on designated for tests only 10 CPUs shielded.
There only perf and lld runs. All the obj files for the tests and the
linker itself are on tmpfs, so no disk I/O is involved. Swap file is
(almost) empty - few MBs is in use.

It might be that different CPUs gets used for different test runs, as the
script starts each run from the scratch. Just a guess. I will look in to
this closer.
I'll take the bot off line to see if having perf running the tests multiple
times would give a better result. And would try to reduce the number of
designated CPUs to see how that would affect the numbers as well.

Thanks

Galina


On Mon, Feb 26, 2018 at 2:17 PM, Rafael Avila de Espindola <
rafael.espindola at gmail.com> wrote:
> Galina Kistanova <gkistanova at gmail.com> writes:
>
> > Hello Rafael,
> >
> >> It seems the produced lld binary is not being statically linked.
> >
> > Hm. It should. But it seems couple config params are missing. Fixed.
> Thanks
> > for catching this!
> >
> >> Is lld-speed-test in a tmpfs?
> >
> > Correct.
> > All the benchmarking tips from https://www.llvm.org/docs/
> Benchmarking.html
> > have been applied to that bot.
> >
> >> Is lld-benchmark.py a copy of lld/utils/benchmark.py?
> >
> > Correct. Modulo few local changes for more verbose printing to be
"bot"
> > friendly. Didn't decided yet if this is something we want in
> > lld/utils/benchmark.py.
>
> Interesting. Looks like the runs got faster, but they are still
> clustered in three or four different groups. Looking at instructions
> makes it even more visible:
>
> http://lnt.llvm.org/db_default/v4/link/graph?
> highlight_run=426&plot.9=1.9.6
>
> Is there anything else running on the machine while the tests are run?
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180227/370951ee/attachment.html>

Galina Kistanova <gkistanova at gmail.com> writes:
> Yep. They are still clustered.
>
>>  Is there anything else running on the machine while the tests are run?
>
> Not much. The usual buildslave stuff - buildbot, ssh server, some light
> network services, snmp client, but that's pretty much it. 20 hardware
> threads are designated for this.
>
> The test runs on designated for tests only 10 CPUs shielded.
> There only perf and lld runs. All the obj files for the tests and the
> linker itself are on tmpfs, so no disk I/O is involved. Swap file is
> (almost) empty - few MBs is in use.
>
> It might be that different CPUs gets used for different test runs, as the
> script starts each run from the scratch. Just a guess. I will look in to
> this closer.
> I'll take the bot off line to see if having perf running the tests
multiple
> times would give a better result. And would try to reduce the number of
> designated CPUs to see how that would affect the numbers as well.
The HT siblings are disabled, right?

It is probably a good idea to experiment with disabling swap and having
a single cpu in the shield group.

Thanks,
Rafael