[llvm-dev] LLD status update and performance chart

[Mehdi Amini via llvm-dev]

> 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>