4 ms·

Any reasons why it could not be as fast as the Go compiler? Maybe GC and the borrow checker could slow down a bit, but apart from that?

bonzini 4y ago
The Go compiler is barely an optimizing compiler. Rust needs massive amounts of inlining to avoid the performance cost of abstractions, and after inlining the code needs to be cleaned up. In this respect it isn't unlike C++.
- sk0g 4y ago
  Does anyone particularly care if development builds inline much? If you can get Go-like compile speeds for development iteration, and the current ones for release, it would be the best of both worlds for me.
  - loeg 4y ago
    In fact, that's exactly why cargo's default for dev builds is -O0: https://doc.rust-lang.org/book/ch14-01-release-profiles.html#:~:text=The%20default%20opt%2Dlevel%20for%20dev%20is%20therefore%200 https://doc.rust-lang.org/book/ch14-01-release-profiles.html...
    - gnuvince 4y ago
      The Rust dev builds are very often (1) slower to build than the equivalent Go program, (2) slower to run than the equivalent Go program. Rust programs really need the `--release` flag to shine—and in some cases, the dev builds of a program cannot be meaningfully used, even for local testing, since they're so slow.
      - loeg 4y ago
        > The Rust dev builds are very often (1) slower to build than the equivalent Go program, (2) slower to run than the equivalent Go program. It could definitely be better, sure.
- cxr 4y ago
  The reference compiler needs a lot of time to make the resulting binary fast, okay fine. But where's the rust-lang.org group's fork of the golang.org group's `go build` tool modified to accept source files written in the Rust language as input and that (quickly) outputs a binary with a performance profile no faster or slower an equivalent program written in Golang? ~15 years of compiler research is too long and comparisons between the two languages (however fair or un-) are too numerous for there to be any excuse for this not to exist, and yet
  - deleted 4y ago
    [deleted]
- deleted 4y ago
  [deleted]
- WinstonSmith84 4y ago
  Go production build is quite small as much as I can say, but I don't understand much at compilers so I will not discuss this. I've a lot of hands on experience with both Go and Rust, and on mid size project, an incremental production build in Go will take less than 1 second, whereas a development (non release) incremental build in Rust will take 10/15s (something as simple as a `println!` update). It's subjective, but it's not much exaggerated to tell that a Go prod build is >10x faster than a Rust dev build So, I get your point for production build, that it needs some special optimization that maybe doesn't happen for Go, but I don't need any optimization when doing Dev testing and this could well remain totally unoptimized. Then I would at least expect for an "un-optimized" dev Rust build to be roughly as fast as a production Go build. At least not >10x slower
alkonaut 4y ago
It could, if it stopped doing a lot of things it does which the Go compiler doesn’t. Or of course if the Go compiler started doing them so it became a lot slower. One example is “full”monomorphization of generics. But there are lots of such examples. Usually though I find the Rust compilation speed a non issue, so long as “cargo check” and the IDE analysis is great, I just rarely compile to begin with.
loeg 4y ago
The borrow checker is not an insignificant cost. Maybe you could imagine an incremental compilation mode that just didn't evaluate the borrow checker for faster development. As other commenters have noted, the Go backend is extremely simplistic ("barely an optimizing compiler"). Rustc is also a lot faster in -O0 mode than any optimizing mode. But -O0 is somewhat dumber than Go's compiler. You could imagine an -O1 (or -O0.5) with compilation time vs performance tradeoff similar to Go, but it isn't there today. There's also an attempt to adopt a more simplistic backend (cranelift) into Rustc to improve codegen performance, but so far it hasn't provided much speedup.
- Thiez 4y ago
  Apart from rare pathological cases borrow checking is not a significant part of compilation time. Disabling it would be very detrimental for little gain.
  - sowbug 4y ago
    As an end user of Rust, I think the borrow checker seems slow because it's one of the last phases to run during vscode's real-time feedback. More than once I've been in the midst of a long refactoring session, and finally fix what I think is the very last syntax problem. But then the borrow checker finally gets to run, and then I learn about a whole new set of problems.
  - loeg 4y ago
    Apologies, I was under the impression it was a significant cost. Do you have any good analysis of where Rust compiler time goes you could link to?
    - Thiez 4y ago
      Here is a nice article that goes into detail: https://fasterthanli.me/articles/why-is-my-rust-build-so-slow https://fasterthanli.me/articles/why-is-my-rust-build-so-slo... Here is an older article that compares compilation times between multiple different libraries, where one of them does spend a significant (and majority of the) time borrow checking: https://wiki.alopex.li/WhereRustcSpendsItsTime https://wiki.alopex.li/WhereRustcSpendsItsTime

