在自己的 VM 解释器中实现自己的分支预测优化是否有意义，或者在已经支持分支预测优化的硬件上运行 VM 就足够了？
这在有限的意义上可能是有意义的。
例如，在 JIT 编译器中，在生成程序集时，您可能决定根据观察到的分支概率对代码进行布局。这只需要一种非常简单的预测器，它知道总体概率，但不需要识别任何模式。如果您确实识别了模式，则可以进行更复杂的优化，例如，可以将具有嵌入式分支的循环交替进行每次迭代，并且可以将每次迭代展开 2 倍，并且为观察到的情况创建有效的主体。
对于解释器来说，它似乎不太有用，但可以想象一些复杂的设计，将一些相邻的指令融合到一个操作中以提高效率，这可能会从分支预测中受益。类似地，解释器可能会从识别循环中受益。
显然，您谈论的是解释字节码的虚拟机，而不是CPU的硬件虚拟化。
如何实施？ CPU 中的分支预测仅在它们是流水线的，并且用于推测性无序执行时才需要。
如果口译软件会产生更多的工作来实现，那么这些事情对于解释器软件来说都没有意义。 对于阵列上的循环以隐藏负载和 ALU 延迟，软件流水线是值得的，尤其是在较旧的顺序 CPU 上，但这不会增加要运行的指令总数。 如果您不确定接下来需要做什么，请将猜测留给硬件 OoO 执行官。
请注意，对于纯非 JIT 解释器，来宾代码中的控制依赖项在解释器中成为数据依赖项，而来宾中的一系列不同指令在解释器中创建控件依赖项(调度到处理程序函数(。 请参阅分支预测对 R 的影响究竟如何？
您可能需要关心将运行代码的 CPU 中的分支预测。 最近(就像自哈斯韦尔以来的英特尔一样(，CPU终于在这方面还不错，使用IT-TAGE预测器：分支预测和解释器的性能 - 不要相信民间传说。
您不会在软件中实现分支预测，但对于较旧的 CPU，值得在考虑硬件分支预测的情况下调整解释器。 X86 预取优化："计算 goto"线程代码有一些链接，尤其是 Darek Mihocka 的一篇文章，讨论了对于较旧的 CPU(编写时是当前的(来说，拥有一个"大中央"调度分支是多么糟糕，就像每个指令处理程序函数返回的单个switch一样。 这意味着哪个指令倾向于遵循的整个模式，必须为该单个分支预测其他指令。 如果没有像IT-TAGE这样的东西，单个分支的预测状态是非常有限的。
针对较旧 CPU 的调优可能涉及在每个处理程序函数结束时将调度放在下一条指令中，而不是返回到单个调度循环。 但同样，这不是实现分支预测，而是针对它进行调整。