3 ms·

It’s more correct to say that it always prefers zero-cost abstractions. Defaulting to dynamic dispatch would go very much against this, even if in some cases it

by orf 4y ago

It’s more correct to say that it always prefers zero-cost abstractions. Defaulting to dynamic dispatch would go very much against this, even if in some cases it’s not a bad idea.

vlovich123 4y ago
Most of the code is cold. Spending compile time on that probably isn’t worth it. As such it’s not a zero cost abstraction (yes yes - it normally means runtime but still - developer time is important too and that’s where the trade off is). In most cases static dispatch is faster. In many cases dynamic dispatch can be just as fast (speculation by CPU negates the cost) and in some cases it can be faster (better code density). This 0-cost abstraction principle from c++ is actively harmful because there’s almost no such thing. Performance is such a subtle thing that what’s 0-cost in one scenario is a non 0 cost in others. Also spending compile time on the “dark matter” of code that’s rarely executed is probably not the best way to spend the developer time budget. I want CI to generate fully optimal code for production in release builds. For running tests in presubmit, I probably want a little bit less optimization. For local development I want it to be just fast enough that compile times are quick and I can iterate quickly (except for the cases I’m tuning performance in which case I have no choice but to spend max compilation time).
- jeffbee 4y ago
  I strongly doubt that endless fields of cold/dead code are zero-cost, without profile guidance and link-time optimization.
  - morelisp 4y ago
    One of my favorite go-to examples for this is "Producing Wrong Data Without Doing Anything Obviously Wrong!" 4.2 where they demonstrate a reproducible >30% performance difference just by "misaligning" stacks with an unused environment variable. That's in the context of unexpected measurement bias, but you won't convince me piles of cold code can't affect memory layout less than that.
  - vlovich123 4y ago
    I think we’re in agreement. Did you misread what I wrote or did I say/imply the opposite somehow?
- orf 4y ago
  I agree, but what you are asking is impossible in the general case. The compiler can’t know what is hot and cold without PGO, and doing dynamic dispatch in development to speed up compilation seems iffy. Surely a better approach is to use incremental compilation, and only do this expensive stuff potentially only once? However I do agree with your overall point - dev compilation in rust is too slow.

by orf 4y ago

It’s more correct to say that it always prefers zero-cost abstractions. Defaulting to dynamic dispatch would go very much against this, even if in some cases it’s not a bad idea.

vlovich123 4y ago

Most of the code is cold. Spending compile time on that probably isn’t worth it. As such it’s not a zero cost abstraction (yes yes - it normally means runtime but still - developer time is important too and that’s where the trade off is). In most cases static dispatch is faster. In many cases dynamic dispatch can be just as fast (speculation by CPU negates the cost) and in some cases it can be faster (better code density). This 0-cost abstraction principle from c++ is actively harmful because there’s almost no such thing. Performance is such a subtle thing that what’s 0-cost in one scenario is a non 0 cost in others. Also spending compile time on the “dark matter” of code that’s rarely executed is probably not the best way to spend the developer time budget. I want CI to generate fully optimal code for production in release builds. For running tests in presubmit, I probably want a little bit less optimization. For local development I want it to be just fast enough that compile times are quick and I can iterate quickly (except for the cases I’m tuning performance in which case I have no choice but to spend max compilation time).

jeffbee 4y ago
I strongly doubt that endless fields of cold/dead code are zero-cost, without profile guidance and link-time optimization.
- morelisp 4y ago
  One of my favorite go-to examples for this is "Producing Wrong Data Without Doing Anything Obviously Wrong!" 4.2 where they demonstrate a reproducible >30% performance difference just by "misaligning" stacks with an unused environment variable. That's in the context of unexpected measurement bias, but you won't convince me piles of cold code can't affect memory layout less than that.
- vlovich123 4y ago
  I think we’re in agreement. Did you misread what I wrote or did I say/imply the opposite somehow?
orf 4y ago
I agree, but what you are asking is impossible in the general case. The compiler can’t know what is hot and cold without PGO, and doing dynamic dispatch in development to speed up compilation seems iffy. Surely a better approach is to use incremental compilation, and only do this expensive stuff potentially only once? However I do agree with your overall point - dev compilation in rust is too slow.