3 ms·

Here is a good article on how important Servo was to the early development of Rust and the feedback loop between the two [1]. I find it interesting to see how

by jmyeet 3y ago

Here is a good article on how important Servo was to the early development of Rust and the feedback loop between the two [1]. I find it interesting to see how Rust chose run-time over compile-time. Some of this is completely understandable (eg the whole borrow-checking mechanism that is so valuable). Generally though, I've found you want to favor compile-time, particularly incremental compile-time. It's better to get something to work first and then optimize performance later than the other way around. [1]: https://pingcap.medium.com/the-rust-compilation-model-calamity-1a8ce781cf6c https://pingcap.medium.com/the-rust-compilation-model-calami...

ReactiveJelly 3y ago
OTOH, dev machines are usually beefier and fewer in number than prod machines. So if you can give yourself head room to make prod _really_ fast, in a few years the dev systems may double in power anyway. Incremental compiles are a common source of bugs, right? I find it's easy to do something from scratch (like imgui painting the whole window every frame) and hard to optimize it not to (like damage in GUIs)
- cookieperson 3y ago
  Thread ripper with nvme drives for rust development make compile times a giggle. Not sure what you mean by bugs due to incremental compilation? I've never seen it happen anyways.
  - kbrosnan 3y ago
    Happens with some frequency with building Gecko. You can see documented instances of it for the CLOBBER file. It allows the person building to optionally have the build system force a clean rebuild. https://hg.mozilla.org/mozilla-central/log/tip/CLOBBER https://hg.mozilla.org/mozilla-central/log/tip/CLOBBER https://firefox-source-docs.mozilla.org/build/buildsystem/mozconfigs.html#mk-add-options https://firefox-source-docs.mozilla.org/build/buildsystem/mo...
jeltz 3y ago
> It's better to get something to work first and then optimize performance later than the other way around. As far as I gather that is one of the issues why Rust is slow to compile. Fast compilers were usually built with performance in mind from the very start while rustc was first made work and then optimized.
est31 3y ago
The main competitor of Rust for writing browsers is C++, and its compilers don't have in-unit incremental compilation. So that's why Rust didn't start out with incremental compilation, but it was added later on, so now you do have it (although it could be improved in many ways).
cookieperson 3y ago
There's a balance between the two and that balance shifts based on product/project requirements. I can't imagine anyone writing a slow browser engine and being like "yea but we will make it fast later!", Screen tearing, 5second plain text page loads, etc don't make for compelling demos. Similarly for an OS or a database you can't have it be below some reasonable performance threshold even in prototyping. Otherwise you aren't even solving the problems, the apparent remaining 10% of the work basically demands a complete rewrite plus many new feature editions - ie youve done nothing.
- easton 3y ago
  > I can't imagine anyone writing a slow browser engine and being like "yea but we will make it fast later!" Funny, that’s the exact opinion of the people building Ladybird for SerenityOS. They are of course doing it for fun, and it doesn’t take five seconds to show text.
  - cookieperson 3y ago
    I wish them every bit of success but I'd worry about their OS if it was built under the same principles.
avgcorrection 3y ago
> It's better to get something to work first and then optimize performance later than the other way around. That’s what they did by using LLVM instead of making their own compiler backend. The compiler could have apparently (according to what have been said) been faster, earlier, if they didn’t have to go through LLVM. But yeah, you’re right about their priorities: minimizing runtime has always been a high priority while designing the language, while designing for fast compiles has not. At least according to my view from the peanut gallery I don’t know anything about compilers, but it would have been interesting to see if a language like Rust would look different today in this regard if they focused on incremental compilation (instead of batch) from day one.
phkahler 3y ago
Having the ability to turn off expensive compiler options is nice. For Solvespace (C++), turning on LTO make compilation about 6x longer for maybe 15 percent runtime performance. I do development without LTO and let releases get LTO. The borrow checker in Rust might be to important to turn off even sometimes.
- xavxav 3y ago
  > The borrow checker in Rust might be to important to turn off even sometimes. Variations of this point come up often, that the main reason rust compile time is slow is typechecking or borrowchecking, but that’s not true, while those operations are expensive, it’s monomorphization (and llvm) that are the main drivers of compile time currently. Building a compiler on top of llvm is unfortunately going to be sluggish for feedback loops , regardless of your type system. Also, unlike LTO, borrow checking is not just an optimization, turning it off would be like allowing you to add arrays and booleans together: meaningless and wrong. Anyways, you wouldn’t save more than ~10% time. Apart from the rant above, I do agree that having the ability to tune optimization levels for development vs prod is good, I would like it if it were easier to do stuff like PGO or other stupidly expensive optimizations for releases.
