How hasn’t Google taken over and hired the Rust team? Weren’t they practically funding them by funding their parent, Mozilla?
Does Google care about Rust?
How to speed up the Rust compiler one last time
41–50 of 61 posts
Re: How to speed up the Rust compiler one last time
#42How hasn’t Google taken over and hired the Rust team? Weren’t they practically funding them by funding their parent, Mozilla?
Does Google care about Rust?
They use it on ChromeOS, Fuchsia, are thinking of introducing it on Android, and driving the conversations of using Linux kernel modules written in Rust.
Re: How to speed up the Rust compiler one last time
#43Re: How to speed up the Rust compiler one last time
#44Earlier quoted context omitted.
Rust's loss is Firefox's gain. I'm sorry to see you leave your Rust work, but I think Mozilla is right to have their best engineers focus on their core product. If we hope to see Firefox survive and remain relevant, then Mozilla really needed to refocus their energies onto it. Also, I assume someone of Nicholas's caliber has a great deal of agency over their own career path, so perhaps a return to Firefox is not enti…
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.
I'd like to see Mozilla focus on Firefox, so that there it remains a viable alternative to Blink-based browsers for as long as possible. I think that may yet become really important as the effects of the incredible dominance of Google in the WWW become more apparent.
I'd also like to see the Rust ecosystem prosper, but I guess others can take up the slack, it is gaining considerable momentum and quite a few places are looking into it, or using it already. If that isn't possible, is there much hope for it anyway?
Re: How to speed up the Rust compiler one last time
#45Earlier quoted context omitted.
Rust's loss is Firefox's gain. I'm sorry to see you leave your Rust work, but I think Mozilla is right to have their best engineers focus on their core product. If we hope to see Firefox survive and remain relevant, then Mozilla really needed to refocus their energies onto it. Also, I assume someone of Nicholas's caliber has a great deal of agency over their own career path, so perhaps a return to Firefox is not enti…
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 see Firefox remaining competitive with Chrome for long.
Re: How to speed up the Rust compiler one last time
#46> The improvements I did are mostly what could be described as “bottom-up micro-optimizations”. > I also did two larger “architectural” or “top-down” changes My summer intern started doing profiling work on compile times with clang: https://lists.llvm.org/pipermail/llvm-dev/2020-July/143012.h... Some things we found: * for a large C codebase like the Linux kernel, we're spending way more time in the front-end (clang)…
> for a large C codebase like the Linux kernel, we're spending way more time in the front-end (clang) than the backend (llvm). This was surprising based on rustc's experience with llvm.
rustc sends large, generally unoptimized chunks to llvm, compared to clang. In Rust, the translation unit is at the crate level, causing llvm to do more analysis. MIR is also still relatively new and I think there is still work to be done doing optimizations in it to get less data sent to llvm.
Re: How to speed up the Rust compiler one last time
#47> The improvements I did are mostly what could be described as “bottom-up micro-optimizations”. > I also did two larger “architectural” or “top-down” changes My summer intern started doing profiling work on compile times with clang: https://lists.llvm.org/pipermail/llvm-dev/2020-July/143012.h... Some things we found: * for a large C codebase like the Linux kernel, we're spending way more time in the front-end (clang)…
> for a large C codebase like the Linux kernel, we're spending way more time in the front-end (clang) than the backend (llvm). This was surprising based on rustc's experience with llvm. rustc sends large, generally unoptimized chunks to llvm, compared to clang. In Rust, the translation unit is at the crate level, causing llvm to do more analysis. MIR is also still relatively new and I think there is still work to be…
Clang doesn't do optimizations though. It generates llvm via a simple tree walk.
Re: How to speed up the Rust compiler one last time
#48Earlier quoted context omitted.
> for a large C codebase like the Linux kernel, we're spending way more time in the front-end (clang) than the backend (llvm). This was surprising based on rustc's experience with llvm. rustc sends large, generally unoptimized chunks to llvm, compared to clang. In Rust, the translation unit is at the crate level, causing llvm to do more analysis. MIR is also still relatively new and I think there is still work to be…
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 do per translation unit.
The consequence is that Rust spends more time on LLVM relatively speaking than C and C++.
The solution to this problem in Rust is naively simple: write smaller translation units.
Rust programmers just want to structure their code however their want, and still have good compile-times. Which is kind of the opposite of how C and C++ programmers typically structure their code in the largests projects, because they value faster compile-times over that kind of "ergonomics"/code organization.
Re: How to speed up the Rust compiler one last time
#49[deleted]
Re: How to speed up the Rust compiler one last time
#50Earlier quoted context omitted.
They use it on ChromeOS, Fuchsia, are thinking of introducing it on Android, and driving the conversations of using Linux kernel modules written in Rust.
Thanks, that is more involvement than I expected / knew about!
There's also experiments going on in Chrome, but nothing is for sure yet.