llvm dev - Dec 2016 - LLD status update and performance chart

Hi,

Now that 2016 is almost over, I wanted to look back and summarize the
progress we've made to LLD this year, as I guess most people who are not
looking closely at LLD don't know very well about the current status. I
think I can say that this year was a fantastic year for LLD. Now I'm pretty
sure that that is going to be a serious (and better, in my opinion)
alternative to the existing GNU linkers thanks to all the improvements
we've made this year.

LLD is now able to link most x86-64 userland programs. The FreeBSD project
and we are trying to make LLD the system default linker of the operating
system, and except a few tricky programs such as the kernel or a boot
loader, the linker works mostly fine. We are still working on implementing
long-tail features/bugs, but I'd say that's just a matter of time. LLD
supports x86, x86-64, x32, AArch64, AMDGPU, ARM, PPC64 and MIPS32/64,
though completeness varies.

Looks like there are already a few systems that are using LLD as system
linkers, such as CloudABI or Fuchsia. Chromium and Clang/LLVM itself has
build options to use LLD to build them.

It is hard to argue about the complexity of a program quantitatively, and
of course I'm biased, but I believe we succeeded to maintain LLD code base
clean, easy to read, and easy to add new features. It is just 20k lines of
modern C++ code which is much smaller than GNU linkers.

Even though LLD was fast from day one, LLD got faster this year, despite it
got a lot of new features. Below is a chart of Clang link time for every
commit made to the LLD repository this year. At the beginning of this year,
LLD took about 16 seconds to produce a 1.5 GB clang (debug build)
executable. Now, it takes about 14.5 seconds on single core and 8.5 seconds
on 20 cores (*1). ld.gold takes about 25 seconds and 20 seconds,
respectively, so we've widen the gap. You can see the benchmark results
here (*2). If you have a problem of too long link time, I'd recommend to
try LLD.

Last but not least, a lot of people joined to the LLD development this
year to make LLD better. We are growing as a community, and I'm very happy
about that!

Thanks,
Rui

(*1) My machine has Ivy Bridge Xeon 2.8 GHz 20 physical cores (40
hyper-threading cores). To measure a single-thread performance, I pinned a
process to (physical and hyper-threading) core 0. To measure a multi-thread
performance, I pinned to CPU socket 2, so that a process gets 10 physical
cores (20 hyperthreading cores).

(*2)
https://docs.google.com/spreadsheets/d/1VvOqiU5JvqlxU7aof8gsbh-yweeNchMgtkamyXrwzrA/edit?usp=sharing.
Changes with more than 1% rise or drop compared to the average of previous
5 commits are colored in green or red, respectively.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161211/ebddf680/attachment.html>

Looks like the image wasn't attached correctly. Here's the chart.



