Live data from Hacker News

How to speed up the Rust compiler one last time

blog.mozilla.org

51–60 of 61 posts

Re: How to speed up the Rust compiler one last time

#51
post #45
post #39

Earlier quoted context omitted.

I'd honestly rather see Rust survive, than Mozilla. Mozilla is few years away from going Blink, and on deathbed. Rust is up and coming language.

While I'd begrudgingly agree the two are not independent. I moved back to Firefox from Chrome exactly because Firefox became once again performance competitive thanks to Quantum. Most (all?) the big Firefox improvements were integrations of Rust code pioneered in servo. The only chance I see for Firefox is doubling down on that and replacing more and more components with those Rust rewrites. If not for that I don't s…

Didn't Mozilla like fire all of their Rust devs? There is no plans for supporting Rust in Firefox AFAIK.

Re: How to speed up the Rust compiler one last time

#52
post #51
post #45

Earlier quoted context omitted.

While I'd begrudgingly agree the two are not independent. I moved back to Firefox from Chrome exactly because Firefox became once again performance competitive thanks to Quantum. Most (all?) the big Firefox improvements were integrations of Rust code pioneered in servo. The only chance I see for Firefox is doubling down on that and replacing more and more components with those Rust rewrites. If not for that I don't s…

Didn't Mozilla like fire all of their Rust devs? There is no plans for supporting Rust in Firefox AFAIK.

There already is Rust in Firefox and has been for years.

Re: How to speed up the Rust compiler one last time

#53
post #51

Earlier quoted context omitted.

Didn't Mozilla like fire all of their Rust devs? There is no plans for supporting Rust in Firefox AFAIK.

There already is Rust in Firefox and has been for years.

True, but not what parent is saying.

> The only chance I see for Firefox is doubling down on that and replacing more and more components with those Rust rewrites

If Firefox has no more Rust developers now, it can't "double down" on replacing components, and all software is prone to bitrot, so after a few years, it will be an unmaintainable, buggy mess.

Re: How to speed up the Rust compiler one last time

#54
post #53

Earlier quoted context omitted.

There already is Rust in Firefox and has been for years.

True, but not what parent is saying. > The only chance I see for Firefox is doubling down on that and replacing more and more components with those Rust rewrites If Firefox has no more Rust developers now, it can't "double down" on replacing components, and all software is prone to bitrot, so after a few years, it will be an unmaintainable, buggy mess.

Mozilla can still use Rust even if they don't pay people to work on Rust. The vast, vast majority of users do exactly that.

My understanding is that there is still plans for more Rust in Firefox.

Re: How to speed up the Rust compiler one last time

#55

Earlier quoted context omitted.

So have you not found in practice any data dependencies or cache issues show up as bottle necks? Or do current tools just make this more of a blind spot for optimization? Also is there any work to multi-thread the Rust compiler on a more fine-grained level like the recent GCC work? I know you allude to that potentially that would make the instruction counts potentially less reliable so wondering if that's something b…

I mentioned in the post several areas I myself haven't looked at, including cache misses. There may be room for improvements there. There is an experimental parallel rustc front-end, e.g. see https://internals.rust-lang.org/t/help-test-parallel-rustc/1... > any exploration of the idea of keeping track of information across builds so that incremental compilation is faster That's exactly what incremental compilation do…

There's an effort to track which functions are modules & what the downstream implications of that are in terms of needing recompilation? Are there any links to technical descriptions? Super interested in reading up on the technical details involved.

Re: How to speed up the Rust compiler one last time

#56

Earlier quoted context omitted.

Clang doesn't do optimizations though. It generates llvm via a simple tree walk.

What's big in C or C++ translation units are header files, but since these mainly contain declarations, and declarations do not require code generation, they don't create any work for the compiler backend. Rust translation units do not have the header file problem (so the frontend does less work), and they are also much larger in terms of definitions, often spawning multiple files, so there is more for the backend to…

Ah. Same problem with static inline functions defined in headers in the kernel. They may not end up generating code, but clang doesn't know that and will still generate llvm for the backend to determine is dead, after clang has already done lots of work performing semantic analysis on it.

Orthogonal to your point:

Also, aggressively marking functions __attribute__((always_inline)) we found was blowing up compile times (reoptimizing the same code again and again).

Finally, expansions of function like macros containing GNU C statement expressions could cause the preprocessed source to bloat very quickly (megabytes of input, IIRC).

Re: How to speed up the Rust compiler one last time