pkolaczk 3y ago
> It's better to get something to work first and then optimize performance later than the other way around. I see it repeated a lot without any justification. And I observe that in practice a reverse statement is true. If you make something work first without looking at its performance from the very first phase of development then you will soon find yourself in a place where the only way to improve performance is doing a full rewrite. It is way easier to add more features to a program that has good performance-oriented design than to improve performance of a program that has accumulated thousands of features. And particularly programs like web browsers, compilers and database engines don't have mythical "95% of CPU power is taken by 5% of code" profile. Their profiles are flat, and when you improve perf by 5% you're already blogging about it.

by jmyeet 3y ago

ReactiveJelly 3y ago

OTOH, dev machines are usually beefier and fewer in number than prod machines. So if you can give yourself head room to make prod _really_ fast, in a few years the dev systems may double in power anyway. Incremental compiles are a common source of bugs, right? I find it's easy to do something from scratch (like imgui painting the whole window every frame) and hard to optimize it not to (like damage in GUIs)

cookieperson 3y ago
Thread ripper with nvme drives for rust development make compile times a giggle. Not sure what you mean by bugs due to incremental compilation? I've never seen it happen anyways.
- kbrosnan 3y ago
  Happens with some frequency with building Gecko. You can see documented instances of it for the CLOBBER file. It allows the person building to optionally have the build system force a clean rebuild. https://hg.mozilla.org/mozilla-central/log/tip/CLOBBER https://hg.mozilla.org/mozilla-central/log/tip/CLOBBER https://firefox-source-docs.mozilla.org/build/buildsystem/mozconfigs.html#mk-add-options https://firefox-source-docs.mozilla.org/build/buildsystem/mo...

jeltz 3y ago

> It's better to get something to work first and then optimize performance later than the other way around. As far as I gather that is one of the issues why Rust is slow to compile. Fast compilers were usually built with performance in mind from the very start while rustc was first made work and then optimized.

est31 3y ago

The main competitor of Rust for writing browsers is C++, and its compilers don't have in-unit incremental compilation. So that's why Rust didn't start out with incremental compilation, but it was added later on, so now you do have it (although it could be improved in many ways).

cookieperson 3y ago

There's a balance between the two and that balance shifts based on product/project requirements. I can't imagine anyone writing a slow browser engine and being like "yea but we will make it fast later!", Screen tearing, 5second plain text page loads, etc don't make for compelling demos. Similarly for an OS or a database you can't have it be below some reasonable performance threshold even in prototyping. Otherwise you aren't even solving the problems, the apparent remaining 10% of the work basically demands a complete rewrite plus many new feature editions - ie youve done nothing.

easton 3y ago
> I can't imagine anyone writing a slow browser engine and being like "yea but we will make it fast later!" Funny, that’s the exact opinion of the people building Ladybird for SerenityOS. They are of course doing it for fun, and it doesn’t take five seconds to show text.
- cookieperson 3y ago
  I wish them every bit of success but I'd worry about their OS if it was built under the same principles.

avgcorrection 3y ago

> It's better to get something to work first and then optimize performance later than the other way around. That’s what they did by using LLVM instead of making their own compiler backend. The compiler could have apparently (according to what have been said) been faster, earlier, if they didn’t have to go through LLVM. But yeah, you’re right about their priorities: minimizing runtime has always been a high priority while designing the language, while designing for fast compiles has not. At least according to my view from the peanut gallery I don’t know anything about compilers, but it would have been interesting to see if a language like Rust would look different today in this regard if they focused on incremental compilation (instead of batch) from day one.

phkahler 3y ago

Having the ability to turn off expensive compiler options is nice. For Solvespace (C++), turning on LTO make compilation about 6x longer for maybe 15 percent runtime performance. I do development without LTO and let releases get LTO. The borrow checker in Rust might be to important to turn off even sometimes.

xavxav 3y ago
> The borrow checker in Rust might be to important to turn off even sometimes. Variations of this point come up often, that the main reason rust compile time is slow is typechecking or borrowchecking, but that’s not true, while those operations are expensive, it’s monomorphization (and llvm) that are the main drivers of compile time currently. Building a compiler on top of llvm is unfortunately going to be sluggish for feedback loops , regardless of your type system. Also, unlike LTO, borrow checking is not just an optimization, turning it off would be like allowing you to add arrays and booleans together: meaningless and wrong. Anyways, you wouldn’t save more than ~10% time. Apart from the rant above, I do agree that having the ability to tune optimization levels for development vs prod is good, I would like it if it were easier to do stuff like PGO or other stupidly expensive optimizations for releases.

pkolaczk 3y ago

> It's better to get something to work first and then optimize performance later than the other way around. I see it repeated a lot without any justification. And I observe that in practice a reverse statement is true. If you make something work first without looking at its performance from the very first phase of development then you will soon find yourself in a place where the only way to improve performance is doing a full rewrite. It is way easier to add more features to a program that has good performance-oriented design than to improve performance of a program that has accumulated thousands of features. And particularly programs like web browsers, compilers and database engines don't have mythical "95% of CPU power is taken by 5% of code" profile. Their profiles are flat, and when you improve perf by 5% you're already blogging about it.