因为speccpu的影响，很多CPU厂家有一个SPEC优化团队，目标就是用软件优化提高成绩，如何看待这种优化提分，哪些是用户用不到的，怎么公平对比？
今天逛zhi~hu时看到讨论鲲鹏920性能时发现有一些有意义的讨论，对于speccpu优化问题，进行了分析。

沙发

夏晶晶
关于SPECINT2006，有时候缩写为SPECINT2K6。主要谈一谈benchmark本身，因为很多帖子都吵得不可开交。牛顿定律说得好，不同的参照系下面相对速率各不相同，所以统一参照系是关键。
现在业界大多数时候做性能比拼还是基于SPECINT2006，参照系比较清晰
从spec网站我们可以点击benchmark选择获得系统厂商上传的分数，都是公开的。这里我们着重关注一下SPECINT RATE，这表示的是一个CPU整系统的总分数。

没办法，只好贴图
文中明确提出：统一用GCC -o2，去掉那些额外的option，测base值，这也是业界用户的主流用法。
这篇下面还有华为官方回应，发布的成绩印证了这种做法。
华为已认证的官方帐号143 人赞同了该回答
感谢知友们对鲲鹏920芯片的关注哈，这个问题，我们找来了华为海思的小伙伴们，看看他们是怎么回复的：
华为鲲鹏920的计算子系统，Memory子系统以及I/O 子系统针对云计算领域的workload做了全面优化设计，可广泛应用于大数据、分布式存储、数据库、Web和ARM 原生等场景。
鲲鹏920基于ARMv8指令集，自主开发处理器内核，针对每个核进行了优化设计，采用多发射、乱序执行、优化分支预测等多种手段提升单核的性能。在Memory子系统上也进行了大量的优化，采用当前典型的3级Cache的架构，对Cache大小以及延时进行了优化设计。鲲鹏920采用自研Mesh互联Fabric，集成了64个自研核，典型主频2.6GHz，性能达到业界领先水平，尤其是整型计算能力，业界标准Benchmark SPECint_rate_base2006@gcc 7.3.0 -O2评分超过930。同时采用了优化的高带宽低延时互联总线，支持多路互联。
同时将DRAM的通道数据从当前主流的6个通道提升到8通道，DRAM的典型主频也从2666MHz提升至2933MHz, 总带宽达到187GB/s，保证了920超强算力的高效输出。
集成PCIe 4.0, CCIX等高速接口，更高效地和外设或其他异构计算单元通信；集成2个100G RoCE端口，片上集成了SAS/SATA3.0可以帮助降低部分存储等场景的TCO。
发布于 2019-01-14

最后，我也建议贴吧网友在讨论CPU性能时，注意“优化”问题，统一对比标准，认清楚一些厂家的宣传手段。

intel同一款芯片SPECINT2006的ICC分数是GCC分数的约1.8~1.9倍。刚才也说了，同一款芯片ICC在业务性能评测上是GCC的1.1～1.2倍。所以这1.8~1.9倍的收益，对于用户来讲基本上是拿不到的，这也是ICC被称为benchmark compiler的原因。
光嘴皮子这么说肯定不行，我们可以再进一步看看是什么带来的这1.8倍提升，看看是不是业务性能真的拿不到？
第一个关键项是AVX，AVX是intel的向量及浮点运算加速的指令。向量指令能够大福提升CPU Load/Store的效率，一些向量的运算也能大福提升运算效率，所以AVX对计算和访存密集型业务有很大收益，典型就是libquantum量子计算。当然GCC也有AVX开关，但是很明显其收益远远小于ICC。有人会问，AVX指令是intel的有效指令，能用而且用的好那是本事。没错，先不谈ICC额外收费的问题，你知道使能AVX，8180的基本频率会降低到2.0GHz么？这其实是一个隐含的配置项，CPU降频会影响很多非访存密集的业务。为什么benchmark其他子项没有受到影响？ 因为不同子项是独立编译并且独立运行的，用户的一个完整业务能够拆成很多子业务独立编译独立运行吗？ 不能啊。
第二个关键点就是parallel选项了，这个怎么说呢，我的观点就是赤裸裸作弊了，但我不明白为什么SPEC网站允许，因为这个选项已经背离了specint测试项的测试目标本身。parallel选项的机制是调用OPENMP库，把一个任务中可以并发的代码都包装成独立的子任务并让众多的子任务并发运行。简单举例，ICC下表面上你在测试单核性能，实际上ICC会调用更多的核来并行执行众多的子任务。那这样测试的结果有意义么？ 以前面的8180测试为例，理论上我们期望有112个copies在并发，但ICC的parallel会编译出数千个子任务并发。这确实是编译器上了不起的技术，但已经超出了SPECINT原本的测试目的，也不是能够让绝大多数用户获得的收益。
over
intel有ICC，AMD有AOCC，其实ARM也有ARMCC，也能做类似的事情。但benchmark的用途是给用户建立性能参照体系而不是相互割裂跑一个虚高的数字。所以我们应该回到benchmark的原点，统一参照系。
统一用GCC -o2，去掉那些额外的option，这也是业界用户的主流用法。

虽然常引夏晶的叙述，但这一点上私以为他的表述是不合适的。编译优化本来就是软件的一部分。同样的应用，就是有不同的编译优化，难道不是用户可体验的性能差异？包括parallel，启动大量子任务给相对空闲的多核上调度，本来也是可体会的差异，对它质疑也应该是对实际负载是否处理得足够好。speccpu开宗明义就说自己测的是整机，这也是为什么服务器厂家会送测，所以整机内的调度说提升性能并无不妥，至少parallel在rate项目启用有合理性，虽然在speed项目启用确实有一些不妥。

夏晶晶说的话也是有立场的，首先本身GCC也具有parallel类似的优化功能。如果说ICC是作作弊，那么GCC同样也作弊，这怎么说得通。
其次，parallel并对单核分数的影响微乎其微。兆芯的四核产品KX-5640为例，其多核的SPECint_Rate分数相较于单核SPECint分数的加速比为3.37，高于龙芯四核3A3000的3.26。
理论上，如果parallel对单核分数有加成，那么多核加速比肯定会露馅。

gcc对不同架构指令的支持也不一样吧。这样比较x86,arm 有先天优势。