4 ms·

For the vast majority of programs most time is spent in code generation/optimization. Rusts static analysis is not why compilation is slow.

by Thiez 4y ago

zarzavat 4y ago
Optimisation happens in release builds. I assume when people talk about compilation speed they mean debug builds because those are the ones you have to wait for. For me the biggest hurdle to adopting Rust is that rust-analyser turns my laptop's fans up to 11. I don't know whose problem that is, but it doesn't happen with other languages, and my black box impression of rust's compilation infrastructure is that it's fucked up.
josephg 4y ago
Yeah … I’ve done a lot of optimization work. (I love that sort of thing). I have an instinct that there’s at least an order of magnitude compilation performance gain possible with a different architecture for the compiler. Especially if you didn’t bother implementing a lot of llvm’s optimizations. It’s just tricky because writing a new rust compiler is a monster amount of work because of how complex Rust is. And rearchitecting the existing compiler would also be a massive undertaking because there’s so much existing code, and it’s spread over rustc (written in rust) and llvm (in C++). A faster compiler probably wouldn’t bother with all of llvm’s intermediate representations. Refactoring across a code boundary that spans two languages (and two projects) sounds utterly exhausting.
- thefaux 4y ago
  It seems obvious to me that eventually someone is going to write a compiler for a language that delivers on rust's main value propositions (fast native code/memory safety/data race protection) but that compiles at least 10x faster than rust for most problems. Initially the generated code might be somewhat slower than rust on average, but I think developers will find they would happily trade some runtime perf for such a dramatic compile time improvement. The runtime performance gap will also narrow over time and eventually probably even supplant rust for most common problems. Rust itself is already too complex and weighed down by many competing interests that will prevent it from being the best possible version of itself. But it also has many self owns such as objectively bad syntactic decisions (like angle brackets for generics) that were made to appease intransigent c programmers.
  - josephg 4y ago
    Yeah; a simpler language would also be easier to learn. Rust is experimenting with an awful lot of new ideas. I imagine rust's successor (whenever that happens) will take the best ideas from rust - including the best design for a borrow checker - and build a much simpler language around that. Rust is the first language in its category. It won't be the best language we ever make in that category.

For the vast majority of programs most time is spent in code generation/optimization. Rusts static analysis is not why compilation is slow.

by Thiez 4y ago

For the vast majority of programs most time is spent in code generation/optimization. Rusts static analysis is not why compilation is slow.

zarzavat 4y ago

Optimisation happens in release builds. I assume when people talk about compilation speed they mean debug builds because those are the ones you have to wait for. For me the biggest hurdle to adopting Rust is that rust-analyser turns my laptop's fans up to 11. I don't know whose problem that is, but it doesn't happen with other languages, and my black box impression of rust's compilation infrastructure is that it's fucked up.

josephg 4y ago

Yeah … I’ve done a lot of optimization work. (I love that sort of thing). I have an instinct that there’s at least an order of magnitude compilation performance gain possible with a different architecture for the compiler. Especially if you didn’t bother implementing a lot of llvm’s optimizations. It’s just tricky because writing a new rust compiler is a monster amount of work because of how complex Rust is. And rearchitecting the existing compiler would also be a massive undertaking because there’s so much existing code, and it’s spread over rustc (written in rust) and llvm (in C++). A faster compiler probably wouldn’t bother with all of llvm’s intermediate representations. Refactoring across a code boundary that spans two languages (and two projects) sounds utterly exhausting.

thefaux 4y ago
It seems obvious to me that eventually someone is going to write a compiler for a language that delivers on rust's main value propositions (fast native code/memory safety/data race protection) but that compiles at least 10x faster than rust for most problems. Initially the generated code might be somewhat slower than rust on average, but I think developers will find they would happily trade some runtime perf for such a dramatic compile time improvement. The runtime performance gap will also narrow over time and eventually probably even supplant rust for most common problems. Rust itself is already too complex and weighed down by many competing interests that will prevent it from being the best possible version of itself. But it also has many self owns such as objectively bad syntactic decisions (like angle brackets for generics) that were made to appease intransigent c programmers.
- josephg 4y ago
  Yeah; a simpler language would also be easier to learn. Rust is experimenting with an awful lot of new ideas. I imagine rust's successor (whenever that happens) will take the best ideas from rust - including the best design for a borrow checker - and build a much simpler language around that. Rust is the first language in its category. It won't be the best language we ever make in that category.