4

一段时间以来，我一直在玩弄一种编程语言的想法：它本质上是 C++ 和 Java 的语法，适用于系统编程（或实际上任何需要高性能的编程），但在我看来，比 C++ 更有趣的语法。我正在考虑如何处理分层类结构中的虚拟方法（我的语言不包括多重继承），以及避免 vtable 查找的方法。我的问题是双重的：

  1. 据我了解，vtable 查找如此影响性能的原因（至少在游戏开发等时间紧迫的场景中）是因为它需要延迟对象 vtable 指针，而这个 vtable 通常是缓存未命中。这是正确的，还是我错过了问题的一部分？
  2. 我对部分解决方案的想法是：如果编译器可以完全确定对象的类型（即，它不能是从它认为的类型派生的类型），并且该对象作为参数传递给函数，其类型为对象类型的超类，然后函数中调用的虚方法的位置可以作为一种“隐藏”参数传递，该参数在编译时添加。也许一个例子会有所帮助：

考虑以下类层次结构的伪代码：

class Animal {
    public void talk() { /* Generic animal noise... */ }
    // ...
}

class Dog extends Animal {
    public void talk() { /* Override of Animal::talk(). */ }
    // ...
}

void main() {
    Dog d = new Dog();
    doSomethingWithAnimal(d);
}

void doSomethingWithAnimal(Animal a) {
    // ...
    a.talk();
    // ....
}

请记住，这是伪代码，而不是 C++ 或 Java 或类似代码。此外，假设 Animal 参数是通过引用而不是值隐式传递的。因为编译器可以看到它d肯定是 type Dog，所以它可以将doSomethingWithAnimal定义翻译成这样的：

void doSomethingWithAnimal(Animal a, methodptr talk = NULL) {
    // ...
    if ( talk != NULL ) {
        talk(a);
    } else {
        a.talk();
    }
    // ...
}

然后main看起来会被编译器翻译成这样的东西：

void main() {
    Dog d = new Dog();
    doSomethingWithAnimal(d, Dog::talk);
}

显然，这不会完全消除对 vtable 的需求，并且可能仍需要为无法确定对象确切类型的情况提供 vtable，但是您对此作为性能优化有何看法？我计划尽可能使用寄存器传递参数，即使参数必须溢出到堆栈上，堆栈上的 methodptr 参数更有可能是缓存命中而不是 vtable 值，对吧？任何和所有的想法都非常感谢。

4

1 回答 1

9

关于Q1：缓存利用率实际上只是虚拟调用“问题”的一部分。函数的全部意义virtual，以及一般的后期绑定，是调用站点可以调用任何实现而不需要更改。这需要一些间接性：

  • 间接意味着解决间接的空间和/或时间开销。
  • 无论您如何进行间接调用，如果 CPU 具有良好的分支预测器并且调用站点是单态的（即只调用一个实现），间接调用只能与静态调用一样快。而且我什至不确定一个完美预测的分支是否与所有硬件开发人员关心的静态分支一样快。
  • 在编译时不知道被调用函数也会抑制基于知道被调用函数的优化（内联，还有循环不变的代码运动等等）。

您的方法并没有改变这一点，因此保留了大部分性能问题：它仍然浪费一些时间和空间（仅在额外的参数和分支上，而不是 vtable 查找上），它不允许内联或其他优化，并且它不会删除间接调用。

Re 2：这是对去虚拟化的一种过程间旋转，C++ 编译器已经在某种程度上做到了这一点（在本地，有@us2012 在评论中描述的限制）。它有一些“小”问题，但如果有选择地应用它可能是值得的。否则，你会生成更多的代码，传递很多额外的参数，做很多额外的分支，并且只会获得很少甚至净损失。

我认为主要问题是它不能解决上述大多数性能问题。为子类和同一主题的其他变体生成专门的函数（而不是一个通用的主体）可能会有所帮助。但这会产生额外的代码，这些代码必须通过性能提升来证明自己是合理的，而且普遍的共识是，即使在性能关键的程序中，这种激进的优化对于大多数代码来说都是不值得的。

特别是，虚拟调用开销仅在相同功能的基准测试中很重要，或者如果您已经从其他所有内容中优化了永远爱的地狱并且需要大量微小的间接调用（游戏开发中的一个示例：几个虚拟方法调用每个几何对象进行绘图或截锥体剔除）。在大多数代码中，虚拟调用无关紧要，或者至少不足以保证进一步的优化尝试。此外，这仅与 AOT 编译器有关，因为 JIT 编译器有其他方法来处理这些问题。查找多态内联缓存，并注意跟踪 JIT 编译器可以轻松内联所有调用，无论是否虚拟。

综上所述：vtables 已经是一种快速且通用的实现虚函数的方式（如果可以使用的话，这里就是这种情况）。除非在极少数情况下，否则您不太可能对它们进行很大改进，更不用说注意到改进了。如果你想尝试它，你可以尝试编写一个 LLVM pass 来做这样的事情（尽管你必须在较低级别的抽象上工作）。

于 2013-01-15T20:03:41.660 回答