分支预测

分支预测( Branch predictor):当处理一个分支指令时,有可能会产生跳转,从而打断流水线指令的处理,因为处理器无法确定该指令的下一条指令,直到分支指令执行完毕。流水线越长,处理器等待时间便越长,分支预测技术就是为了解决这一问题而出现的。因此,分支预测是处理器在程序分支指令执行前预测其结果的一种机制。在ARM中,使用全局分支预测器,该预测器由转移目标缓冲器( Branch Target Buffer,BTB)、全局历史缓冲器( Global History Buffer,GHB) MicroBe,以及 Return Stack组成。

采用分支预测,处理器猜测进入哪个分支,并且基于预测结果来取指、译码。如果猜测正确,就能节省时间,如果猜测错误,大不了从头再来,刷新流水线,在新的地址处取指、译码。

分支预测算法:

  1. 无条件跳转指令必然会跳转,而条件跳转指令有时候跳转,有时候不跳转,一种简单的预测方式就是根据该指令上一次是否跳转来预测当前时刻是否跳转。如果该跳转指令上次发生跳转,就预测这一次也会跳转,如果上一次没有跳转,就预测这一次也不会跳转。这种预测方式称为:1位预测(1- bit prediction)
  2. 2位预测(2- bit predictor)。每个跳转指令的预测状态信息从1bit增加到2bit计数器,如果这个跳转执行了,就加1,加到3就不加了,如果这个跳转不执行,就减1,减到0就不减了,当计数器值为0和1时,就预测这个分支不执行,当计数器值为2和3时,就预测这个分支执行。2位的计数器比1位的计数器拥有更好的稳定性。

通常商用的处理器会使用多种策略的组合,来获得更好的预测结果;

分支预测实现

算法是基础,有了算法后,就可以在处理器中实现分支预测功能。 Intel的分支预测模块包含了3个单元:

  1. Branch Target Buffer(BTB)
  2. The Static Predictor
  3. Return stack


基本的BTB结构如下:
分支指令在执行后,会将这条指令的地址及它的跳转信息记录在BTB中。 BtB buffer不会太大,不能将所有的分支指令都存进去,通常采用Hash表的方式存入。在取指时,先将PC(程序指针)和BTB中的分支指令的地址进行比较,如果找到了,说明这条指令是分支指令,并且在BTB中有记录,就使用BTB预测出来的跳转地址。如果没有记录,就不能使用BTB的信息了,取指下一条指令。
Intel的 Branch Target Buffer还包含了历史跳转信息,用于预测分支指令是否发生跳转。

The Static Predictor

当分支指令在BTB中记录了历史信息才能使用BTB进行预测,当分支在BTB中找不到记录时,可以使用 The Static Predictor(静态预测器)。人们将分支指令的执行情况做了大量的统计,从中总结出一些特征,并将这些特征总结为一些固定的策略,这就是静态预测器.
当指令被解码后,它是不是分支指令,以及要跳转的地方就知道了,只是不知道是否该跳。一般来说,向上的跳转,常用来组织成循环,这个跳转应该被预测为执行。

Return Stack

函数调用在程序中大量出现,函数调用与返回也都是通过跳转来实现的。例如,有3个函数调用了 printf函数,pinf函数地址固定,调用时知道地方,但是在返回时,并不知道该返回到哪个地方, Retum Stack(返回栈)可以用于解决这个问题。在函数调用时,将函数的返回地址压栈到 Retum Stack中,当遇到函数返回指令时,就从 Retum Stack中取出地址。

部分来自《大话处理器》这本书;

原文地址:https://www.cnblogs.com/linhaostudy/p/9193162.html

时间: 2024-10-07 05:23:05

分支预测的相关文章

体系结构复习2——指令级并行(分支预测和VLIW)

第五章内容较多,接体系结构复习1 5.4 基于硬件推测的指令级并行 动态分支预测是在程序运行时,根据转移的历史信息等动态确定预测分支方向,主要方法有: 基于BPB(Branch Prediction Buffer)和BHT(Branch History Table)的方法 高性能指令发送(High Performance Instruction Delivery) 5.4.1 基于BPB和BHT的方法 (1)1-bit BHT 分支指令PC的低位索引1位记录上一次转移是否成功(不是预测是否正确)

CPU 分支预测

