3 ms·

That's true but devirtualization optimizations tend to be pretty brittle and it's very easy to fall of the optimizer's blessed path and end up back to doing to

That's true but devirtualization optimizations tend to be pretty brittle and it's very easy to fall of the optimizer's blessed path and end up back to doing to a virtual call without realizing it. Worse, once the devirtualization optimization has failed, any further optimizations you would get from inlining the call will also fail. If you're programming in C++, you probably do care about this level of performance, and in that case, it's nice to program in a style that guarantees it instead of hoping for a sufficiently smart compiler.

CyberRabbi 4y ago
> If you're programming in C++, you probably do care about this level of performance, and in that case, it's nice to program in a style that guarantees it instead of hoping for a sufficiently smart compiler. Neither implementation guarantees any particular sequence of assembly instructions. Both require hoping that a sufficiently smart compiler will compile it to a sufficiently optimal sequence of instructions.
- munificent 4y ago
  Yes, in principle a compiler is free to generate arbitrarily horrendous code regardless of what you ask it to do. In practice, non-virtual function calls are reliably compiled to fairly efficient code while virtual calls are much less reliable.
  - CyberRabbi 4y ago
    > In practice, non-virtual function calls are reliably compiled to fairly efficient code while virtual calls are much less reliable. Like I said, this echoes the conventional wisdom that most C++ developers seem to retain. The compiler landscape has changed since that wisdom was formed, since the advent of LTO and devirtualization optimizations.
    - asdfws 4y ago
      So has programmer methodology. Throwing virtual calls everywhere is a relic of the past from the era of OOP fetishism. If you actually have statically verifiable leafs for virtual calls then you didn't even need a virtual call to begin with. It's code slop.
    - i-use-nixos-btw 4y ago
      Strongly agree on the philosophy - but alas my experience with this specific case has not been great. I’ve seen it simplify patches of code here and there, and that does apply to the trivial examples given in the post this topic links to - a function call involving a known child class. But add some basic real-world complexity and it quickly gets too complex for the optimiser to prove that it knows for sure what child class it is dealing with.
kaba0 4y ago
Unless you are in a hot loop (where you may not use virtual methods to begin with), I don’t think that performance difference is significant. Virtual calls have a slight overhead, but far from serious, and similarly not inlining something that you call only a single time for example is not the end of the world.
- munificent 4y ago
  The problem with not inlining is less with the overhead of the function call itself, and more the loss of further optimization opportunities. Consider this (trivial) example: main() { int x = foo() + 3; } int foo() { return 5; } Without inlining you have both the overhead of the call and the arithmetic addition. If you can inline the call then you get: main() { int x = 5 + 3; } But more importantly, the optimizer can now also eliminate the addition too: main() { int x = 8; } This is obviously a trivial example, but in real-world code, the optimization options opened up after inlining are important.

CyberRabbi 4y ago

> If you're programming in C++, you probably do care about this level of performance, and in that case, it's nice to program in a style that guarantees it instead of hoping for a sufficiently smart compiler. Neither implementation guarantees any particular sequence of assembly instructions. Both require hoping that a sufficiently smart compiler will compile it to a sufficiently optimal sequence of instructions.

munificent 4y ago
Yes, in principle a compiler is free to generate arbitrarily horrendous code regardless of what you ask it to do. In practice, non-virtual function calls are reliably compiled to fairly efficient code while virtual calls are much less reliable.
- CyberRabbi 4y ago
  > In practice, non-virtual function calls are reliably compiled to fairly efficient code while virtual calls are much less reliable. Like I said, this echoes the conventional wisdom that most C++ developers seem to retain. The compiler landscape has changed since that wisdom was formed, since the advent of LTO and devirtualization optimizations.
  - asdfws 4y ago
    So has programmer methodology. Throwing virtual calls everywhere is a relic of the past from the era of OOP fetishism. If you actually have statically verifiable leafs for virtual calls then you didn't even need a virtual call to begin with. It's code slop.
  - i-use-nixos-btw 4y ago
    Strongly agree on the philosophy - but alas my experience with this specific case has not been great. I’ve seen it simplify patches of code here and there, and that does apply to the trivial examples given in the post this topic links to - a function call involving a known child class. But add some basic real-world complexity and it quickly gets too complex for the optimiser to prove that it knows for sure what child class it is dealing with.

kaba0 4y ago

Unless you are in a hot loop (where you may not use virtual methods to begin with), I don’t think that performance difference is significant. Virtual calls have a slight overhead, but far from serious, and similarly not inlining something that you call only a single time for example is not the end of the world.

munificent 4y ago
The problem with not inlining is less with the overhead of the function call itself, and more the loss of further optimization opportunities. Consider this (trivial) example: main() { int x = foo() + 3; } int foo() { return 5; } Without inlining you have both the overhead of the call and the arithmetic addition. If you can inline the call then you get: main() { int x = 5 + 3; } But more importantly, the optimizer can now also eliminate the addition too: main() { int x = 8; } This is obviously a trivial example, but in real-world code, the optimization options opened up after inlining are important.