On Sun, Dec 11, 2016 at 7:04 PM, Rui Ueyama <ruiu at google.com> wrote:
> Hi,
>
> Now that 2016 is almost over, I wanted to look back and summarize the
> progress we've made to LLD this year, as I guess most people who are
not
> looking closely at LLD don't know very well about the current status. I
> think I can say that this year was a fantastic year for LLD. Now I'm
pretty
> sure that that is going to be a serious (and better, in my opinion)
> alternative to the existing GNU linkers thanks to all the improvements
> we've made this year.
>
> LLD is now able to link most x86-64 userland programs. The FreeBSD project
> and we are trying to make LLD the system default linker of the operating
> system, and except a few tricky programs such as the kernel or a boot
> loader, the linker works mostly fine. We are still working on implementing
> long-tail features/bugs, but I'd say that's just a matter of time.
LLD
> supports x86, x86-64, x32, AArch64, AMDGPU, ARM, PPC64 and MIPS32/64,
> though completeness varies.
>
> Looks like there are already a few systems that are using LLD as system
> linkers, such as CloudABI or Fuchsia. Chromium and Clang/LLVM itself has
> build options to use LLD to build them.
>
> It is hard to argue about the complexity of a program quantitatively, and
> of course I'm biased, but I believe we succeeded to maintain LLD code
base
> clean, easy to read, and easy to add new features. It is just 20k lines of
> modern C++ code which is much smaller than GNU linkers.
>
> Even though LLD was fast from day one, LLD got faster this year, despite
> it got a lot of new features. Below is a chart of Clang link time for every
> commit made to the LLD repository this year. At the beginning of this year,
> LLD took about 16 seconds to produce a 1.5 GB clang (debug build)
> executable. Now, it takes about 14.5 seconds on single core and 8.5 seconds
> on 20 cores (*1). ld.gold takes about 25 seconds and 20 seconds,
> respectively, so we've widen the gap. You can see the benchmark results
> here (*2). If you have a problem of too long link time, I'd recommend
to
> try LLD.
>
> Last but not least, a lot of people joined to the LLD development this
> year to make LLD better. We are growing as a community, and I'm very
happy
> about that!
>
> Thanks,
> Rui
>
> (*1) My machine has Ivy Bridge Xeon 2.8 GHz 20 physical cores (40
> hyper-threading cores). To measure a single-thread performance, I pinned a
> process to (physical and hyper-threading) core 0. To measure a multi-thread
> performance, I pinned to CPU socket 2, so that a process gets 10 physical
> cores (20 hyperthreading cores).
>
> (*2) https://docs.google.com/spreadsheets/d/1VvOqiU5JvqlxU7aof8gsbh-
> yweeNchMgtkamyXrwzrA/edit?usp=sharing. Changes with more than 1% rise or
> drop compared to the average of previous 5 commits are colored in green or
> red, respectively.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161211/3b7b3662/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Capture.GIF
Type: image/gif
Size: 34826 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161211/3b7b3662/attachment.gif>

Hmm, I think I made a mistake again. This is the correct chart.



On Sun, Dec 11, 2016 at 7:05 PM, Rui Ueyama <ruiu at google.com> wrote:
> Looks like the image wasn't attached correctly. Here's the chart.
>
>
>
> On Sun, Dec 11, 2016 at 7:04 PM, Rui Ueyama <ruiu at google.com>
wrote:
>
>> Hi,
>>
>> Now that 2016 is almost over, I wanted to look back and summarize the
>> progress we've made to LLD this year, as I guess most people who
are not
>> looking closely at LLD don't know very well about the current
status. I
>> think I can say that this year was a fantastic year for LLD. Now
I'm pretty
>> sure that that is going to be a serious (and better, in my opinion)
>> alternative to the existing GNU linkers thanks to all the improvements
>> we've made this year.
>>
>> LLD is now able to link most x86-64 userland programs. The FreeBSD
>> project and we are trying to make LLD the system default linker of the
>> operating system, and except a few tricky programs such as the kernel
or a
>> boot loader, the linker works mostly fine. We are still working on
>> implementing long-tail features/bugs, but I'd say that's just a
matter of
>> time. LLD supports x86, x86-64, x32, AArch64, AMDGPU, ARM, PPC64 and
>> MIPS32/64, though completeness varies.
>>
>> Looks like there are already a few systems that are using LLD as system
>> linkers, such as CloudABI or Fuchsia. Chromium and Clang/LLVM itself
has
>> build options to use LLD to build them.
>>
>> It is hard to argue about the complexity of a program quantitatively,
and
>> of course I'm biased, but I believe we succeeded to maintain LLD
code base
>> clean, easy to read, and easy to add new features. It is just 20k lines
of
>> modern C++ code which is much smaller than GNU linkers.
>>
>> Even though LLD was fast from day one, LLD got faster this year,
despite
>> it got a lot of new features. Below is a chart of Clang link time for
every
>> commit made to the LLD repository this year. At the beginning of this
year,
>> LLD took about 16 seconds to produce a 1.5 GB clang (debug build)
>> executable. Now, it takes about 14.5 seconds on single core and 8.5
seconds
>> on 20 cores (*1). ld.gold takes about 25 seconds and 20 seconds,
>> respectively, so we've widen the gap. You can see the benchmark
results
>> here (*2). If you have a problem of too long link time, I'd
recommend to
>> try LLD.
>>
>> Last but not least, a lot of people joined to the LLD development this
>> year to make LLD better. We are growing as a community, and I'm
very happy
>> about that!
>>
>> Thanks,
>> Rui
>>
>> (*1) My machine has Ivy Bridge Xeon 2.8 GHz 20 physical cores (40
>> hyper-threading cores). To measure a single-thread performance, I
pinned a
>> process to (physical and hyper-threading) core 0. To measure a
multi-thread
>> performance, I pinned to CPU socket 2, so that a process gets 10
physical
>> cores (20 hyperthreading cores).
>>
>> (*2) https://docs.google.com/spreadsheets/d/1VvOqiU5JvqlxU7a
>> of8gsbh-yweeNchMgtkamyXrwzrA/edit?usp=sharing. Changes with more than
1%
>> rise or drop compared to the average of previous 5 commits are colored
in
>> green or red, respectively.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161211/f951ace2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Capture.GIF
Type: image/gif
Size: 34826 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161211/f951ace2/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Capture.GIF
Type: image/gif
Size: 24502 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161211/f951ace2/attachment-0003.gif>

