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

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 Tue, Dec 13, 2016 at 1:22 PM, Davide Italiano <davide at freebsd.org>
wrote:
> 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
s/lld/lld as a library/

--
Davide

On Tue, Dec 13, 2016 at 1:22 PM, Davide Italiano via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> 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.
>
I don't know if FreeBSD support affected the LLD architecture. FreeBSD
affected the priority of the to-do items for sure, but the linker
architecture was set much before we started experimenting it on FreeBSD.

I'd object the binary-ish thinking that we had two exclusive choices, speed
or modularity (whatever it means in the linker's context). It's not what
I
have in my mind. LLD is usable as a library already, you can embed it to
your product, and I believe that satisfies many use cases. That's modular
(you can use a linker as a module) and very fast. What do you want more
than that? If you want more features for different use cases, please bring
up.

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
> _______________________________________________
> 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/20161213/9f6c61f7/attachment.html>

On Tue, Dec 13, 2016 at 1:54 PM, Rui Ueyama <ruiu at google.com>
wrote:
> On Tue, Dec 13, 2016 at 1:22 PM, Davide Italiano via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>>
>> 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.
>
>
> I don't know if FreeBSD support affected the LLD architecture. FreeBSD
> affected the priority of the to-do items for sure, but the linker
> architecture was set much before we started experimenting it on FreeBSD.
>
It's the other way around. lld more than once resulted in change in
FreeBSD, see for example Kostik's comment in
https://reviews.freebsd.org/D8610#178738

> I'd object the binary-ish thinking that we had two exclusive choices,
speed
> or modularity (whatever it means in the linker's context). It's not
what I
> have in my mind. LLD is usable as a library already, you can embed it to
> your product, and I believe that satisfies many use cases. That's
modular
> (you can use a linker as a module) and very fast. What do you want more
than
> that? If you want more features for different use cases, please bring up.
>
lld is reasonable for my purposes as it is. That's why I deliberately
avoided to comment on lld as a library.

-- 
Davide

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