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

On 13 Dec 2016, at 19:02, Mehdi Amini via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> I’m totally willing to believe you that it is not possible to write the
fastest ELF linker on earth (or in the universe) with a library based and
reusable components approach. But clang is not the fastest C/C++ compiler
available, and LLVM is not the fastest compiler framework either!
I’m not how it compares now, but at least when I started contributing and for a
year or two after the speed of clang (especially at O0, for fast
compile-test-debug cycles) was one of its big selling points.

David

> On Dec 13, 2016, at 11:06 AM, David Chisnall <David.Chisnall at
cl.cam.ac.uk> wrote:
> 
> On 13 Dec 2016, at 19:02, Mehdi Amini via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>> 
>> I’m totally willing to believe you that it is not possible to write the
fastest ELF linker on earth (or in the universe) with a library based and
reusable components approach. But clang is not the fastest C/C++ compiler
available, and LLVM is not the fastest compiler framework either!
> 
> I’m not how it compares now, but at least when I started contributing and
for a year or two after the speed of clang (especially at O0, for fast
compile-test-debug cycles) was one of its big selling points.
Some data: 
- http://baptiste-wicht.com/posts/2016/11/zapcc-a-faster-cpp-compiler.html
<http://baptiste-wicht.com/posts/2016/11/zapcc-a-faster-cpp-compiler.html>
-
http://hubicka.blogspot.nl/2016/03/building-libreoffice-with-gcc-6-and-lto.html
<http://hubicka.blogspot.nl/2016/03/building-libreoffice-with-gcc-6-and-lto.html>

That does not mean we’re not taking compile time seriously: we are and we (at
least a few people I know of) are planning on improving it, hopefully
significantly. I don’t believe we’d ever go against the design principles
(modularity, etc.) though.

Also, the above data is just about clang as a C/C++ compiler. LLVM is a
different beast and its overhead (that is somehow inherent with the features
provided) is "well known” (for example I believe this drove:
https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/
<https://webkit.org/blog/5852/introducing-the-b3-jit-compiler/> ; but you
can find other examples).

— 
Mehdi

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

David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> writes:
> On 13 Dec 2016, at 19:02, Mehdi Amini via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>> 
>> I’m totally willing to believe you that it is not possible to write the
fastest ELF linker on earth (or in the universe) with a library based and
reusable components approach. But clang is not the fastest C/C++ compiler
available, and LLVM is not the fastest compiler framework either!
>
> I’m not how it compares now, but at least when I started contributing and
for a year or two after the speed of clang (especially at O0, for fast
compile-test-debug cycles) was one of its big selling points.
It is pretty horrible actually. Last I measure (March) clang was slower
than gcc at building llvm+clang. The subject is "llvm and clang are
getting slower" if you want to search for the details.

Another reason for having lld "done" and benchmarked first.

Cheers,
Rafael

> Another reason for having lld "done" and benchmarked first.
Please be honest with us. Your position is clearly "over my dead
body", perhaps best phrased as "when I consider lld done and have
moved onto something else".

Tim.

On Tue, Dec 13, 2016 at 12:22 PM, Rafael Avila de Espindola via
llvm-dev <llvm-dev at lists.llvm.org> wrote:
> David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> writes:
>
>> On 13 Dec 2016, at 19:02, Mehdi Amini via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>>
>>> I’m totally willing to believe you that it is not possible to write
the fastest ELF linker on earth (or in the universe) with a library based and
reusable components approach. But clang is not the fastest C/C++ compiler
available, and LLVM is not the fastest compiler framework either!
>>
>> I’m not how it compares now, but at least when I started contributing
and for a year or two after the speed of clang (especially at O0, for fast
compile-test-debug cycles) was one of its big selling points.
>
> It is pretty horrible actually. Last I measure (March) clang was slower
> than gcc at building llvm+clang. The subject is "llvm and clang are
> getting slower" if you want to search for the details.
>
> Another reason for having lld "done" and benchmarked first.
>
I wouldn't use the word "horrible" here.

I'm not going to express an opinion about lld, and I'm not familiar
enough with clang to judge, but it's pretty clear that the reason LLVM
(in particular the middle-end) is slow is not because it is a library.
It's slow because there are passes using suboptimal algorithms and the
cost of replacing them increases over time for multiple reasons (risk
of introducing miscompiles, not catching cases that people added
because they speed up their microbenchmarks, lack of reviewers, you
name it).

lld is also in a very particular situation right now because the main
OS where it's used is FreeBSD, which desperately needs a linker to
replace a 10 years-old legacy, so people are willing to change their
linker scripts or user-facing linker features (e.g. options) because
there's no other candy shop in town.

clang is not in the same situation, because it has to support all C++
(which is by itself far more complicated than anything a linker will
ever support) and llvm has (might want to?) support all kind of crazy
optimizations because it's fundamentally unreasonable to ask an user
to canonicalize/change his code to get better performances that the
optimizer could catch just fine because they're "too complicated".

I think (but that's just my wild guess) the situation will be
different if lld will ever decide to try to become the system linker
on Linux, where there are already two alternatives so people have much
more flexibility and user may be less keen to change stuffs on their
side to keep the linker simple/fast/clean.

Side note, the amount of complexity in the optimizer is not even
remotely comparable to the one in the linker, so I don't think it's a
fair to talk about performance tracking of the two together.

That said, I agree that lld received much more attention optimizing
performances than llvm did (although the situation is slowly changing
in the last few months), so llvm has definitely something to learn
from lld on this side (and apparently it is).

Ciao,

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare

On 12/13/2016 12:22 PM, Rafael Avila de Espindola via llvm-dev
wrote:
> David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> writes:
>
>> On 13 Dec 2016, at 19:02, Mehdi Amini via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>>> I’m totally willing to believe you that it is not possible to write
the fastest ELF linker on earth (or in the universe) with a library based and
reusable components approach. But clang is not the fastest C/C++ compiler
available, and LLVM is not the fastest compiler framework either!
>> I’m not how it compares now, but at least when I started contributing
and for a year or two after the speed of clang (especially at O0, for fast
compile-test-debug cycles) was one of its big selling points.
> It is pretty horrible actually. Last I measure (March) clang was slower
> than gcc at building llvm+clang. The subject is "llvm and clang are
> getting slower" if you want to search for the details.
>
> Another reason for having lld "done" and benchmarked first.
Can you define "done"?  This is a serious question; I am not trolling 
here.  I can understand your desire to finish one effort first, but if 
you're going to put off other work until it is "done", you need to
clearly define what that means.
>
> Cheers,
> Rafael
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev