我今天在一个由If语句引起的紧循环中遇到了一些速度减慢的情况，这让我有些惊讶，因为我希望分支预测能够成功地将特定语句流水线化，以最大限度地降低条件的成本。
当我坐下来思考为什么它没有得到更好的处理时，我意识到我对分支预测是如何处理的一无所知。我非常了解分支预测的概念及其优点，但问题是我不知道是谁在实现它，也不知道他们用什么方法来预测条件预测的结果。
更深入地看，我知道分支预测可以在几个级别上完成：
- 具有指令流水线的硬件本身
- C++风格编译器
- 口译语言的口译员
- 像java这样经过半编译的语言可以做到以上两个和三个
然而，由于优化可以在许多领域进行，我不确定如何预测分支预测。例如，如果我是用Java编写的，那么在编译、解释或解释后由硬件对我的条件进行优化了吗！？更有趣的是，这是否意味着某人使用不同的运行时环境？在不同的解释器中使用不同的分支预测算法是否会导致基于条件的紧密循环，根据使用的解释器显示出显著不同的性能？
因此，我的问题是，如果软件可以在非常不同的计算机上运行，这可能意味着不同的分支预测，那么如何围绕分支预测推广优化？如果硬件和解释器可以改变他们的方法，那么评测和使用任何一种被证明最快的方法都不能保证。让我们忽略C++，在那里你有编译级别的能力来强制执行这一点，如果有人仍然需要优化解释语言中的紧密循环，请查看解释语言。
是否存在某些假设，无论使用何种口译员，通常都是安全的？是否必须深入研究一种语言的复杂规范才能对分支预测做出任何有意义的假设？
简短回答：
为了帮助提高分支预测器的性能，请尝试构建程序，使条件语句不依赖于明显随机的数据。
详细信息
这个问题的另一个答案声称：
没有办法在高级语言中做任何事情来优化分支预测，缓存当然，有时你可以，但分支预测，不，根本不是。
然而，这根本不是真的。这一事实的一个很好的例子来自于Stack Overflow上最著名的问题之一。
所有分支预测器的工作方式都是识别重复代码执行的模式，并根据需要使用这些信息来预测分支的结果和/或目标。
当用高级语言编写代码时，应用程序程序员通常不必担心如何优化条件分支。例如，gcc具有__builtin_expect函数，它允许程序员指定条件分支的预期结果。但是，即使应用程序程序员确信他们知道特定分支的典型结果，通常也没有必要使用注释。在热循环中，使用此指令不太可能有助于提高性能。如果分支真的有很大的偏差，那么即使没有程序员注释，预测器也能够在大多数时间正确预测结果。
在大多数现代处理器上，分支预测器的性能非常好（即使在复杂的工作负载上，准确率也超过95%）。因此，作为一种微观优化，试图提高分支预测的准确性可能不是应用程序程序员想要关注的事情。通常，编译器会更好地生成适用于其目标特定硬件平台的最佳代码。
但是分支预测器依赖于识别模式，如果应用程序的编写方式不存在模式，那么分支预测器的性能就会很差。如果可以修改应用程序，使其具有模式，那么分支预测器就有机会做得更好。如果你发现一个分支的预测真的很差，你可以在高级语言的层面上考虑这一点。
分支预测（如缓存和流水线）通常是为了使代码更快地运行，从而克服系统中的瓶颈（所有dram都是超慢的廉价dram，X和Y之间的所有总线层，等等）。
没有办法在高级语言中做任何事情来优化分支预测，缓存当然，有时你可以，但分支预测，不，根本不是。为了进行预测，核心必须将分支与前面的指令一起放入管道中，并且跨体系结构和实现（不可能找到一个有效的规则）。通常甚至不在一个体系结构和高级语言的实现中。
您还可能很容易陷入这样一种情况，即为分支预测进行调优，而为缓存或管道或其他您可能想要使用的优化进行调优。总体性能首先是特定于应用程序的，然后是针对该应用程序进行调整的，而不是通用的。
尽管我喜欢在高级语言级别上宣扬和进行优化，但分支预测属于过早优化类别。如果还没有启用，只需在核心中启用它，有时它会为您节省几个周期，大多数时候它不会，而且根据实现的不同，它可能会花费比它节省的更多的周期。就像缓存一样，它与命中率和未命中率有关，如果它猜对了，你就可以更快地将代码放入一个更快的内存中，如果它猜错了，你已经烧毁了将要运行的代码可能使用的总线周期。
缓存通常是一个好处（尽管编写高级代码并不难，这表明它会降低性能而不是节省成本），因为代码通常在分支前对一定数量的指令线性运行。同样，数据的访问顺序经常足以克服惩罚。分支并不是我们每一条指令都要做的事情，我们分支到哪里也没有一个共同的答案。
您的后端可以尝试调整分支预测，方法是在分支之前的几个周期进行预分支决策，但所有决策都在管道大小内，并调整提取线或缓存线对齐。这再次干扰了对核心中其他功能的调优。