论文理解
我认为这篇论文在我目前工作中，所体现的价值是（以下全是我自己的理解，可能有不准确之处）：
- 提供了使用少量的benchmark进行测试却获得大致相同结果的依据：根据论文提供的数据，对于SPECrate INT/FP、SPECspeed INT/FP可以各选3个benchmark进行测试，最终的准确率大于93%
- 通过分析每个benchmark的input set，选出最具有代表性的input：一般来说，benchmark有多个输入，最后得到的结果是综合这些input的结果呈现出来，而只选择具有代表性的input进行测试（这里直接编译运行benchmark的优势就体现了出来），可以进一步缩短测试时间
- 大多数INT类型的benchmark rate版和speed版反映的性能特征相差不大，但由于rate的规模要远远小于speed，所以可以使用rate版本的benchmark来进行初步的性能测试，来缩短测试时间，但是许多FP类型的benchmark相差还是很大的，不能使用rate版本来代替speed版本做初步性能测试（具体还是要根据Figure7和Figure 8来判断是否可以使用rate进行替代，而且论文在这一部分只考虑的是单核的处理器，对于多核这个结论可能并不适用）。
我认为这些结论可以在对于优化编译系统的初步性能测试，以节约时间，但对于最终性能的测试，还是应该运行all benchmarks。
除此以外，该论文还说明了CPU2017将CPU2006中benchmark的移除，基本没有影响其反应的性能特征，增加的benchmark总体来说还是更能说明性能特征的，但我暂时觉得这块不是我工作的重点，所以我没有把精力放在这块内容的解读上。
论文内容
这里只是截选了一些我认为比较重要的内容，并且按照自己的理解写了出来。
CPU2017 Benchmark：Overview & Characterization
-
根据Table 1我们可以看出每个benchmark指令数、访存指令占比、分支指令比、CPI。我们可以很容易地得出结论，rate benchmark要比speed benchmark指令数少很多。
-
CPU2017与CPU2006相比，具有更多的指令数（这就导致测试时间更长）；CPU2017分支指令比减少和访存指令比增多，这可能会导致基本块变大，控制冒险变少，可能会导致更高程度的并行。
-
Figure1将benchmark运行时间划分为多项活动所用的时间，这里Front-End Bound包括取指、分支预测错误所阻塞的周期，Others包含resource stalls（我理解为结构冒险）、指令依赖、结构依赖等。显然优化Figure1中占比最大的部分可以带来更多的性能提高。
如leela_r、mcf_r、xz_r因为有着高分支预测错误率，所以要花很多运行时间在Front-End上（可以看到这几个benchmark的灰色部分占比比较大），mcf_r指令cache的miss rate也很高，这也是导致它在Front-End花费更多时间的另一个原因。
omnetpp_r、xalancgmk_r、mcf_r和fotonik3d_r访问cache、memory时间多。
这部分内容带给我的启发是：如果想针对某部分进行优化，可以选择部分benchmark进行有针对地测试（可以将Figure 1或者Table 1作为选择benchmark的依据），比如：如果做的是针对访存的优化，可以优先选择omnetpp_r等访存时间占比较多的benchmark有针对地进行测试。
问题：我理解的取指过程是从存储器或者cache中去除指令，放入指令寄存器，对其进行译码，取指时间是不是包含了访问L1 I、L2、L3的时间？那么图中的L2 Bound、L3 Bound是不是指的是访问数据的时间？
METHODOLOGY
在这部分作者列出了一些性能指标，见Table 3。
并介绍了他后续用来对比程序相似性的方法：使用每个benchmark所测量出来的以上性能指标作为数据，进行PCA（主成分分析法），拿出PCs，对于分析出来的主成分进行层次聚类，得到benchmark的相似性。
REDUNDANCY IN CPU2017 BENCHMARK SUITE
这部分是整篇paper的重头戏，主要分为以下五个部分：
-
如何科学地选取少量地benchmark进行测试，却获得大致相同的结果
Figure 2、3、4分别是用METHODOLOGY中的方法做出的图，这些图可以作为subset benchmark的依据。比如：如果我们想仅使用3个benchmark来对SPECrate FP进行测试，就相当于把Figure 4中的benchmark分为三类，507一类，519、549一类，其余为一类，于是必选507，然后从519和549中选取一个作为代表（这里选择549），最后从余下的benchmarks中选择具有最小linkage distance的benchmark来作为这一类的代表，在本例中也就是从608和544中任选一个作为最后一类benchmarks的代表。
于是我们可以得到如Table 5所示的结果：
选benchmarks的子集可不可以反应真实的性能情况呢？在论文中说明：使用三个benchmark代表这一类benchmark的时候，average error是很小的，效果远远好于随机选取几个benchmark来进行性能测试，说明这样是可行的。
保守一点地说，使用1/3的benchmark是可以反应测试情况的。 -
选择有代表性的input set
CPU2017的benchmark大多数有着很多input set，它应该是综合多个input set的结果最后得出性能测试的结果，但是这样无疑要耗费大量的时间。于是可以使用METHODOLOGY提出的方法对input set进行分析。
最终可以选出每个benchmark的代表性input set如Table 7所示：
问题：以557为例（我在Figure 7中用红框标注出来），我认为选取它代表性input set的流程为，找到与557.xz.r linkage distance最小的input set（也就是和557.xz.r最相似的input set），根据Figure 7，我认为是input set 3，而不是Table 7给出的input set 1，是我哪里错了吗？
-
rate和speed benchmark是不同的吗
从Figure 7中其实可以看出来，除了620、623、625，大多数INT类型的benchmark的speed和rate在性能的表现上都是相似的（因为linkage distance比较小），但是许多FP类型的benchmark相差还是很大的，不能使用rate版本来代替speed版本做初步性能测试（具体还是要根据Figure7和Figure 8来判断是否可以使用rate进行替代，而且论文在这一部分只考虑的是单核的处理器，对于多核这个结论可能并不适用）。
问题：在单核情况下，使用rate的benchmark代替speed的benchmark做性能测试，是指使用rate的benchmark测rate，可以一定程度反应出来该benchmark所对应的speed吗？
-
将benchmark按照分支和访存行为划分出来
- 具有高分支预测错误率的benchmark：541、641、505、605
- 具有高分支命中率的benchmark：505、605、502、602
- 具有高data cache miss rate的benchmark：605、505、607、507、649、549
- 具有高cache accesses数的benchmark：500、600、607、507
- 具有高指令cache 访问和miss的benchmark：500、600、502、602
尽管可以针对性地进行测试，但是最后的测试结果还是应该要覆盖到整个workload。
-
为不同的应用环境挑选具有代表性的benchmark
Table 8列出了不同应用场景下的benchmark，加粗的benchmark是该应用场景下具有代表性的benchmark。对于那些在rate和speed上performance behavior差不多的benchmark这里只加粗rate的benchmark（因为IC小）。
注：本文含自身理解，可能存在不准确之处，后续可能会进行修改