[lld] r240759 - COFF: Update README with the latest performance numbers.
Rui Ueyama
ruiu at google.com
Thu Jun 25 21:26:02 PDT 2015
Author: ruiu
Date: Thu Jun 25 23:26:02 2015
New Revision: 240759
URL: http://llvm.org/viewvc/llvm-project?rev=240759&view=rev
Log:
COFF: Update README with the latest performance numbers.
Modified:
lld/trunk/COFF/README.md
Modified: lld/trunk/COFF/README.md
URL: http://llvm.org/viewvc/llvm-project/lld/trunk/COFF/README.md?rev=240759&r1=240758&r2=240759&view=diff
==============================================================================
--- lld/trunk/COFF/README.md (original)
+++ lld/trunk/COFF/README.md Thu Jun 25 23:26:02 2015
@@ -12,6 +12,9 @@ Our plan is to implement a linker for th
different idea, and then apply the same idea to the ELF if proved to
be effective.
+Currently it's able to link everything in LLVM/CLang/LLD on the
+Windows platform.
+
Overall Design
--------------
@@ -112,15 +115,19 @@ There are mainly three actors in this li
Performance
-----------
-Currently it's able to self-host on the Windows platform. It takes 1.2
-seconds to self-host on my Xeon 2580 machine, while the existing
-Atom-based linker takes 5 seconds to self-host. We believe the
-performance difference comes from simplification and optimizations we
-made to the new port. Notable differences are listed below.
+It's generally 2x faster than MSVC link.exe. It takes 3.5 seconds to
+self-host on my Xeon 2580 machine. MSVC linker takes 7.0 seconds to
+link the same executable. The resulting output is 65MB.
+The old LLD is buggy that it produces 120MB executable for some reason,
+and it takes 30 seconds to do that.
+
+We believe the performance difference comes from simplification and
+optimizations we made to the new port. Notable differences are listed
+below.
* Reduced number of relocation table reads
- In the existing design, relocation tables are read from beginning to
+ In the old design, relocation tables are read from beginning to
construct graphs because they consist of graph edges. In the new
design, they are not read until we actually apply relocations.
@@ -129,7 +136,7 @@ made to the new port. Notable difference
tables directly. The other is that it reduces number of relocation
entries we have to read, because we won't read relocations for
dead-stripped COMDAT sections. Large C++ programs tend to consist of
- lots of COMDAT sections. In the existing design, the time to process
+ lots of COMDAT sections. In the old design, the time to process
relocation table is linear to size of input. In this new model, it's
linear to size of output.
@@ -241,3 +248,20 @@ Glossary
by shifting entire images in memory by some offsets. Although doing
this breaks text sharing, I think this mechanism is not actually bad
on today's computers.
+
+* ICF
+
+ Short for Identical COMDAT Folding.
+
+ ICF is an optimization to reduce output size by merging COMDAT sections
+ by not only their names but by their contents. If two COMDAT sections
+ happen to have the same metadata, actual contents and relocations,
+ they are merged by ICF. It is known as an effective technique,
+ and it usually reduces C++ program's size by a few percent or more.
+
+ Note that this is not entirely sound optimization. C/C++ require
+ different functions have different addresses. If a program depends on
+ that property, it would fail at runtime. However, that's not really an
+ issue on Windows because MSVC link.exe enabled the optimization by
+ default. As long as your program works with the linker's default
+ settings, your program should be safe with ICF.
More information about the llvm-commits
mailing list