去年在安宁庄的时候, 有个同事阐述了一个观点:php中的if else  在执行时考虑到效率的原因,不会按我们的代码的顺序一条一条去试,而是随机找出一个分支,执行,如果不对,再随机找到一个分支 当时由于种种原因,也没过多去想这个问题,最近查了下资料,发现里面的学问还挺大的 php解释器是由c编写的,是个经编译生成的二进制文件, 我们编写的PHP代码相当于这个C程序的参数,只不过这个参数是个一个的文件, 这个C程序要解析这个php文件,产生相应的opcode,再去执行opcode对应的函数,每一部

浅谈分支预测、流水线与条件转移(转载)

一 一个问题 原文链接:http://www.cnblogs.com/yangecnu/p/4196026.html#undefined 在StackOverflow上有这么一个问题 Why is processing a sorted array faster than an unsorted array? .例子中,对一个数组进行条件求和,在排序前和排序后,性能有很大的差别.原始的例子是C++和Java的,这里将其换成了C# : static void Main(string[] args)

分支预测技术

分支预测(Branch Prediction): 从P5时代开始的一种先进的,解决处理分支指令(if-then-else)导致流水线失败的数据处理方法,由CPU来判断程序分支的进行方向,能够加快运算速度. 当 包含流水线技术的处理器处理分支指令时就会遇到一个问题,根据判定条件的真/假的不同,有可能会产生转跳,而这会打断流水线中指令的处理,因为处理器无法 确定该指令的下一条指令,直到分支执行完毕.流水线越长,处理器等待的时间便越长,因为它必须等待分支指令处理完毕,才能确定下一条进入流水线的指令.

__builtin_expect — 分支预测优化

1.引言 在很多源码如Linux内核.Glib等,我们都能看到likely()和unlikely()这两个宏,通常这两个宏定义是下面这样的形式. #define likely(x) __builtin_expect(!!(x), 1) #define unlikely(x) __builtin_expect(!!(x), 0) 可以看出这2个宏都是使用函数 __builtin_expect()实现的, __builtin_expect()函数是GCC的一个内建函数(build-in functi

分支预测(branch prediction)

记录一个在StackOverflow上看到一个十分有趣的问题:问题. 高票答案的优化方法: 首先找到罪魁祸首: if (data[c] >= 128) sum += data[c]; 优化方案使用位操作: int t = (data[c] - 128) >> 31; sum += ~t & data[c]; 正数右移31一定为0,负数右移31一定为-1.再取反进行求&(按位与),0与任何数的&为0,-1与任何数的&为数本身.这样就巧妙的避开分支预测了,可以

优化技巧:提前if判断帮助CPU分支预测

摘要: 在stackoverflow上有一个非常有名的问题:为什么处理有序数组要比非有序数组快?,可见分支预测对代码运行效率有非常大的影响.要提高代码执行效率,一个重要的原则就是尽量避免CPU把流水线清空,那么提高分支预测的成功率就非常重要. 分支预测 在stackoverflow上有一个非常有名的问题:为什么处理有序数组要比非有序数组快?,可见分支预测对代码运行效率有非常大的影响. 现代CPU都支持分支预测(branch prediction)和指令流水线(instruction pipeli

【CPU微架构设计】利用Verilog设计基于饱和计数器和BTB的分支预测器

在基于流水线(pipeline)的微处理器中,分支预测单元(Branch Predictor Unit)是一个重要的功能部件,它负责收集和分析分支/跳转指令的参数和执行结果,当处理新的分支/跳转指令时,BPU将根据已有的统计结果和当前分支跳转指令的参数,预测其执行结果,为流水线取指提供决策依据,进而提高流水线效率. 下面讨论提出分支预测机制的主要原因和实际意义: 在流水线处理分支跳转指令时,目标地址往往需要推迟到指令的执行阶段才能运算得出,在此之前处理器无法及时得知下一条指令的取指地址,因此无法

理解CPU分支预测,提高代码效率

摘要: 技术传播的价值,不仅仅体现在通过商业化产品和开源项目来缩短我们构建应用的路径,加速业务的上线速率,也会体现在优秀程序员在工作效率提升.产品性能优化和用户体验改善等小技巧方面的分享,以提高我们的工作能力. 技术传播的价值,不仅仅体现在通过商业化产品和开源项目来缩短我们构建应用的路径,加速业务的上线速率,也会体现在优秀程序员在工作效率提升.产品性能优化和用户体验改善等小技巧方面的分享,以提高我们的工作能力. 从本期开始,我们将邀请来自阿里巴巴各个技术团队的程序员,涵盖中间件.前端.移动开发.