[lld] r312796 - Currently lld creates a single section to collect all commons. There is no way

Shoaib Meenai via llvm-commits llvm-commits at lists.llvm.org
Wed Sep 13 10:11:31 PDT 2017


I can try to get some more measurements. How is LLD performance generally evaluated? Do you use any particular profiling tools? (I'm running my link on Linux.)

From: Rui Ueyama <ruiu at google.com>
Date: Tuesday, September 12, 2017 at 5:39 PM
To: Shoaib Meenai <smeenai at fb.com>
Cc: Rafael Avila de Espindola <rafael.espindola at gmail.com>, Dmitry Mikulin <dmitry.mikulin at sony.com>, "llvm-commits at lists.llvm.org" <llvm-commits at lists.llvm.org>
Subject: Re: [lld] r312796 - Currently lld creates a single section to collect all commons. There is no way

Yeah, benchmark is tricky. If your CPU is cold at beginning, the first few runs could be faster than the following runs of the same program because of Intel Turbo Boost, for example.

If there's still 2% difference, I'd like to know if it's caused by this patch. I didn't expect that this patch would slow down the linker by a few percent. I believe this patch is negligible in terms of linker performance, unless your program is using tons of common symbols.

On Tue, Sep 12, 2017 at 5:30 PM, Shoaib Meenai <smeenai at fb.com<mailto:smeenai at fb.com>> wrote:
I can't reproduce the slowdown anymore :( I'm measuring by running the link in
question 16 times with `time` and taking the average of the total time
reported. Yesterday, I was consistently seeing the 20% slowdown I mentioned.
Today that difference has dropped to 2%. Perhaps my runs yesterday got unlucky
with CPU load from other processes or something similar.

Sorry for the false alarm. I'll still try to switch my library to using
-fno-common though, just for general cleanliness. Thanks for all the replies!

On 9/12/17, 2:51 PM, "Rafael Avila de Espindola" <rafael.espindola at gmail.com<mailto:rafael.espindola at gmail.com>> wrote:

    Shoaib Meenai <smeenai at fb.com<mailto:smeenai at fb.com>> writes:

    > It's written in C, and it has 325 common symbols.
    >
    > I only read up on common symbols today, so please correct me if my
    > understanding is off. From what I've read, you'll end up with a common symbol
    > in your object file if you have an uninitialized non-static global variable,
    > e.g. (in the global scope):
    >
    > int x;
    >
    > If you mark the variable static, or if you explicitly zero-initialize it,
    > it'll end up in bss instead of COMMON. You can also use -fno-common to force
    > the use of bss, and C++ does so by default.
    >
    > I understand that COMMON symbols were originally devised to deal with people
    > writing `int x` instead of `extern int x` in headers. My library doesn't have
    > that problem; the `int x` form is used only in source files, and the intent is
    > to define a variable and have it be automatically zero-initialized. I was
    > hoping that if a variable was preceded by an extern declaration, e.g.
    >
    > extern int x;
    > ...
    > int x;
    >
    > the compiler would place it in bss instead of COMMON, but that doesn't appear
    > to be the case.
    >
    > I'll try compiling my sources with -fno-common. This definitely seems like
    > something a lot of libraries could run into though, since it looks like all
    > you need to trigger it is an uninitialized global variable.

    Your understanding is correct. As Rui points out, allocating 325
    sections cannot be directly slowing down lld so much.

    My first guess would be that by making DefinedCommon larger the patch
    could have increased the size of Symbol, but that was not the case since
    SharedSymbol was still bigger.

    How stable is the benchmark across lld versions? What time do you get
    with top of tree?

    Cheers,
    Rafael


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170913/181179f2/attachment.html>


More information about the llvm-commits mailing list