llvm dev - Mar 2016 - LLD performance w.r.t. local symbols (and --build-id)

Slowdown by "[ELF] - Early continue in
InputSectionBase<ELFT>::relocate(). NFC.?" looks wierd for me. I do
not see any reasons for any impact on perfomance by this change.

Good news is that since it was NFC it can easily be reverted. But I think
slowdown in results is unrelative with that change and reverting will not give
us 2-3% boost back.


Best regards,
George.
________________________________
??: Rui Ueyama <ruiu at google.com>
??????????: 16 ????? 2016 ?. 4:24
????: Sean Silva
?????: llvm-dev; Rafael Ávila de Espíndola; Michael Spencer; Davide Italiano;
George Rimar
????: Re: LLD performance w.r.t. local symbols (and --build-id)

Some slowdown by --build-id was expected. It scans most parts of the output to
compute a hash value after all. It can easily be parallelized, but it would
still have non-negligible performance impact. I'd think it is not a good
practice for the compiler to pass --build-id option unconditionally. It seems to
me that the option was added too casually without fully understanding that the
option would slows down linking time significantly.

On Tue, Mar 15, 2016 at 6:03 PM, Sean Silva <chisophugis at
gmail.com<mailto:chisophugis at gmail.com>> wrote:
Hi,

Rafael took some measurements to try to investigate the effect of the local
symbols changes.
I've been taking a look at the measurements he got and there were some
interesting things we noticed.

For starters, in the range of revisions tested (r263214 through r263471), we
found that the commit for --build-id was the most noticeable, with slowdowns
from 7% to 23% (note: these were non-debug builds).

This is somewhat concerning because it appears that this option is passed to the
linker by default on Linux. Any performance comparisons with other linkers
before LLD started respecting --build-id must be taken with a grain of salt
unless they were controlled for --build-id.

Returning to the original motivation for the investigation (local symbols), we
see something interesting. Zooming in r263214 through r263237, we find that the
performance characteristics for linking ScyllaDB are substantially different
from the others. The reason for this is still unknown.

The following commits showed significant performance changes for ScyllaDB.

r263222  ~4% speedup for ScyllaDB
commit 1ffd121a07a3d67bf52d849c0cdef0f2fad889ba
Author: Rafael Espindola <rafael.espindola at
gmail.com<mailto:rafael.espindola at gmail.com>>
Date:   Fri Mar 11 12:06:30 2016 +0000

    Create a SymbolBody for locals.

    pr26878 shows a case where locals have to be in the got.

    git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk at 263222
91177308-0d34-0410-b5e6-96231b3b80d8

r263225 ~4% speedup for ScyllaDB
commit 34ca5194d5e5e28d760cc8a730a2e1f3b2b6a21f
Author: Rafael Espindola <rafael.espindola at
gmail.com<mailto:rafael.espindola at gmail.com>>
Date:   Fri Mar 11 12:19:05 2016 +0000

    Compute value of local symbol with getVA.

    git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk at 263225
91177308-0d34-0410-b5e6-96231b3b80d8

r263227 ~2-3% slowdown for ScyllaDB
commit 6b96b614d9e0232b106165255148af8909607ec1
Author: George Rimar <grimar at accesssoftek.com<mailto:grimar at
accesssoftek.com>>
Date:   Fri Mar 11 12:57:52 2016 +0000

    [ELF] - Early continue in InputSectionBase<ELFT>::relocate(). NFC.

    git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk at 263227
91177308-0d34-0410-b5e6-96231b3b80d8

r263228 ~6-7% slowdown for ScyllaDB
commit e5aedbede69d60d90f16395af8d4fa6171a5c46a
Author: Rafael Espindola <rafael.espindola at
gmail.com<mailto:rafael.espindola at gmail.com>>
Date:   Fri Mar 11 13:04:28 2016 +0000

    Simplify now that local symbols can use getVA.

    It is really odd that Mips differentiates symbols that are born local
    and those that become local because of hidden visibility. I don't know
    enough mips to known if this is a bug or not.

    git-svn-id: https://llvm.org/svn/llvm-project/lld/trunk at 263228
91177308-0d34-0410-b5e6-96231b3b80d8


My full notebook is here:
https://drive.google.com/file/d/0B8v10qJ6EXRxYlNTTUpiQjF5eGM/view?usp=sharing

-- Sean Silva




-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160316/201da5bd/attachment.html>

On 16 March 2016 at 01:34, George Rimar <grimar at accesssoftek.com>
wrote:
> Slowdown by "[ELF] - Early continue in
InputSectionBase<ELFT>::relocate().
> NFC." looks wierd for me. I do not see any reasons for any impact on
> perfomance by this change.

I think it is just because the continue is unlikely and now there is
an early check of offset.
> Good news is that since it was NFC it can easily be reverted. But I think
> slowdown in results is unrelative with that change and reverting will not
> give us 2-3% boost back.
I don't think we should revert it right now. There are a few big
changes I would like to try to the relocation processing code.

Cheers,
Rafael

On Wed, Mar 16, 2016 at 9:05 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:
> On 16 March 2016 at 01:34, George Rimar <grimar at accesssoftek.com>
wrote:
> > Slowdown by "[ELF] - Early continue in
> InputSectionBase<ELFT>::relocate().
> > NFC." looks wierd for me. I do not see any reasons for any impact
on
> > perfomance by this change.
>
>
> I think it is just because the continue is unlikely and now there is
> an early check of offset.
>
> > Good news is that since it was NFC it can easily be reverted. But I
think
> > slowdown in results is unrelative with that change and reverting will
not
> > give us 2-3% boost back.
>
> I don't think we should revert it right now. There are a few big
> changes I would like to try to the relocation processing code.
>
Agreed. Unless your code changes algorithm, you don't need to worry too
much about performance fluctuations caused by that change. This may vary on
compiler, compiler version, code around your change, and test cases.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160316/dba0057c/attachment.html>