为什么 std::any 的实现使用函数指针 +函数操作码，而不是指向虚拟表的指针 +虚拟通话？

Question

gcc 和 llvm 将功能指针存储在任何对象中，并使用op/操作参数来调用该功能以执行不同的操作。这是LLVM的该函数的示例：

static void* __handle(_Action __act, any const * __this,
                          any * __other, type_info const * __info,
                          void const* __fallback_info)
    {
        switch (__act)
        {
        case _Action::_Destroy:
          __destroy(const_cast<any &>(*__this));
          return nullptr;
        case _Action::_Copy:
          __copy(*__this, *__other);
          return nullptr;
        case _Action::_Move:
          __move(const_cast<any &>(*__this), *__other);
          return nullptr;
        case _Action::_Get:
            return __get(const_cast<any &>(*__this), __info, __fallback_info);
        case _Action::_TypeInfo:
          return __type_info();
        }
        __libcpp_unreachable();
    }

注意：这只是一个__ handle函数，但是每个> abory实现中有两个这样的功能：一个用于在中分配的任何中分配的小对象（小缓冲区优化），另一个用于分配在堆上的大对象。使用哪一个取决于存储在任何对象中的函数指针的值。

在运行时选择两个实现之一并从预定义方法列表中调用特定方法的能力本质上是虚拟表的手动实现。我想知道为什么要以这种方式实施。简单地存储指向虚拟类型的指针会更容易吗？

我找不到有关此实施原因的任何信息。考虑到这一点，我想使用虚拟类在两种方式上是最佳的：

• 它需要一个对象实例并管理单身人士，而实际上，实际上是一个vtable（无实例）就足够了。
• 在上调用函数任何都将涉及两个间接性：首先通过存储在的指针中，以获取VTable，然后通过存储在VTable中的指针。我不确定这是否与上面的基于Switch的方法有什么不同。

这些是基于switch -ing op编码的实现的原因吗？当前实施还有其他主要优势吗？您知道有关此技术的一般信息的链接吗？

Answer 1

考虑std :: Any的典型用例：您将其传递给代码，将其移动数十次，将其存储在数据结构中并稍后再次获取。特别是，您可能会经常从函数返回它。

如今，指向单个“ Do Alovy”功能的指针位于Any中的数据旁边。鉴于这是一种相当小的类型（GCC x86-64上的16个字节），任何都适合一对寄存器。现在，如果您从函数中返回任何，则任何的“执行所有操作”函数的指针已经在寄存器或堆栈中！您可以直接跳到它而无需从内存中获取任何东西。最有可能的是，您甚至根本不必触摸内存：您知道在构造它时中的哪种类型，因此函数指针值只是一个常数，该常数已加载到适当的注册。稍后，您将寄存器的值用作跳跃目标。这意味着没有机会对跳跃进行错误预测的机会，因为没有什么可以预测的，CPU的值就在那里。

换句话说：通过此实现免费获得跳跃目标的原因是，CPU首先已经以某种方式触摸了任何，这意味着它已经知道了跳跃目标可以跳到它的情况下，没有额外的延迟。

这意味着，如果任何已经“热”，那么在当前的实现中确实没有间接说明，这大部分时间都在于它，尤其是当它用作返回值时。

另一方面，如果您在只读部分中使用函数表指针（并让任何实例指向这一点），则必须转到内存（或缓存）每次您都想移动或访问它。在这种情况下，任何的大小仍然是16个字节，但是从内存中获取值的速度比访问寄存器中的值要慢得多，尤其是如果它不在缓存中。在许多情况下，移动任何都与将其16个字节从一个位置复制到另一个位置一样简单，然后将原始实例归零。这在任何现代CPU上都是免费的。但是，如果您进入指针表路线，则每次都必须从内存中获取，等待读取完成，然后进行间接调用。现在考虑一下，您通常必须对任何（即移动，然后破坏）进行一系列通话，这将很快加起来。问题在于，您不仅会在每次触摸任何> 时免费获得要免费跳到的函数的地址，CPU必须明确获取它。间接跳到从内存中读取的值很昂贵，因为CPU只能在整个内存操作完成后退休跳跃操作。这不仅包括获取一个值（由于缓存而可能很快），还可以解决生成，存储转发查找，TLB查找，访问验证，甚至可能是Page Table Walks。因此，即使快速计算了跳跃地址，跳跃也不会退休很长时间。一般而言，“间接跳动到地址 - 从内存”操作是CPU管道可能发生的最糟糕的事情之一。

TL; DR：正如现在的那样，返回任何都不会停滞CPU的管道（跳跃目标已经在寄存器中可用，因此跳跃可以立即退休）。使用基于表的解决方案，返回任何将两次 ：一次获取移动函数的地址，然后再获取驱动器的时间。这将延迟跳跃的退休，因为它不仅需要等待内存值，还需要等待TLB和访问权限检查。

另一方面，代码存储器访问不受此影响，因为无论如何代码以微模式形式保存（在µOP缓存中）。因此，在该开关语句中获取和执行一些有条件的分支非常快（甚至是当分支预测器变得正确时，几乎总是这样做时）。