LLVM's New LLD ELF Linker Continues To Mature For Linux Systems

[phoronix]

Phoronix: LLVM's New LLD ELF Linker Continues To Mature For Linux Systems

Last year LLVM developers made significant progress on developing a new ELF linker for Linux/Unix-like systems. Since then, this high-performance linker from LLD (dubbed "LLD") has continued maturing and gaining additional functionality...

http://www.phoronix.com/scan.php?page=news_item&px=LLD-Linker-ELF-Progress-2016

[milkylainen]

Don't care. Proof of concept linkers (or various other tools) claiming fame through speed without passing the available complexity/configurability of existing programs is not rocket science. This linker is not even scriptable yet. Ignoring standard/functionality and claming "should work" is not comparable either.

It is the same with LLVM/Clang vs GCC. In the beginning it was all like. "Ohhh. It is soo shiny. I can compile gazillion lines per second. GCC is soo slooow."
Now as the featureset creeps up and GCC is adding effort to optimize, they are closing in on eachother. Who would have guessed...

[octoploid]

Don't care. Proof of concept linkers (or various other tools) claiming fame through speed without passing the available complexity/configurability of existing programs is not rocket science. This linker is not even scriptable yet. Ignoring standard/functionality and claming "should work" is not comparable either.

It is the same with LLVM/Clang vs GCC. In the beginning it was all like. "Ohhh. It is soo shiny. I can compile gazillion lines per second. GCC is soo slooow."
Now as the featureset creeps up and GCC is adding effort to optimize, they are closing in on eachother. Who would have guessed...

Exactly.
GCC now actually compiles faster than Clang and still produces better binaries.
The same thing will happen here, once they implement all the linker script features.
And why would anyone help to debug a new linker? Gold is fast enough already and it took years to fix all its bugs.

[tessio]

And why would anyone help to debug a new linker? Gold is fast enough already and it took years to fix all its bugs.

The same thing could had been said about Gold in relation to GNU Linker back then.

[Rubble Monkey]

Don't care. Proof of concept linkers (or various other tools) claiming fame through speed without passing the available complexity/configurability of existing programs is not rocket science. This linker is not even scriptable yet. Ignoring standard/functionality and claming "should work" is not comparable either.

It is the same with LLVM/Clang vs GCC. In the beginning it was all like. "Ohhh. It is soo shiny. I can compile gazillion lines per second. GCC is soo slooow."
Now as the featureset creeps up and GCC is adding effort to optimize, they are closing in on eachother. Who would have guessed...

And why do you think GCC is so focused on adding more optimizations? LLVM/Clang, regardless of how it compares performance wise, has added a healthy bit of competition to the mix. Perhaps the same will happen with LLD and GNU Gold. But on a side note, you have to admit that the error messages are nicer looking in clang than GCC.

[VikingGe]

GCC now actually compiles faster than Clang and still produces better binaries.

Which code does GCC actually compile faster?

As for my 200k+ lines of C++ code, Clang is still significantly faster, though not by as much as it was before GCC 5.

But on a side note, you have to admit that the error messages are nicer looking in clang than GCC.

GCC also got some nicer messages. But nicer doesn't always mean nice:

/home/***/Projects/taihen/arstd/db/iter/iterator.h:121:9: error: no matching conversion for functional-style cast from
'ar::Db::JoinIterator<ar::Db::TableIterator<ar::Tuple<ar::Ch, ar::Int<unsigned int> > >, ar::Db::Iterator<
ar::Db::TableIterator<ar::Tuple<ar::Ch, ar::String, ar::String> > >, (lambda at /home/***/Projects/taihen/app/handle
/handle_kanji_category.cpp:42:13)>' to 'ProjectionIterator<ar::Db::JoinIterator<ar::Db::TableIterator<ar::Tuple<
ar::Ch, ar::Int<unsigned int> > >, ar::Db::Iterator<ar::Db::TableIterator<ar::Tuple<ar::Ch, ar::String, ar::String
> > >, (lambda at /home/***/Projects/taihen/app/handle/handle_kanji_category.cpp:42:13)>, 2UL, 3UL, 4UL>'
        ProjectionIterator<Base, ColIds...>(
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[milkylainen]

And why do you think GCC is so focused on adding more optimizations? LLVM/Clang, regardless of how it compares performance wise, has added a healthy bit of competition to the mix. Perhaps the same will happen with LLD and GNU Gold. But on a side note, you have to admit that the error messages are nicer looking in clang than GCC.

Sure. It adds a healthy bit of competition. But it is also the same problem that diverges projects and we never get a standard of anything.
It has always been the same thing. "I don't like X, I can write Wayland and do it much better". "I dont like Y, so I'll do my own Z". In that, they also totally underestimate the complexity and the amount of hours needed to get anything half decent.
And sure enough... Now we have another competing standard.
If people were to focus, and in a consensus dump one project while creating the next generation, that would be fine. But as it stands right now, everybody is reinventing the wheel in a claim for fame race, or "not invented here". Etc.
Divergence kills progress too.

A classic:

https://xkcd.com/927/

[SystemCrasher]

For Linux systems? Michael should be kidding. The only thing using llvm to the date on Linux is AMD GPU drivers. Which is quite a disadvantage for GPU computing when it comes to Linux. Linux distros and devs are using GCC and do not give a fuck about ability of corporations to close source. On other hand, some uncommon toolchain is a quite a major bummer, any day. Needless to say it makes GPU programming far less popular thing than it should to be.

Clang hardly got major adoption anywhere else in Linux. It mostly used by BSDs, well known corporate footpads. Ironically, BSDs are always end being screwed up by their lords. Sorry but this appoach unworkable.