#57
post #53

Earlier quoted context omitted.

There already is Rust in Firefox and has been for years.

True, but not what parent is saying. > The only chance I see for Firefox is doubling down on that and replacing more and more components with those Rust rewrites If Firefox has no more Rust developers now, it can't "double down" on replacing components, and all software is prone to bitrot, so after a few years, it will be an unmaintainable, buggy mess.

I think there is confusion here over the meaning of "Rust developer".

Mozilla did lay off most of its employees that were working directly on the Rust language and its implementation. This was a handful of people.

Mozilla also laid off some employees that were using Rust, such as the Servo team.

But Mozilla still has plenty of employees that know and use Rust, both in Firefox (e.g. the WebRender team), and in code relating to Firefox such as services. This is a much larger number of people.

Re: How to speed up the Rust compiler one last time

#58

Earlier quoted context omitted.

I mentioned in the post several areas I myself haven't looked at, including cache misses. There may be room for improvements there. There is an experimental parallel rustc front-end, e.g. see https://internals.rust-lang.org/t/help-test-parallel-rustc/1... > any exploration of the idea of keeping track of information across builds so that incremental compilation is faster That's exactly what incremental compilation do…

There's an effort to track which functions are modules & what the downstream implications of that are in terms of needing recompilation? Are there any links to technical descriptions? Super interested in reading up on the technical details involved.

You might want to look into Salsa:

http://smallcultfollowing.com/babysteps/blog/2019/01/29/sals...

http://smallcultfollowing.com/babysteps/blog/2020/04/09/libr...

Re: How to speed up the Rust compiler one last time

#59

Earlier quoted context omitted.

What's big in C or C++ translation units are header files, but since these mainly contain declarations, and declarations do not require code generation, they don't create any work for the compiler backend. Rust translation units do not have the header file problem (so the frontend does less work), and they are also much larger in terms of definitions, often spawning multiple files, so there is more for the backend to…

Ah. Same problem with static inline functions defined in headers in the kernel. They may not end up generating code, but clang doesn't know that and will still generate llvm for the backend to determine is dead, after clang has already done lots of work performing semantic analysis on it. Orthogonal to your point: Also, aggressively marking functions __attribute__((always_inline)) we found was blowing up compile time…

Rust doesn't have the "static in header" problem, but it does have the "always inline" and "macros" problem.

The "always inline" problem is smaller in Rust, because it does Thin LTO by default, compiles partially to bit-code, that can be partially inlined if necessary, etc. So essentially the Rust toolchain is a bit better at inlining when its profitable than C and C++ toolchains "by default" (you can tune C and C++ toolchains like clang to be as good as Rust).

In C and C++, macros are generally frowned upon, not because of this compile-time issues, but rather because they are dangerous, tricky, non-hygienic, powerful usage requires complex patterns, their interaction with header files and PCHs, etc.

Rust macros are awesome, super useful, widely used, etc. So people end up using them a lot, and this is by design, not a flaw of the language. This ends up resulting in a lot of duplicated code being expanded, and that leads to the problem that you mention, but much worse, because there are just many more macros in Rust.

This kind of applies to templates / traits as well. There are many C++ that don't write templates, but all Rust programmers use generics because they are great. Rust can pre-compile generics, so the cost of this is not as bad as for C++ where the same generic might be instantiated by multiple TUs. But still, just by the fact that they are more widely used, the size of the problem grows.

Re: How to speed up the Rust compiler one last time

#60

> Contrary to what you might expect, instruction counts have proven much better than wall times when it comes to detecting performance changes on CI, because instruction counts are much less variable than wall times (e.g. ±0.1% vs ±3%; the former is highly useful, the latter is barely useful). Using instruction counts to compare the performance of two entirely different programs (e.g. GCC vs clang) would be foolish,…

It isn't surprising to me that instruction counts as a performance metric would have less variance than wall time. Did you know that the environment size can actually affect wall time? > We see that something external and orthogonal to the program, i.e., changing the size (in bytes) of an unused environment variable, can dramatically (frequently by about 33% and once by almost 300%) change the performance of our prog…

That's exactly my point! The only thing that matters is wall clock time so if cache layout is making a 300% difference to wall clock, focusing on instructions counts will mislead you on the most impactful optimization to make (i.e. cache layout optimizations won't show up in instruction counts).

And yes. I'm aware of that result because of Professor Berger's talks on Coz & the other work he's done in this space.

Post reply on HN