bonzini 4y ago

The Go compiler is barely an optimizing compiler. Rust needs massive amounts of inlining to avoid the performance cost of abstractions, and after inlining the code needs to be cleaned up. In this respect it isn't unlike C++.

sk0g 4y ago
Does anyone particularly care if development builds inline much? If you can get Go-like compile speeds for development iteration, and the current ones for release, it would be the best of both worlds for me.
- loeg 4y ago
  In fact, that's exactly why cargo's default for dev builds is -O0: https://doc.rust-lang.org/book/ch14-01-release-profiles.html#:~:text=The%20default%20opt%2Dlevel%20for%20dev%20is%20therefore%200 https://doc.rust-lang.org/book/ch14-01-release-profiles.html...
  - gnuvince 4y ago
    The Rust dev builds are very often (1) slower to build than the equivalent Go program, (2) slower to run than the equivalent Go program. Rust programs really need the `--release` flag to shine—and in some cases, the dev builds of a program cannot be meaningfully used, even for local testing, since they're so slow.
    - loeg 4y ago
      > The Rust dev builds are very often (1) slower to build than the equivalent Go program, (2) slower to run than the equivalent Go program. It could definitely be better, sure.
cxr 4y ago
The reference compiler needs a lot of time to make the resulting binary fast, okay fine. But where's the rust-lang.org group's fork of the golang.org group's `go build` tool modified to accept source files written in the Rust language as input and that (quickly) outputs a binary with a performance profile no faster or slower an equivalent program written in Golang? ~15 years of compiler research is too long and comparisons between the two languages (however fair or un-) are too numerous for there to be any excuse for this not to exist, and yet
- deleted 4y ago
  [deleted]
deleted 4y ago
[deleted]
WinstonSmith84 4y ago
Go production build is quite small as much as I can say, but I don't understand much at compilers so I will not discuss this. I've a lot of hands on experience with both Go and Rust, and on mid size project, an incremental production build in Go will take less than 1 second, whereas a development (non release) incremental build in Rust will take 10/15s (something as simple as a `println!` update). It's subjective, but it's not much exaggerated to tell that a Go prod build is >10x faster than a Rust dev build So, I get your point for production build, that it needs some special optimization that maybe doesn't happen for Go, but I don't need any optimization when doing Dev testing and this could well remain totally unoptimized. Then I would at least expect for an "un-optimized" dev Rust build to be roughly as fast as a production Go build. At least not >10x slower

alkonaut 4y ago

It could, if it stopped doing a lot of things it does which the Go compiler doesn’t. Or of course if the Go compiler started doing them so it became a lot slower. One example is “full”monomorphization of generics. But there are lots of such examples. Usually though I find the Rust compilation speed a non issue, so long as “cargo check” and the IDE analysis is great, I just rarely compile to begin with.

loeg 4y ago

The borrow checker is not an insignificant cost. Maybe you could imagine an incremental compilation mode that just didn't evaluate the borrow checker for faster development. As other commenters have noted, the Go backend is extremely simplistic ("barely an optimizing compiler"). Rustc is also a lot faster in -O0 mode than any optimizing mode. But -O0 is somewhat dumber than Go's compiler. You could imagine an -O1 (or -O0.5) with compilation time vs performance tradeoff similar to Go, but it isn't there today. There's also an attempt to adopt a more simplistic backend (cranelift) into Rustc to improve codegen performance, but so far it hasn't provided much speedup.

Thiez 4y ago
Apart from rare pathological cases borrow checking is not a significant part of compilation time. Disabling it would be very detrimental for little gain.
- sowbug 4y ago
  As an end user of Rust, I think the borrow checker seems slow because it's one of the last phases to run during vscode's real-time feedback. More than once I've been in the midst of a long refactoring session, and finally fix what I think is the very last syntax problem. But then the borrow checker finally gets to run, and then I learn about a whole new set of problems.
- loeg 4y ago
  Apologies, I was under the impression it was a significant cost. Do you have any good analysis of where Rust compiler time goes you could link to?
  - Thiez 4y ago
    Here is a nice article that goes into detail: https://fasterthanli.me/articles/why-is-my-rust-build-so-slow https://fasterthanli.me/articles/why-is-my-rust-build-so-slo... Here is an older article that compares compilation times between multiple different libraries, where one of them does spend a significant (and majority of the) time borrow checking: https://wiki.alopex.li/WhereRustcSpendsItsTime https://wiki.alopex.li/WhereRustcSpendsItsTime