Rust Now Prefers Using The GNU Gold Linker By Default

[phoronix]

Phoronix: Rust Now Prefers Using The GNU Gold Linker By Default

The latest win for GNU's Gold linker is with the Rust programming language...

http://www.phoronix.com/scan.php?page=news_item&px=Rust-Gold-Linker

[Kemosabe]

Why can't it used for kernel modules?

[milkylainen]

Big whoop. Everybody seems to care about the seconds spent compiling and building objects. While I commend the effort being placed in writing gold, it isn't a ld replacement (yet).
Also, speed is usually a (somewhat) function of feature set. While LLVM/Clang and gold might be shiny, new and fast, they do not carry the same feature set as their more mature competitors do.
People tend to forget that GCC is a thirty year old project. The amount of features and cruft collected is just astounding. I will happily benchmark LLVM/Clang 25 years down the road and compare it against a new shiny lightweight compiler.. (Oh.. the new is soo shiny and faaast. It can compile my kernel in 28 seconds instead of 30!).

[Meteorhead]

Big whoop. Everybody seems to care about the seconds spent compiling and building objects. While I commend the effort being placed in writing gold, it isn't a ld replacement (yet).
Also, speed is usually a (somewhat) function of feature set. While LLVM/Clang and gold might be shiny, new and fast, they do not carry the same feature set as their more mature competitors do.
People tend to forget that GCC is a thirty year old project. The amount of features and cruft collected is just astounding. I will happily benchmark LLVM/Clang 25 years down the road and compare it against a new shiny lightweight compiler.. (Oh.. the new is soo shiny and faaast. It can compile my kernel in 28 seconds instead of 30!).

Following up on your thoughts:

X.Org is a 30 year old project. XServer rocks, who needs this new and shiny Wayland anyway...

Just because something is 30 years old doesn't render it automatically better, than something new. The new and shiny isn't better, because it is inherently better, or because it is simply new. The new and shiny is exactly the same as the old, but written WITH the 30 years of wisdom that has accumulated in the old. It is something that looks as if the developers of the old could go back in time and start over fresh with the experience gained over time.

XServer has design choices deeply rooted that cannot be changed and which seemed like a good idea at the time, but proved to be wrong decisions. They were indeed good choices at the time, but software development evolved and XServer become obsolete, but archaic the least. Same things goes pretty much for object orientation. It seemed like a good idea at the time, but it proved not to scale. Objects with 128 members are not efficient when thrown about in memory inside nested loops. Something else needs to be done in these cases (Data-oriented Design?).

So yes, the new and shiny respects the old, but has every chance of becoming equally feature rich, but in less amount of time. If it does not reimplement the old in 5 years instead of 30, they need to reevaluate.

[smitty3268]

Big whoop. Everybody seems to care about the seconds spent compiling and building objects. While I commend the effort being placed in writing gold, it isn't a ld replacement (yet).
Also, speed is usually a (somewhat) function of feature set. While LLVM/Clang and gold might be shiny, new and fast, they do not carry the same feature set as their more mature competitors do.
People tend to forget that GCC is a thirty year old project. The amount of features and cruft collected is just astounding. I will happily benchmark LLVM/Clang 25 years down the road and compare it against a new shiny lightweight compiler.. (Oh.. the new is soo shiny and faaast. It can compile my kernel in 28 seconds instead of 30!).

When your linker takes longer to run than the actual compiler, you have a problem. Also, the GNU devs have acknowledged how terrible the LD code is, which is why they accepted the gold project into binutils.

I certainly agree that newer isn't always better, but in this case it is.

[Luke_Wolf]

Same things goes pretty much for object orientation. It seemed like a good idea at the time, but it proved not to scale. Objects with 128 members are not efficient when thrown about in memory inside nested loops. Something else needs to be done in these cases (Data-oriented Design?).

If you've got 128 members on an object I can guarantee that whatever you're looking at isn't Object Oriented design. There aren't any real scaling problems with proper OOP.

[Ericg]

Big whoop. Everybody seems to care about the seconds spent compiling and building objects. While I commend the effort being placed in writing gold, it isn't a ld replacement (yet).
Also, speed is usually a (somewhat) function of feature set. While LLVM/Clang and gold might be shiny, new and fast, they do not carry the same feature set as their more mature competitors do.
People tend to forget that GCC is a thirty year old project. The amount of features and cruft collected is just astounding. I will happily benchmark LLVM/Clang 25 years down the road and compare it against a new shiny lightweight compiler.. (Oh.. the new is soo shiny and faaast. It can compile my kernel in 28 seconds instead of 30!).

Its not just features though, its paradigms and mentalities and the way things are done. Thirty years down the road, there will be a new shiny compiler that will be benchmarked against LLVM/Clang and GCC, and it will be faster than both of them on similar hardware. And it won't just be because it has less features, it will be because it has 30yrs of additional research backing it that LLVM, and especially GCC, didn't have, and they have learned new things, and come up with better algorithms and methods for doing things and things continually improve. To say that LLVM/Clang, and Gold are only faster because they support less features is being overly forgiving to GCC and ld, and not being disingenuous to LLVM/Clang and Gold.

[PinkUnicorn1421543]

If you've got 128 members on an object I can guarantee that whatever you're looking at isn't Object Oriented design. There aren't any real scaling problems with proper OOP.

That's 128 members including all nested members. Proper OOP in this case would be 128 levels of indirection.

[Luke_Wolf]

That's 128 members including all nested members. Proper OOP in this case would be 128 levels of indirection.

no it doesn't you moron. Proper OOP dictates that you should use no more than 5 levels of derivation (not including off of Object) and no more than 3 of those should be actual classes with the preference being Interface -> (Abstract Class ->) Class -> Class -> Class. This rule can be broken but if you're going more than 3 deep proper OOP considers it a code smell.

[Ericg]

no it doesn't you moron.

Oi, Luke, cool it. Mods do exist on these forums, as infrequent as they are.