5 ms·

Rust could also have shorter compile times, if it gave up on a lot of the optimizations and features it currently does.

• eptcyka 4y ago
  A massive source of compilation pain is that Rust just generally generates a lot of code - it always prefers specialization over dynamic dispatch unless the source specificies dynamic dispatch. Couple this with a culture of believing dynamic dispatch is always worse and lots of codegen for generics and you get one hell of a task for your linter. I wouldn't call this an optimization, but rather an almost cultural design decision.
  • 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.
  • pjmlp 4y ago
    Meanwhile OCaml and Haskell provide interpreters and REPL to ease the whole development experience. Nothing prevents Rust of doing the same, other than resources.
    • LoganDark 4y ago
      evcxr does provide a hacky Rust REPL implementation: https://github.com/evcxr/evcxr https://github.com/evcxr/evcxr -Emily
      • eptcyka 4y ago
        Yes, but said REPL just wraps user entered expressions itno a function body and then compiles them to a shared object via cargo - thus the language is interpreted via the slow compiler anyway.
        • LoganDark 4y ago
          I said hacky, and also parent was talking about the lack of a REPL, not the speed of one. -Emily
  • foldr 4y ago
    >and you get one hell of a task for your linter Did you mean 'linker' here?
    • eptcyka 4y ago
      Yes.