Bootstrap

分支预测器实验简述

经 yyh 提醒,加了一条优化,在一些测试点上有很大提升(final2)。


本来没打算写的,一是因为最近太忙了,二是因为这个东西太玄学了,很多地方都在吊打我的常识。开始做的时候已经是提交当天下午了(当时还没有延期的通知),所以前面没做好数据记录。

拿到代码以后我首先试了很多种平凡的改法,比如 PC xor ghr 改为 (PC << 2) xor ghr 之类的,改进不大,大多数情况下都要比基本的 gshare 劣。

然后实现了一个仅用局部历史的预测器,测量几组数据发现比 gshare 优秀。嗯,很好。然后我又写了个预测器来选择是采纳局部信息的预测器还是全局信息的预测器,效果出乎意料的好。

本来故事到这里一帆风顺,当时单纯的我还有点疑惑为什么大家都花那么多时间来做这个作业——直到我发现我的基于局部历史的预测器有一个bug:我想写的是把 PC 和局部历史信息拼接起来作为地址去查表,但我写成了 (PC << 8) ^ lhr,其中 lhr 不止 8 位。这个东西看起来就没有什么道理,于是我顺手把这个 bug 改掉了,再一跑结果差的难以想象。好吧,那就像 gshare 一样改成 PC ^ lhr 呗,结果还是差,就是要左移八位再异或才是最优的。

这有什么道理?

后面还发生了很多很多的类似的情况,我完全解释不通为什么这么改会更好,事情已经朝着我无法控制的方向发展了。

后面的一个多小时我做的东西就是:随机改动某几个参数/某个地方的写法,在测试集上跑,根据结果的变化反过来再来改参数。这不就是在测试集上人肉梯度下降么?认识到这一点的时候我就一点往下优化的欲望都没了。

那就这样吧,最后放一个表:

LONG-1LONG-2LONG-3LONG-4SHORT-1SHORT-2SHORT-3SHORT-4SHORT-24SHORT-25SHORT-27SHORT-28SHORT-30
gshare0.57721.38617.78710.00522.917611.39013.72085.16290.00050.00180.4710.00747.0143
21bits0.10730.91396.75340.00660.68384.16963.31001.89590.00050.00180.04080.00741.3241
24bits0.09120.84666.81110.00730.60403.55913.21301.67890.00050.00180.04980.00751.0796
mixed0.12310.95476.90000.00530.82514.09813.20702.65270.00100.00230.24450.01101.4643
final0.09020.84606.81500.00730.60283.43963.21231.66860.00050.00180.04980.00751.0663
final20.08880.76706.61210.00651.16720.56022.30011.13480.00050.00180.14040.00830.2364
;