nnethercote

I'm a member of Futurewei's Rust team, and I'm in the Compiler Contributors group.

I started these posts back in 2016 when I wasn't a member of either. It's been a long-running series, and there's never been much reason for them to go on the official Rust blog, because they get enough attention on my personal blog.

In the past I have posted links to Hacker News but usually they don't make the front page and get few if any comments, so I stopped bothering, but others sometimes do. I always post to /r/rust where the level of discussion tends to be higher-quality than HN, because there is a higher level of Rust knowledge.

I've tried AST memory layout work in the Zig style, look for "shrinkage" in these two posts:

- https://nnethercote.github.io/2022/10/27/how-to-speed-up-the...

- https://nnethercote.github.io/2023/03/24/how-to-speed-up-the...

It's hard work. Small AST changes often require hundreds of changes to the code. The required changes usually make the AST less ergonomic to work with. And the perf benefits I obtained were very small. Even after shrinking `ast::Expr` (by far the most common AST node kind) from over 100 bytes to 64 bytes on 64-bit.

The linked Zig PR has very impressive reductions in walltime/cycles/etc. but if you read closely it's restricted just to parsing, which is usually a very small slice of compile time, at least for rustc. My experience with these kinds of changes was disappointing. I concluded "I’d love to be proven wrong, but it doesn’t feel like this work is taking place in a good part of the effort/benefit curve."

I just want to say that this is a very weird but cool approach that I never would have thought of. Nice work!

No problem, I learned that I shouldn't post drafts and assume they will go unnoticed :)

The link above is to a draft version of the blog post, which is no longer available.

The final version (which has a different title) is at https://nnethercote.github.io/2023/07/11/back-end-parallelis....

A HN post about the final version is at https://news.ycombinator.com/item?id=36675281.

Thanks for the suggestion!

I didn't know about this. Thanks for the tip!

The book is primarily about Rust-specific things. Section 1 says: "Some of the techniques within are entirely Rust-specific, and some involve ideas that can be applied (often with modifications) to programs written in other languages." I will clarify this.

Having said that, Section 16 does have general optimization advice, and I will consider adding some brief notes about the things you mentioned there.

Thanks for the suggestion.

It was a really weird and messy situation, and unpleasant to live through.

I agree that Brendan's Prop 8 donation was bad. But he did it privately, and never (AFAIK) made anti-LGBT comments in public. People who had worked with him for many years were surprised to find he had these views. It was only found out because of political donation public disclosure laws.

Some Mozilla employees publicly criticized Brendan for the Prop 8 donation, but some defended him, because of the aforementioned privateness of it. A number of the defenses came from LGBT employees.

The pile-on at the time was intense. It lasted more than a week. It reached the front page of my local paper. Crazy stuff.

Brendan chose to stand down as CEO and also quit Mozilla. He wasn't fired, and Mozilla leadership asked him to stay.

All this nuance was lost. Lots of left-leaning people concluded that Mozilla had knowingly promoted a proudly anti-LGBT guy to CEO. Lots of right-leaning people concluded that Mozilla had fired their CEO for his political views. Both conclusions were greatly over-simplified. Almost everyone found a reason to hate Mozilla. Bad times!

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.

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

> This is a supremely surprising conclusion

That's why I started the paragraph with "Contrary to what you might expect".

As for Stabilizer: "Stabilizer eliminates measurement bias by comprehensively and repeatedly randomizing the placement of functions, stack frames, and heap objects in memory." Those placements can affect cycle counts and wall times a lot, but don't affect instruction counts.

Thank you for the kind words.

To clarify: I am still at Mozilla! But I will be working fully on Firefox for the foreseeable future. I have edited the opening paragraph of the post to make this clearer.

Coming up with a binary "is this acceptable?" heuristic is also harder for performance than it is for correctness.

Thank you for the links and the kind words!

Yes. The good thing about this metric is that there is very little variation, unlike wall times, which makes it easier to spot regressions.

Hi, I'm the author of the blog post.

There is definitely a marketing angle to these posts. Rust has a reputation for slow compilation, and one of my goals is to show that (a) people working on Rust care about compile times, and (b) improvements are being made.

I'll let you judge whether the marketing is backed by actual substance. It's a long-running blog post series, here are links to all the posts.

* https://blog.mozilla.org/nnethercote/2016/10/14/how-to-speed...

* https://blog.mozilla.org/nnethercote/2016/11/23/how-to-speed...

* https://blog.mozilla.org/nnethercote/2018/04/30/how-to-speed...

* https://blog.mozilla.org/nnethercote/2018/06/05/how-to-speed...

* https://blog.mozilla.org/nnethercote/2018/11/06/how-to-speed...

* https://blog.mozilla.org/nnethercote/2019/07/17/how-to-speed...

* https://blog.mozilla.org/nnethercote/2019/07/25/the-rust-com...

* https://blog.mozilla.org/nnethercote/2019/10/11/how-to-speed...

* https://blog.mozilla.org/nnethercote/2019/12/11/how-to-speed...

* https://blog.mozilla.org/nnethercote/2020/04/24/how-to-speed...

* https://blog.mozilla.org/nnethercote/2020/08/05/how-to-speed...

EDIT: I just saw that alilleybrinker already linked to all these and more below: https://news.ycombinator.com/item?id=24061346

That's an excellent explanation.

A small correction: if I recall correctly, the Corporation is legally allowed to give some money to the Foundation, and it does so. But the allowed amount is quite small -- maybe a couple a million a year? I don't remember exactly -- and only a tiny fraction of the Corporation's profits.

As well as templates, C++ has function overloading, so when a function is named in an error message it has to show all the arguments as well. And if it can't find a function variant that matches a call, it'll print out a "did you mean this one?" message for all of them.

Yes, the compiler's error messages are extremely good. They often give correct and useful suggestions on how to change code to make it compile. This can be invaluable when dealing with trickier corners of the language such as explicit lifetimes.

Because my git-fu is weak and I have a fast network connection and a big disk! Doing things the dumb way works fine for me :)

But an apology is much better than no apology, right?

Twice!

Right now there are 81 comments in this thread and bigbugbag has written 18 of them.

There is precedent! https://wiki.mozilla.org/Oxidation

You had a running CSS engine within a day?

It's more complicated than that. Firefox on Android uses much of the core code that desktop does. But sometimes new features do get enabled on Android a little later. One example is Stylo, the new style engine, which isn't enabled on Android yet.

Note that these kinds of things are typically highly dependent on machine/browser configuration and workload. So that bug's title is overly broad, power consumption is fine for many (most?) people.

I've heard that Vim Vixen is decent, though I haven't used it myself.

https://addons.mozilla.org/en-US/firefox/addon/vim-vixen/