3 ms·

I think there's a deeper problem in that the program can't easily tell the compiler what to do - we have pragmas and so on but they're crap. I remember a Jon C

by mhh__ 3y ago

I think there's a deeper problem in that the program can't easily tell the compiler what to do - we have pragmas and so on but they're crap. I remember a Jon Chesterfield pointing out to me that people mistake inlining to be solely about call-overhead and not specialization - you should be able to nudge the compiler which one you want if at all (the "don't do anything" case being more often desired than pass-authors might think, myself include)

masklinn 3y ago
> I remember a Jon Chesterfield pointing out to me that people mistake inlining to be solely about call-overhead and not specialization I recall multiple mentions over the years that inlining is the most important optimisation because of how many further optimisations it unlocks. I guess having some experience with Rust helps there, as the inlining itself is only a small fraction of all the work required to achieve "zero-cost abstraction". It’s very much load-bearing, but it’s the start if the work, not the end.
- mhh__ 3y ago
  Not particularly unique to rust
  - chlorion 3y ago
    I don't think many languages other than rust and c++ use monomorphization extremely heavily. Pretty much everything in rust is going to be using traits and c++ uses templates for most things as well. Every time you use a trait or a template, the code is expanded for the specific instance, and this gives a lot of opportunity for inlining stuff. A lot of other languages would not have the same opportunity to inline code when doing polymorphism stuff because they rely on dynamic dispatch or something similar that can't be inlined very well or at all. So I'm not disagreeing with you at all but I think rust and c++ get to inline stuff a little more aggressively, but this is just my theory and may be incorrect!
JonChesterfield 3y ago
> I think there's a deeper problem in that the program can't easily tell the compiler what to do Yes. We have divisions - application, language library, language implementation - which are broadly convenient but drop information on the boundaries. The implementation probably pattern matches on the library and the library will probably depends on quirks of the implementation (e.g. compiler intrinsics written for it), but the application is unlikely to be be able to extend the implementation. In cases where it can, there's a tendency to call it monkey patching and disapprove. > people mistake inlining to be solely about call-overhead and not specialization Yeah, that sounds like me. Inlining is an approximation to per-callsite specialisation which is easier to implement, where you pay for ease of compiler development with (machine) code duplication. attributes noinline and alwaysinline are relatively likely to exist, but specialise with respect to the third parameter is still on a wishlist. This is in the ballpark of compilers could be better, and should be better, than the current state of the art.

by mhh__ 3y ago

masklinn 3y ago

> I remember a Jon Chesterfield pointing out to me that people mistake inlining to be solely about call-overhead and not specialization I recall multiple mentions over the years that inlining is the most important optimisation because of how many further optimisations it unlocks. I guess having some experience with Rust helps there, as the inlining itself is only a small fraction of all the work required to achieve "zero-cost abstraction". It’s very much load-bearing, but it’s the start if the work, not the end.

mhh__ 3y ago
Not particularly unique to rust
- chlorion 3y ago
  I don't think many languages other than rust and c++ use monomorphization extremely heavily. Pretty much everything in rust is going to be using traits and c++ uses templates for most things as well. Every time you use a trait or a template, the code is expanded for the specific instance, and this gives a lot of opportunity for inlining stuff. A lot of other languages would not have the same opportunity to inline code when doing polymorphism stuff because they rely on dynamic dispatch or something similar that can't be inlined very well or at all. So I'm not disagreeing with you at all but I think rust and c++ get to inline stuff a little more aggressively, but this is just my theory and may be incorrect!

JonChesterfield 3y ago

> I think there's a deeper problem in that the program can't easily tell the compiler what to do Yes. We have divisions - application, language library, language implementation - which are broadly convenient but drop information on the boundaries. The implementation probably pattern matches on the library and the library will probably depends on quirks of the implementation (e.g. compiler intrinsics written for it), but the application is unlikely to be be able to extend the implementation. In cases where it can, there's a tendency to call it monkey patching and disapprove. > people mistake inlining to be solely about call-overhead and not specialization Yeah, that sounds like me. Inlining is an approximation to per-callsite specialisation which is easier to implement, where you pay for ease of compiler development with (machine) code duplication. attributes noinline and alwaysinline are relatively likely to exist, but specialise with respect to the third parameter is still on a wishlist. This is in the ballpark of compilers could be better, and should be better, than the current state of the art.