4 ms·

A really dumb 1 AM question. If there is a lot of work thrown away because stuff is compiled even if not needed, would making every function generic and delayin

by dminik 2mo ago

A really dumb 1 AM question. If there is a lot of work thrown away because stuff is compiled even if not needed, would making every function generic and delaying compilation until instantiation help here? Note that it's not a serious suggestion, but I wonder what effect it would have on build times.

steveklabnik 2mo ago
I mean, the core thing is like, you have to have a compiler codebase (and language semantics) that's designed around being able to delay in the first place to be able to even try this, and once you've gotten that in place, well, it's not really about this specific idea anymore.
- tancop 2mo ago
  Would this work better in a language where generics are vtable based by default and only monomorphized as a form of LTO? If you have a Zig style machine IR where function calls are a "fake instruction" you can decide between direct and virtual call at final codegen time. That would mean generics in shared libraries are possible without hacks but you can always choose to statically link and monomorphize for speed. Libraries could even ship both the vtable based catch all code and specializations for common types as a fast path (but that would probably need a custom dynamic linker).
  - steveklabnik 2mo ago
    It really depends on a lot of things. This design is possible, yes, but it also means that you can't have some of the same features as Rust has. Rust's traits can be "non-dyn safe" (which used to be called "non-object safe"), because sometimes you cannot use them via a vtable, and must use them via monomorphization. So you can have languages that do things this way, but they make other tradeoffs (either performance ones or power ones, depending).
panstromek 2mo ago
Yes, and there is some compiler flag to do this, even though it's not 100% intended for this use (I think it's something like mir-inline-trheshold=0). There's also -Zhint-mostly-unused flag. The tradeoff is that these functions then have to be encoded in metadata for downstream crates, so it's not necessarily faster.
SkiFire13 2mo ago
The downside of this is that if two crates use the same function each of them will have to codegen it, duplicating the work needed for those functions. As always this could be avoided with some extra complexity, but that require lot of work and testing that hasn't been done. So for now this is useful only in crates that have a lot of unused functions, so even if one function is codegenned multiple times you still save time overall.

by dminik 2mo ago

steveklabnik 2mo ago

I mean, the core thing is like, you have to have a compiler codebase (and language semantics) that's designed around being able to delay in the first place to be able to even try this, and once you've gotten that in place, well, it's not really about this specific idea anymore.

tancop 2mo ago
Would this work better in a language where generics are vtable based by default and only monomorphized as a form of LTO? If you have a Zig style machine IR where function calls are a "fake instruction" you can decide between direct and virtual call at final codegen time. That would mean generics in shared libraries are possible without hacks but you can always choose to statically link and monomorphize for speed. Libraries could even ship both the vtable based catch all code and specializations for common types as a fast path (but that would probably need a custom dynamic linker).
- steveklabnik 2mo ago
  It really depends on a lot of things. This design is possible, yes, but it also means that you can't have some of the same features as Rust has. Rust's traits can be "non-dyn safe" (which used to be called "non-object safe"), because sometimes you cannot use them via a vtable, and must use them via monomorphization. So you can have languages that do things this way, but they make other tradeoffs (either performance ones or power ones, depending).

panstromek 2mo ago

Yes, and there is some compiler flag to do this, even though it's not 100% intended for this use (I think it's something like mir-inline-trheshold=0). There's also -Zhint-mostly-unused flag. The tradeoff is that these functions then have to be encoded in metadata for downstream crates, so it's not necessarily faster.

SkiFire13 2mo ago

The downside of this is that if two crates use the same function each of them will have to codegen it, duplicating the work needed for those functions. As always this could be avoided with some extra complexity, but that require lot of work and testing that hasn't been done. So for now this is useful only in crates that have a lot of unused functions, so even if one function is codegenned multiple times you still save time overall.