Thank you for this exciting update about LLD.

I will start experimenting with using liblld in Zig (http://ziglang.org/)
instead of starting a child process to invoke the system linker. Once
liblld makes it into the various package managers out there, this will be a
big step toward painless cross-platform compilation.

It should also reduce one of the compilation speed bottlenecks, since I
could transition from writing objects to the file system to passing liblld
LLVM modules directly. Is that correct?

-Andrew

On Sun, Dec 11, 2016 at 10:04 PM, Rui Ueyama via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> Now that 2016 is almost over, I wanted to look back and summarize the
> progress we've made to LLD this year, as I guess most people who are
not
> looking closely at LLD don't know very well about the current status. I
> think I can say that this year was a fantastic year for LLD. Now I'm
pretty
> sure that that is going to be a serious (and better, in my opinion)
> alternative to the existing GNU linkers thanks to all the improvements
> we've made this year.
>
> LLD is now able to link most x86-64 userland programs. The FreeBSD project
> and we are trying to make LLD the system default linker of the operating
> system, and except a few tricky programs such as the kernel or a boot
> loader, the linker works mostly fine. We are still working on implementing
> long-tail features/bugs, but I'd say that's just a matter of time.
LLD
> supports x86, x86-64, x32, AArch64, AMDGPU, ARM, PPC64 and MIPS32/64,
> though completeness varies.
>
> Looks like there are already a few systems that are using LLD as system
> linkers, such as CloudABI or Fuchsia. Chromium and Clang/LLVM itself has
> build options to use LLD to build them.
>
> It is hard to argue about the complexity of a program quantitatively, and
> of course I'm biased, but I believe we succeeded to maintain LLD code
base
> clean, easy to read, and easy to add new features. It is just 20k lines of
> modern C++ code which is much smaller than GNU linkers.
>
> Even though LLD was fast from day one, LLD got faster this year, despite
> it got a lot of new features. Below is a chart of Clang link time for every
> commit made to the LLD repository this year. At the beginning of this year,
> LLD took about 16 seconds to produce a 1.5 GB clang (debug build)
> executable. Now, it takes about 14.5 seconds on single core and 8.5 seconds
> on 20 cores (*1). ld.gold takes about 25 seconds and 20 seconds,
> respectively, so we've widen the gap. You can see the benchmark results
> here (*2). If you have a problem of too long link time, I'd recommend
to
> try LLD.
>
> Last but not least, a lot of people joined to the LLD development this
> year to make LLD better. We are growing as a community, and I'm very
happy
> about that!
>
> Thanks,
> Rui
>
> (*1) My machine has Ivy Bridge Xeon 2.8 GHz 20 physical cores (40
> hyper-threading cores). To measure a single-thread performance, I pinned a
> process to (physical and hyper-threading) core 0. To measure a multi-thread
> performance, I pinned to CPU socket 2, so that a process gets 10 physical
> cores (20 hyperthreading cores).
>
> (*2) https://docs.google.com/spreadsheets/d/1VvOqiU5JvqlxU7aof8gsbh-
> yweeNchMgtkamyXrwzrA/edit?usp=sharing. Changes with more than 1% rise or
> drop compared to the average of previous 5 commits are colored in green or
> red, respectively.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161211/c82a6658/attachment.html>

On Sun, Dec 11, 2016 at 7:31 PM, Andrew Kelley <superjoe30 at gmail.com>
wrote:
> Thank you for this exciting update about LLD.
>
> I will start experimenting with using liblld in Zig (http://ziglang.org/)
> instead of starting a child process to invoke the system linker. Once
> liblld makes it into the various package managers out there, this will be a
> big step toward painless cross-platform compilation.
>
> It should also reduce one of the compilation speed bottlenecks, since I
> could transition from writing objects to the file system to passing liblld
> LLVM modules directly. Is that correct?
>
LLD's driver currently takes only a command line argument strings, so you
need to write ELF files to a filesystem and read them back at the moment.

Theoretically, we could accept a list of command line strings and
MemoryBuffer objects (instead of filenames) so that we can link in-memory
ELF object files. Adding that feature shouldn't be hard.

> -Andrew
>
> On Sun, Dec 11, 2016 at 10:04 PM, Rui Ueyama via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Hi,
>>
>> Now that 2016 is almost over, I wanted to look back and summarize the
>> progress we've made to LLD this year, as I guess most people who
are not
>> looking closely at LLD don't know very well about the current
status. I
>> think I can say that this year was a fantastic year for LLD. Now
I'm pretty
>> sure that that is going to be a serious (and better, in my opinion)
>> alternative to the existing GNU linkers thanks to all the improvements
>> we've made this year.
>>
>> LLD is now able to link most x86-64 userland programs. The FreeBSD
>> project and we are trying to make LLD the system default linker of the
>> operating system, and except a few tricky programs such as the kernel
or a
>> boot loader, the linker works mostly fine. We are still working on
>> implementing long-tail features/bugs, but I'd say that's just a
matter of
>> time. LLD supports x86, x86-64, x32, AArch64, AMDGPU, ARM, PPC64 and
>> MIPS32/64, though completeness varies.
>>
>> Looks like there are already a few systems that are using LLD as system
>> linkers, such as CloudABI or Fuchsia. Chromium and Clang/LLVM itself
has
>> build options to use LLD to build them.
>>
>> It is hard to argue about the complexity of a program quantitatively,
and
>> of course I'm biased, but I believe we succeeded to maintain LLD
code base
>> clean, easy to read, and easy to add new features. It is just 20k lines
of
>> modern C++ code which is much smaller than GNU linkers.
>>
>> Even though LLD was fast from day one, LLD got faster this year,
despite
>> it got a lot of new features. Below is a chart of Clang link time for
every
>> commit made to the LLD repository this year. At the beginning of this
year,
>> LLD took about 16 seconds to produce a 1.5 GB clang (debug build)
>> executable. Now, it takes about 14.5 seconds on single core and 8.5
seconds
>> on 20 cores (*1). ld.gold takes about 25 seconds and 20 seconds,
>> respectively, so we've widen the gap. You can see the benchmark
results
>> here (*2). If you have a problem of too long link time, I'd
recommend to
>> try LLD.
>>
>> Last but not least, a lot of people joined to the LLD development this
>> year to make LLD better. We are growing as a community, and I'm
very happy
>> about that!
>>
>> Thanks,
>> Rui
>>
>> (*1) My machine has Ivy Bridge Xeon 2.8 GHz 20 physical cores (40
>> hyper-threading cores). To measure a single-thread performance, I
pinned a
>> process to (physical and hyper-threading) core 0. To measure a
multi-thread
>> performance, I pinned to CPU socket 2, so that a process gets 10
physical
>> cores (20 hyperthreading cores).
>>
>> (*2) https://docs.google.com/spreadsheets/d/1VvOqiU5JvqlxU7a
>> of8gsbh-yweeNchMgtkamyXrwzrA/edit?usp=sharing. Changes with more than
1%
>> rise or drop compared to the average of previous 5 commits are colored
in
>> green or red, respectively.
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161211/cb098ec8/attachment.html>

Thanks a lot for the summary!

As my last big task for the year I was asked to check the status of the
ports build in freebsd. That includes a tremendous amount of software,
and we are doing very well there.

With just a few hacks (including printing "not GNU" in --version) the
results are that we can build 19828 packages and 179 fail. There were
also 6175 skipped.

Some of the failures don't look lld specific (I noticed a missing
dependency on makeinfo for example). Others are because of our library
handling and yet others are because of broken object files.

I will try to upload all the failed logs and build dirs somewhere before
I go on vacation, but it is pretty impressive how much we can link and works.

Cheers,
Rafael


Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> writes:
> Hi,
>
> Now that 2016 is almost over, I wanted to look back and summarize the
> progress we've made to LLD this year, as I guess most people who are
not
> looking closely at LLD don't know very well about the current status. I
> think I can say that this year was a fantastic year for LLD. Now I'm
pretty
> sure that that is going to be a serious (and better, in my opinion)
> alternative to the existing GNU linkers thanks to all the improvements
> we've made this year.
>
> LLD is now able to link most x86-64 userland programs. The FreeBSD project
> and we are trying to make LLD the system default linker of the operating
> system, and except a few tricky programs such as the kernel or a boot
> loader, the linker works mostly fine. We are still working on implementing
> long-tail features/bugs, but I'd say that's just a matter of time.
LLD
> supports x86, x86-64, x32, AArch64, AMDGPU, ARM, PPC64 and MIPS32/64,
> though completeness varies.
>
> Looks like there are already a few systems that are using LLD as system
> linkers, such as CloudABI or Fuchsia. Chromium and Clang/LLVM itself has
> build options to use LLD to build them.
>
> It is hard to argue about the complexity of a program quantitatively, and
> of course I'm biased, but I believe we succeeded to maintain LLD code
base
> clean, easy to read, and easy to add new features. It is just 20k lines of
> modern C++ code which is much smaller than GNU linkers.
>
> Even though LLD was fast from day one, LLD got faster this year, despite it
> got a lot of new features. Below is a chart of Clang link time for every
> commit made to the LLD repository this year. At the beginning of this year,
> LLD took about 16 seconds to produce a 1.5 GB clang (debug build)
> executable. Now, it takes about 14.5 seconds on single core and 8.5 seconds
> on 20 cores (*1). ld.gold takes about 25 seconds and 20 seconds,
> respectively, so we've widen the gap. You can see the benchmark results
> here (*2). If you have a problem of too long link time, I'd recommend
to
> try LLD.
>
> Last but not least, a lot of people joined to the LLD development this
> year to make LLD better. We are growing as a community, and I'm very
happy
> about that!
>
> Thanks,
> Rui
>
> (*1) My machine has Ivy Bridge Xeon 2.8 GHz 20 physical cores (40
> hyper-threading cores). To measure a single-thread performance, I pinned a
> process to (physical and hyper-threading) core 0. To measure a multi-thread
> performance, I pinned to CPU socket 2, so that a process gets 10 physical
> cores (20 hyperthreading cores).
>
> (*2)
>
https://docs.google.com/spreadsheets/d/1VvOqiU5JvqlxU7aof8gsbh-yweeNchMgtkamyXrwzrA/edit?usp=sharing.
> Changes with more than 1% rise or drop compared to the average of previous
> 5 commits are colored in green or red, respectively.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

On 12 December 2016 at 03:04, Rui Ueyama via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> LLD is now able to link most x86-64 userland programs. The FreeBSD project
> and we are trying to make LLD the system default linker of the operating
> system, and except a few tricky programs such as the kernel or a boot
> loader, the linker works mostly fine. We are still working on implementing
> long-tail features/bugs, but I'd say that's just a matter of time.
LLD
> supports x86, x86-64, x32, AArch64, AMDGPU, ARM, PPC64 and MIPS32/64,
> though completeness varies.
>
Thanks for the update!
>From our side, AArch64 is stable and "production ready", though
not
necessarily complete. We now have a buildbot that bootstraps Clang and runs
the test-suite with LLD:

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-lld

We'll start looking at other large and complex programs next (though Clang
is quite complex and libclang is quite large already).

