4 ms·

As a point of reference "warmed up" compilation for me still takes ~1minute. Bearable for general work, horrible for quick tweaks or UI-related work.

infogulch 8y ago
I've heard that long warm compilation times can be mitigated by breaking up code into separate modules so it doesn't recompile e.g. the actor system every time you adjust a layout. Basically caching works best on the module boundary. Is this something you've explored?
- z0mbie42 8y ago
  +1 I've splitted a 20k+LOC Rust project into multiple crates and compilation time improved a lot (still slow compared to other languages) but it's now manageable.
- theanzelm 8y ago
  Yes, I factored out quite a bit of generic parts of the engine into libraries and took some steps to cut down on number of generics being instanced (which was one of the main drivers of compile time). Now I'm left with pretty much the game core, which is highly interdependent and thus nearly impossible to break up into crates (they can't mutually depend on each other). And it's still kinda slow.
jeanmichelx 8y ago
I'm so jealous of software development tools. Elaborating the hardware (systemverilog) I'm working on (about a year of work from scratch, nothing fancy) takes 8 minutes.
- jtms 8y ago
  Wow, I get frustrated and feel unproductive if my feedback loop is longer than 2-5 SECONDS. This must require a seriously different approach to trial and error exploration
  - dimfeld 8y ago
    A lot of that is done in a simulator on the computer, which usually builds very quick once you get the environment and simulation scripts written. The full build to a bit file that can be loaded into hardware is an NP-hard optimization problem, so as your design approaches the limits of either the desired clock speed or the amount of space in the chip, it can become very slow.
    - jeanmichelx 8y ago
      I wish. This figure is reloading the formal tool after a one line change in the RTL. Placing (not routing!) takes around 24 hours since we need to run in a larger environment than just the block level to get realistic timing reports

infogulch 8y ago

I've heard that long warm compilation times can be mitigated by breaking up code into separate modules so it doesn't recompile e.g. the actor system every time you adjust a layout. Basically caching works best on the module boundary. Is this something you've explored?

z0mbie42 8y ago
+1 I've splitted a 20k+LOC Rust project into multiple crates and compilation time improved a lot (still slow compared to other languages) but it's now manageable.
theanzelm 8y ago
Yes, I factored out quite a bit of generic parts of the engine into libraries and took some steps to cut down on number of generics being instanced (which was one of the main drivers of compile time). Now I'm left with pretty much the game core, which is highly interdependent and thus nearly impossible to break up into crates (they can't mutually depend on each other). And it's still kinda slow.

jeanmichelx 8y ago

I'm so jealous of software development tools. Elaborating the hardware (systemverilog) I'm working on (about a year of work from scratch, nothing fancy) takes 8 minutes.

jtms 8y ago
Wow, I get frustrated and feel unproductive if my feedback loop is longer than 2-5 SECONDS. This must require a seriously different approach to trial and error exploration
- dimfeld 8y ago
  A lot of that is done in a simulator on the computer, which usually builds very quick once you get the environment and simulation scripts written. The full build to a bit file that can be loaded into hardware is an NP-hard optimization problem, so as your design approaches the limits of either the desired clock speed or the amount of space in the chip, it can become very slow.
  - jeanmichelx 8y ago
    I wish. This figure is reloading the formal tool after a one line change in the RTL. Placing (not routing!) takes around 24 hours since we need to run in a larger environment than just the block level to get realistic timing reports