嵌套分支和投机执行会怎样? [英] What happens with nested branches and speculative execution?

问题描述

好的，所以我知道，如果特定条件分支的条件需要花费时间来计算(例如，内存访问)，则CPU会假定条件结果，并沿该路径推测执行.但是，如果沿着该路径弹出另一个慢速的条件分支会发生什么(当然，假设第一个条件尚未解决，并且CPU无法仅仅提交更改)?CPU只是在推测内进行推测吗?如果最后一个条件的预测有误，但第一个条件不是预测的，会发生什么?会一直回滚吗?

Alright, so I know that if a particular conditional branch has a condition that takes time to compute (memory access, for instance), the CPU assumes a condition result and speculatively executes along that path. However, what would happen if, along that path, yet another slow conditional branch pops up (assuming, of course, that the first condition hasn't been resolved yet and the CPU can't just commit the changes)? Does the CPU just speculate inside the speculation? What happens if the last condition is mispredicted but the first wasn't? Does it just rollback all the way?

我说的是这样的东西:

if (value_in_memory == y){
   // computations
   if (another_val_memory == x){
      //computations
   }
}

推荐答案

推测性执行是 regular 的执行状态，而不是异常CPU在看到分支时进入的特殊模式，并且然后在分支不再飞行时离开.

Speculative execution is the regular state of execution, not a special mode that an out of order CPU enters when it sees a branch and then leaves when the branch is no longer in flight.

如果您认为不仅是分支可能出错，而且很多指令(包括那些访问内存的指令，对它们的输入值有限制)等也容易出错，那么这很容易看到.因此，任何实质性的乱序执行都意味着不断的猜测，CPU就是围绕这个想法而构建的.

This is easier to see if you consider that it's not just branches that can fault, but many instructions, including those that access memory, have restrictions on their input values, etc. So any substantial out of order execution implies constant speculation, and CPUs are built around that idea.

因此，嵌套分支"在这种意义上并没有什么特别的.

So "nested branches" doesn't end up being special in that sense.

现在，现代CPU具有多种用于快速分支错误预测恢复的方法，比从其他类型的故障 ¹ 中恢复的速度更快.例如，它们可以在某些分支快照快照寄存器映射的状态，以允许恢复在分支位于重排序缓冲区的开头之前开始.由于在 all 分支上进行快照并非总是可行的，因此可能需要复杂的启发式方法来决定在哪里拍摄快照.

Now, modern CPUs have a variety of methods for quick branch misprediction recovery, faster than recovery from other types of faults¹. For example they may snapshot the state of the register mapping at some branches, to allow recovery to start before the branch is at the head of the reorder buffer. Since it is not always feasible to snapshot at all branches, there might be complicated heuristics involved to decide where to take snapshots.

我提到最后一部分，因为这是嵌套分支可能重要的一种方式:当有许多分支在飞行中时，您可能会遇到一些与这些分支的跟踪有关的微体系结构限制，以进行恢复.有关更多详细信息，您可以浏览分支顺序缓冲区"的专利(适用于Intel技术，但毫无疑问是其他技术).

I mention this last part because it is one way in which nested branches might matter: when there are lots of branches in flight, you might hit some microarchitectural limits related to the tracking of these branches for recovery purposes. For more details, you can look through patents for "branch order buffer" (for Intel techniques, but there are no doubt others).

¹ 基本的恢复方法是继续执行，直到有故障的指令退休为止，然后丢弃所有较新的指令.在分支错误预测的情况下，这意味着您实际上可能会遭受两种或更多种错误预测，只有最旧的分支才会实际生效:例如，较年轻的分支错误预测，而在执行该分支之前(此时可能会发生恢复)，另一种发生了错误的预测，因此年轻的人最终被丢弃了.

¹ The basic recovery method is keep executing until the faulting instruction is the next to retire, and then throw away all younger instructions. In the context of branch mispredictions, this means you could actually suffer two or more mispredictions only the oldest of which actually takes effect: e.g., a younger branch mispredicts, and while executing up to that branch (at which point recovery can occur), another mispredict occurs, so the younger one ends up getting discarded.

这篇关于嵌套分支和投机执行会怎样?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！