ARM support is coming a long way, but we're still not able to link Clang
yet, and there are some issues on the test-suite. We'll be continuing to
make progress throughout next year and hopefully have a similar buildbot on
ARM.

Rafael,

Great news about FreeBSD! Once LLD has become their default linker in
x86_64, I'd like to start the same process on AArch64.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161212/0a7c0cb2/attachment.html>

Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> writes:
> ARM support is coming a long way, but we're still not able to link
Clang
> yet, and there are some issues on the test-suite. We'll be continuing
to
> make progress throughout next year and hopefully have a similar buildbot on
> ARM.
BTW, can you link it if you enable only the ARM target? Last time I
tried on TK1 the only remaining issue was the range extension thunks and
with only one target we got lucky and didn't need them.

> Rafael,
>
> Great news about FreeBSD! Once LLD has become their default linker in
> x86_64, I'd like to start the same process on AArch64.
Awesome. I actually expect a much smaller tail on AArch64 than on X86_64.

Cheers,
Rafael

LLD/ELF is is only about a year and a half old, and it's amazing how far
we've come. I have LLD/ELF to thank for the fondest memories of my time at
PlayStation; I can't count how many times Michael and I were there past
midnight getting things working, and after Davide joined us, seeing him
leave every night limited only by how late the last Caltrain would run.
It's amazing to be a part of this.

