5 ms·

From an uninformed distance this looks a bit underwhelming: initial builds are slower, incremental builds are not _that_ much faster, and build outputs are no l

by bla2 10y ago

From an uninformed distance this looks a bit underwhelming: initial builds are slower, incremental builds are not _that_ much faster, and build outputs are no longer deterministic functions of just the build inputs (which is useful for example for distributed build systems).

pcwalton 10y ago
> incremental builds are not _that_ much faster Right now, they aren't. This will change as things improve. Remember, this is just the groundwork to allow incremental compilation to work at all. There are lots of places where the compiler now needs to be updated to use that framework. > build outputs are no longer deterministic functions of just the build inputs (which is useful for example for distributed build systems). You don't have to use incremental compilation if you care about this problem. But you will want to, because it isn't a problem in practice :) There is no reason why distributed build systems couldn't simply be made aware of incremental compilation.
mtanski 10y ago
The way Rust works today is that you compile a whole crate together (all the files). The side effect of that is that the compiler can optimize the whole create vs what's in one file. You get an effect that analogous to LTO (like in C/C++). Conversely, if you now go to incremental builds the opportunity for LTO style optimizations. Thus you end up with a worse runtime performance in incremental compilation. Caveats and fine details missing all over the place. More focused on the general point.
- ngrilly 10y ago
  > Thus you end up with a worse runtime performance in incremental compilation. Are you sure about this (in the current implementation)?
  - mtanski 10y ago
    The article it self says "[...] This is because incremental compilation splits the code into smaller optimization units than a regular compilation session, resulting in less time optimizing, but also in less efficient runtime code."
    - ngrilly 10y ago
      Thanks, you're right. I missed that.
jeffdavis 10y ago
Why does it become non-deterministic?
- taeric 10y ago
  I think the point is that the work done is not deterministic based on just the file inputs. Specifically, it has to pull in the external state of what the previous compile did. I would hope that the actual output is deterministic based on the inputs. That is, changing function C in a file that has A, B, and C should be the same as a fresh compile of the same file. Even if the actual work that is done is different.
  - pcwalton 10y ago
    It is.

by bla2 10y ago

pcwalton 10y ago

> incremental builds are not _that_ much faster Right now, they aren't. This will change as things improve. Remember, this is just the groundwork to allow incremental compilation to work at all. There are lots of places where the compiler now needs to be updated to use that framework. > build outputs are no longer deterministic functions of just the build inputs (which is useful for example for distributed build systems). You don't have to use incremental compilation if you care about this problem. But you will want to, because it isn't a problem in practice :) There is no reason why distributed build systems couldn't simply be made aware of incremental compilation.

mtanski 10y ago

The way Rust works today is that you compile a whole crate together (all the files). The side effect of that is that the compiler can optimize the whole create vs what's in one file. You get an effect that analogous to LTO (like in C/C++). Conversely, if you now go to incremental builds the opportunity for LTO style optimizations. Thus you end up with a worse runtime performance in incremental compilation. Caveats and fine details missing all over the place. More focused on the general point.

ngrilly 10y ago
> Thus you end up with a worse runtime performance in incremental compilation. Are you sure about this (in the current implementation)?
- mtanski 10y ago
  The article it self says "[...] This is because incremental compilation splits the code into smaller optimization units than a regular compilation session, resulting in less time optimizing, but also in less efficient runtime code."
  - ngrilly 10y ago
    Thanks, you're right. I missed that.

jeffdavis 10y ago

Why does it become non-deterministic?

taeric 10y ago
I think the point is that the work done is not deterministic based on just the file inputs. Specifically, it has to pull in the external state of what the previous compile did. I would hope that the actual output is deterministic based on the inputs. That is, changing function C in a file that has A, B, and C should be the same as a fresh compile of the same file. Even if the actual work that is done is different.
- pcwalton 10y ago
  It is.