[lld] r287946 - Parallelize uncompress() and splitIntoPieces().
David Blaikie via llvm-commits
llvm-commits at lists.llvm.org
Mon Nov 28 11:52:53 PST 2016
You mean why are some debug sections compressed and not others? LLVM
compresses any where the compressed size is smaller than the uncompressed
size (ie: we don't compress really small sections where the overhead is
gerater than the benefit)
Or if you mean: why do we compress debug sections but not non-debug
sections? Probably because people who cared about debug info implemented it
& no one looked at the overall benefit. And also probably the benefit to
compress the (very large) debug sections was worth the compute overhead of
compressing/decompressing.
So if we were to take a more holistic approach we might find that
compressing particularly 'large' sections is what's important - regardless
of whether they're debug or non-debug sections.
On Mon, Nov 28, 2016 at 11:35 AM Rui Ueyama <ruiu at google.com> wrote:
> This may be a silly question, but why do we compress some sections and
> don't compress other sections? What is the criteria?
>
> On Mon, Nov 28, 2016 at 9:45 AM, David Blaikie <dblaikie at gmail.com> wrote:
>
>
>
> On Mon, Nov 28, 2016 at 9:26 AM Rui Ueyama <ruiu at google.com> wrote:
>
> On Mon, Nov 28, 2016 at 9:21 AM, David Blaikie <dblaikie at gmail.com> wrote:
>
> tangentially related to compressed sections: Currently, I take it, lld
> decompresses all compressed input sections into memory before producing
> output, yes? Is there any chance in the future that lld might use a more
> streaming approach to reduce memory overhead? (ie: defer decompressing
> until output - and decompress/write out (possibly recompressing) in chunks,
> rather than necessary whole sections or all sections)
>
>
> Interesting idea. LLD currently decompresses all live (non-gc'ed) sections
> in memory because it may contain mergeable strings or (theoretically) EH
> frames that need to be handled specially. But for regular sections, we
> could use a streaming approach indeed. It doesn't only save memory but also
> improves performance because it eliminates one extra memory copy (we can
> write uncompressed data directly to the output buffer).
>
>
> Yep - even for strings, you could read/process the strings into the
> stringmap in chunks, rather than reading the whole buffer in, then
> inserting them all. (also improves memory locality - so you don't read it
> all in, then go back and start cache missing on the beginning of the buffer
> to process them)
>
> It comes to mind because of the memory optimizations I've been
> doing/looking at in the DWP tool.
>
>
>
>
> On Fri, Nov 25, 2016 at 12:15 PM Rui Ueyama via llvm-commits <
> llvm-commits at lists.llvm.org> wrote:
>
> Author: ruiu
> Date: Fri Nov 25 14:05:08 2016
> New Revision: 287946
>
> URL: http://llvm.org/viewvc/llvm-project?rev=287946&view=rev
> Log:
> Parallelize uncompress() and splitIntoPieces().
>
> Uncompressing section contents and spliting mergeable section contents
> into smaller chunks are heavy tasks. They scan entire section contents
> and do CPU-intensive tasks such as uncompressing zlib-compressed data
> or computing a hash value for each section piece.
>
> Luckily, these tasks are independent to each other, so we can do that
> in parallel_for_each. The number of input sections is large (as opposed
> to the number of output sections), so there's a large parallelism here.
>
> Actually the current design to call uncompress() and splitIntoPieces()
> in batch was chosen with doing this in mind. Basically what we need to
> do here is to replace `for` with `parallel_for_each`.
>
> It seems this patch improves latency significantly if linked programs
> contain debug info (which in turn contain lots of mergeable strings.)
> For example, the latency to link Clang (debug build) improved by 20% on
> my machine as shown below. Note that ld.gold took 19.2 seconds to do
> the same thing.
>
> Before:
> 30801.782712 task-clock (msec) # 3.652 CPUs utilized
> ( +- 2.59% )
> 104,084 context-switches # 0.003 M/sec
> ( +- 1.02% )
> 5,063 cpu-migrations # 0.164 K/sec
> ( +- 13.66% )
> 2,528,130 page-faults # 0.082 M/sec
> ( +- 0.47% )
> 85,317,809,130 cycles # 2.770 GHz
> ( +- 2.62% )
> 67,352,463,373 stalled-cycles-frontend # 78.94% frontend cycles
> idle ( +- 3.06% )
> <not supported> stalled-cycles-backend
> 44,295,945,493 instructions # 0.52 insns per cycle
> # 1.52 stalled cycles per
> insn ( +- 0.44% )
> 8,572,384,877 branches # 278.308 M/sec
> ( +- 0.66% )
> 141,806,726 branch-misses # 1.65% of all branches
> ( +- 0.13% )
>
> 8.433424003 seconds time elapsed
> ( +- 1.20% )
>
> After:
> 35523.764575 task-clock (msec) # 5.265 CPUs utilized
> ( +- 2.67% )
> 159,107 context-switches # 0.004 M/sec
> ( +- 0.48% )
> 8,123 cpu-migrations # 0.229 K/sec
> ( +- 23.34% )
> 2,372,483 page-faults # 0.067 M/sec
> ( +- 0.36% )
> 98,395,342,152 cycles # 2.770 GHz
> ( +- 2.62% )
> 79,294,670,125 stalled-cycles-frontend # 80.59% frontend cycles
> idle ( +- 3.03% )
> <not supported> stalled-cycles-backend
> 46,274,151,813 instructions # 0.47 insns per cycle
> # 1.71 stalled cycles per
> insn ( +- 0.47% )
> 8,987,621,670 branches # 253.003 M/sec
> ( +- 0.60% )
> 148,900,624 branch-misses # 1.66% of all branches
> ( +- 0.27% )
>
> 6.747548004 seconds time elapsed
> ( +- 0.40% )
>
> Modified:
> lld/trunk/ELF/Driver.cpp
> lld/trunk/ELF/InputSection.cpp
>
> Modified: lld/trunk/ELF/Driver.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/lld/trunk/ELF/Driver.cpp?rev=287946&r1=287945&r2=287946&view=diff
>
> ==============================================================================
> --- lld/trunk/ELF/Driver.cpp (original)
> +++ lld/trunk/ELF/Driver.cpp Fri Nov 25 14:05:08 2016
> @@ -20,6 +20,7 @@
> #include "Target.h"
> #include "Writer.h"
> #include "lld/Config/Version.h"
> +#include "lld/Core/Parallel.h"
> #include "lld/Driver/Driver.h"
> #include "llvm/ADT/StringExtras.h"
> #include "llvm/ADT/StringSwitch.h"
> @@ -800,14 +801,15 @@ template <class ELFT> void LinkerDriver:
>
> // MergeInputSection::splitIntoPieces needs to be called before
> // any call of MergeInputSection::getOffset. Do that.
> - for (InputSectionBase<ELFT> *S : Symtab.Sections) {
> - if (!S->Live)
> - continue;
> - if (S->Compressed)
> - S->uncompress();
> - if (auto *MS = dyn_cast<MergeInputSection<ELFT>>(S))
> - MS->splitIntoPieces();
> - }
> + parallel_for_each(Symtab.Sections.begin(), Symtab.Sections.end(),
> + [](InputSectionBase<ELFT> *S) {
> + if (!S->Live)
> + return;
> + if (S->Compressed)
> + S->uncompress();
> + if (auto *MS = dyn_cast<MergeInputSection<ELFT>>(S))
> + MS->splitIntoPieces();
> + });
>
> // Write the result to the file.
> writeResult<ELFT>();
>
> Modified: lld/trunk/ELF/InputSection.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/lld/trunk/ELF/InputSection.cpp?rev=287946&r1=287945&r2=287946&view=diff
>
> ==============================================================================
> --- lld/trunk/ELF/InputSection.cpp (original)
> +++ lld/trunk/ELF/InputSection.cpp Fri Nov 25 14:05:08 2016
> @@ -22,6 +22,7 @@
>
> #include "llvm/Support/Compression.h"
> #include "llvm/Support/Endian.h"
> +#include <mutex>
>
> using namespace llvm;
> using namespace llvm::ELF;
> @@ -160,6 +161,8 @@ InputSectionBase<ELFT>::getRawCompressed
> return {Data.slice(sizeof(*Hdr)), read64be(Hdr->Size)};
> }
>
> +// Uncompress section contents. Note that this function is called
> +// from parallel_for_each, so it must be thread-safe.
> template <class ELFT> void InputSectionBase<ELFT>::uncompress() {
> if (!zlib::isAvailable())
> fatal(toString(this) +
> @@ -179,7 +182,12 @@ template <class ELFT> void InputSectionB
> std::tie(Buf, Size) = getRawCompressedData(Data);
>
> // Uncompress Buf.
> - char *OutputBuf = BAlloc.Allocate<char>(Size);
> + char *OutputBuf;
> + {
> + static std::mutex Mu;
> + std::lock_guard<std::mutex> Lock(Mu);
> + OutputBuf = BAlloc.Allocate<char>(Size);
> + }
> if (zlib::uncompress(toStringRef(Buf), OutputBuf, Size) !=
> zlib::StatusOK)
> fatal(toString(this) + ": error while uncompressing section");
> Data = ArrayRef<uint8_t>((uint8_t *)OutputBuf, Size);
> @@ -746,6 +754,12 @@ MergeInputSection<ELFT>::MergeInputSecti
> StringRef Name)
> : InputSectionBase<ELFT>(F, Header, Name,
> InputSectionBase<ELFT>::Merge) {}
>
> +// This function is called after we obtain a complete list of input
> sections
> +// that need to be linked. This is responsible to split section contents
> +// into small chunks for further processing.
> +//
> +// Note that this function is called from parallel_for_each. This must be
> +// thread-safe (i.e. no memory allocation from the pools).
> template <class ELFT> void MergeInputSection<ELFT>::splitIntoPieces() {
> ArrayRef<uint8_t> Data = this->Data;
> uintX_t EntSize = this->Entsize;
>
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20161128/b77b791e/attachment.html>
More information about the llvm-commits
mailing list