One of the most exciting things in the last months has been this new phase
LLD has entered where new developers are joining, fixing the bugs they find
and implementing the features they need as they port LLD to new platforms
-- that is the ultimate validation that we're doing something right.

-- Sean Silva

On Sun, Dec 11, 2016 at 7:04 PM, Rui Ueyama via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> Now that 2016 is almost over, I wanted to look back and summarize the
> progress we've made to LLD this year, as I guess most people who are
not
> looking closely at LLD don't know very well about the current status. I
> think I can say that this year was a fantastic year for LLD. Now I'm
pretty
> sure that that is going to be a serious (and better, in my opinion)
> alternative to the existing GNU linkers thanks to all the improvements
> we've made this year.
>
> LLD is now able to link most x86-64 userland programs. The FreeBSD project
> and we are trying to make LLD the system default linker of the operating
> system, and except a few tricky programs such as the kernel or a boot
> loader, the linker works mostly fine. We are still working on implementing
> long-tail features/bugs, but I'd say that's just a matter of time.
LLD
> supports x86, x86-64, x32, AArch64, AMDGPU, ARM, PPC64 and MIPS32/64,
> though completeness varies.
>
> Looks like there are already a few systems that are using LLD as system
> linkers, such as CloudABI or Fuchsia. Chromium and Clang/LLVM itself has
> build options to use LLD to build them.
>
> It is hard to argue about the complexity of a program quantitatively, and
> of course I'm biased, but I believe we succeeded to maintain LLD code
base
> clean, easy to read, and easy to add new features. It is just 20k lines of
> modern C++ code which is much smaller than GNU linkers.
>
> Even though LLD was fast from day one, LLD got faster this year, despite
> it got a lot of new features. Below is a chart of Clang link time for every
> commit made to the LLD repository this year. At the beginning of this year,
> LLD took about 16 seconds to produce a 1.5 GB clang (debug build)
> executable. Now, it takes about 14.5 seconds on single core and 8.5 seconds
> on 20 cores (*1). ld.gold takes about 25 seconds and 20 seconds,
> respectively, so we've widen the gap. You can see the benchmark results
> here (*2). If you have a problem of too long link time, I'd recommend
to
> try LLD.
>
> Last but not least, a lot of people joined to the LLD development this
> year to make LLD better. We are growing as a community, and I'm very
happy
> about that!
>
> Thanks,
> Rui
>
> (*1) My machine has Ivy Bridge Xeon 2.8 GHz 20 physical cores (40
> hyper-threading cores). To measure a single-thread performance, I pinned a
> process to (physical and hyper-threading) core 0. To measure a multi-thread
> performance, I pinned to CPU socket 2, so that a process gets 10 physical
> cores (20 hyperthreading cores).
>
> (*2) https://docs.google.com/spreadsheets/d/1VvOqiU5JvqlxU7aof8gsbh-
> yweeNchMgtkamyXrwzrA/edit?usp=sharing. Changes with more than 1% rise or
> drop compared to the average of previous 5 commits are colored in green or
> red, respectively.
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20161212/ed8f93d4/attachment.html>