5 ms·

Based on how much ram that was using, it sounds like Rust is a language that couldn't have been practical until the past ~15 years or so. That is interesting to

Based on how much ram that was using, it sounds like Rust is a language that couldn't have been practical until the past ~15 years or so. That is interesting to me, given how long languages like ML have been around. Is there something genuinely computationally harder about compiling Rust?

killercup 8y ago
> Is there something genuinely computationally harder about compiling Rust? I'm not sure. Here's what I know: Rust has a complex type system. It also compiles whole packages (crates) at a time, and heavily uses monomorphization for generic code (that is probably less important for the type checking step but is quite heavy on the final compile-with-LLVM/link step). If it was necessary, I'm sure it'd be possible to trade in some memory usage for CPU time (IIRC, a lot of memory is used for caching/memoization). But aside from outliners like that "10GB less memory usage" fix, rustc doesn't use that much RAM.
civility 8y ago
I'm not a type theory guy, but it seems like you could rank Rust's type system somewhere in the realm of ML, Ocaml, Haskell, COQ, Agda, ATS, or something else. If Rust uses more memory and computation than those, then it's reasonable to assume there is another reason. I'm guessing you could have a very efficient implementation of Rust, but that it would be rewrite instead of an incremental fix. This statement is likely to be unpopular.
simias 8y ago
I don't know a lot about compilers but as far as I can tell from a compilation complexity standpoint Rust is C++ on steroids. Like C++ (and unlike higher level ML languages) Rust does most of the type system heavy lifting statically at compile-time. That results in potentially faster and simpler machinecode with fewer runtime dependencies but it also means that the compilation "tree" can become extremely complex since you need to resolve all types at compile-time and emit code for it. You can't just emit dynamic code that will dispatch at runtime. Heavily templated C++ code is notoriously slow to compile so it's no surprise that heavily genericized Rust code doesn't fare much better. On top of that Rust builds one crate at a time basically, it's not like C where you typically have plenty of smaller compilation units that are black-boxes to one-another. C++ has the same compilation model but as mentioned above templates need to be resolved completely at compile-time so all templated code ends up in headers and therefore in copy/pasted by the processor every compilation unit it's used in. And then after all that in Rust you have the borrow checker which probably ads a non-negligible runtime overhead. I agree that it's an interesting evolution as far as programming languages are concerned. I consider that Rust is overall superior to C but at the same time in the seventies nobody could have run a Rust compiler on anything more than a Hello World. Meanwhile I've just compiled (with optims) an auto-generated C file of about 20k lines almost instantly on my 2018 computer.
- pjmlp 8y ago
  You can get reasonably fast compile times in C++ with a mix of incremental compilation, incremental linking, binary libraries and if using clang or VC++, experimental modules support. Still slower than compiling Ada, Delphi, Eiffel, D code, though.
kibwen 8y ago
It's an interesting thing to consider, but note as well that much of what the compiler does is for the purpose of optimization (much of which is memory-intensive), for which the goal is parity with modern C and C++ compilers. And while it's true that C itself was designed to compile reasonably on machines with little memory, in practice modern C compilers go well above and beyond what machines of the 70s, 80s, or even 90s would find reasonable. Ultimately I think the answer would be a mix of "you could absolutely write a version of Rust that would compile reasonably on hardware from 1990", but also that the hardware limitations of that era would absolutely feed back into the design of the language in determining what features and implementation details would be feasible, which suggests that the language itself could very well look very different than it does today, even while maintaining the philosophy of no-GC memory-safety.

killercup 8y ago

> Is there something genuinely computationally harder about compiling Rust? I'm not sure. Here's what I know: Rust has a complex type system. It also compiles whole packages (crates) at a time, and heavily uses monomorphization for generic code (that is probably less important for the type checking step but is quite heavy on the final compile-with-LLVM/link step). If it was necessary, I'm sure it'd be possible to trade in some memory usage for CPU time (IIRC, a lot of memory is used for caching/memoization). But aside from outliners like that "10GB less memory usage" fix, rustc doesn't use that much RAM.

civility 8y ago

I'm not a type theory guy, but it seems like you could rank Rust's type system somewhere in the realm of ML, Ocaml, Haskell, COQ, Agda, ATS, or something else. If Rust uses more memory and computation than those, then it's reasonable to assume there is another reason. I'm guessing you could have a very efficient implementation of Rust, but that it would be rewrite instead of an incremental fix. This statement is likely to be unpopular.

simias 8y ago

I don't know a lot about compilers but as far as I can tell from a compilation complexity standpoint Rust is C++ on steroids. Like C++ (and unlike higher level ML languages) Rust does most of the type system heavy lifting statically at compile-time. That results in potentially faster and simpler machinecode with fewer runtime dependencies but it also means that the compilation "tree" can become extremely complex since you need to resolve all types at compile-time and emit code for it. You can't just emit dynamic code that will dispatch at runtime. Heavily templated C++ code is notoriously slow to compile so it's no surprise that heavily genericized Rust code doesn't fare much better. On top of that Rust builds one crate at a time basically, it's not like C where you typically have plenty of smaller compilation units that are black-boxes to one-another. C++ has the same compilation model but as mentioned above templates need to be resolved completely at compile-time so all templated code ends up in headers and therefore in copy/pasted by the processor every compilation unit it's used in. And then after all that in Rust you have the borrow checker which probably ads a non-negligible runtime overhead. I agree that it's an interesting evolution as far as programming languages are concerned. I consider that Rust is overall superior to C but at the same time in the seventies nobody could have run a Rust compiler on anything more than a Hello World. Meanwhile I've just compiled (with optims) an auto-generated C file of about 20k lines almost instantly on my 2018 computer.

pjmlp 8y ago
You can get reasonably fast compile times in C++ with a mix of incremental compilation, incremental linking, binary libraries and if using clang or VC++, experimental modules support. Still slower than compiling Ada, Delphi, Eiffel, D code, though.

kibwen 8y ago

It's an interesting thing to consider, but note as well that much of what the compiler does is for the purpose of optimization (much of which is memory-intensive), for which the goal is parity with modern C and C++ compilers. And while it's true that C itself was designed to compile reasonably on machines with little memory, in practice modern C compilers go well above and beyond what machines of the 70s, 80s, or even 90s would find reasonable. Ultimately I think the answer would be a mix of "you could absolutely write a version of Rust that would compile reasonably on hardware from 1990", but also that the hardware limitations of that era would absolutely feed back into the design of the language in determining what features and implementation details would be feasible, which suggests that the language itself could very well look very different than it does today, even while maintaining the philosophy of no-GC memory-safety.