← Back to context

Comment by torginus

6 months ago

It's unfixable in the sense that the problem isn't with how fast the compiler is, it's that you give it a ton of extra work. You could try to convince the library devs to use more dyn, but it'd require a culture shift. I don't think the compiler going behind the users back and second guessing whether to use static dispatch or inlining is something a low-level language should do. Java, sure.

In fact I define a systems language as something that allows the dev to describe intended machine behavior more conveniently, as opposed to a higher-level language, where the user describes desired behavior and the compiler figures out the rest.

It's not all inherent language-semantics issues like monomorphization. rustc currently generates LLVM IR in a fairly naive/brute-force-ish way. The resulting machine code is as good as you'd get with more carefully generated LLVM IR, because LLVM is very good at optimizing, but it takes longer to get there. Some of the work that LLVM currently does could instead be done in earlier compilation passes, and they could do it faster by exploiting relevant context that LLVM doesn't have. But again, this'd require significant architectural changes, which is why it hasn't already happened.

Also it could maybe make sense for debug builds to let the compiler choose whether to use static or dynamic dispatch, with an attribute to force static dispatch in those cases where it's absolutely required. (I vaguely recall some kind of attempt to do that, that got stuck because it had trouble dealing with associated constants or something like that. But I can't find it now.)