SPEC CPU2017基准测试实战：CPU性能对比与选型分析

简介：一份发表于《电子产品可靠性与环境试验》2021年增刊的学术论文PDF，基于SPEC CPU2017国际权威评测工具，系统对比了国产ARM架构处理器Hi1616与Intel E5-2650v4的性能差异。论文先介绍国产CPU发展现状与研究背景，随后从不同线程数下的计算速度、不同任务拷贝数下的吞吐量两个维度设计对比实验，并进一步验证GCC编译器版本对测试结果的影响；结果表明在多任务高并发场景中Hi1616具有明显优势，而E5-2609v4在单线程科学计算场景下表现更佳。对于从事CPU选型评估、国产替代验证、软硬件协同优化等工作的工程师与研究人员来说，这份资源提供了完整的测试思路与可复现的实验依据。压缩包内含1个PDF文件，文件大小约1.08MB，文档含摘要、测试方法、数据图表与结论，可直接查阅。已有2891人关注学习这份资源。通过阅读论文，读者能够掌握SPEC CPU2017的基准测试方法，理解ARM与X86架构在不同负载下的性能特征，并为国产CPU的研发与应用提供量化支撑。

1. 从一次CPU选型翻车说起：SPEC CPU2017到底在量什么

某回给业务挑双路服务器，候选两颗CPU在宣传页上都是“旗舰”，结果一上真实负载，一颗快一颗慢，差距稳定在15%以上。项目超期那几天我才意识到，所谓“实测”如果没一套业界认账的量化基准，本质上就是各说各话。后来照着《基于SPEC CPU2017的CPU性能对比分析》这份报告的思路做了一轮正规测试，问题才真正定位。SPEC CPU2017是目前业界认可度最高的CPU计算性能基准，把编译器、数值计算、稀疏图遍历、气象模型等真实负载浓缩成数十个标准程序，输出可横向对比的分数。这篇文章按“拆套件→搭环境→跑分→对比→避坑”的顺序，把一套能复现的CPU性能对比分析方案摆出来，给做选型和调优的同行一个可直接照做的落地路径。

2. 拆解SPEC CPU2017套件：rate/speed与base/peak怎么选

第一次接触这套基准的人，有一半会挂在套件选择上。SPEC CPU2017不是“一个”测试，而是几十个程序、四个可执行套件的组合；不搞清差异就跑分，分数出来往往不是你想回答的问题。先想清楚“我要测吞吐还是测延迟”，再决定跑哪个套件。

2.1 rate与speed：吞吐和延迟，是两种完全不同的答案

rate模式把相同副本复制到多个核上并发跑，测的是系统吞吐；speed模式只放一个副本，测的是单任务延迟。同一台机器在两种模式下得到的是两个不同物理量的数字，不能互相换算。用表格列一下就清楚了。

实际选型时，虚拟化密度、混部调度这类场景看intrate；数据库OLTP这类延迟敏感业务看intspeed。给某中间件选型那次，我们最初只看rate，差点推断错了方向，因为这类业务单线程等待时间才是用户体感的关键。这是血泪经验。

还有一点容易忽略：rate副本数对分数有非线性影响。副本数从1涨到物理核数时，吞吐分数近似线性上升；超过物理核数、靠超线程补位时，提升幅度开始不确定，可能只有几个百分点甚至不升反降。所以跑rate前一定要明确副本数，并在报告里写清楚，否则别人无法复现你的“吞吐结论”。

2.2 base与peak：为什么选型只看base

每个套件跑出来都有两档分数：base和peak。base要求所有测试程序用同一组优化选项，程序之间不允许单独调优，保证可复现的公平；peak允许对每个程序单独给优化flag，分数可以拉得很高。对横向对比来说，base是主依据。

peak那种逐程序调优，数学上更像“针对基准本身做优化”，不代表一台机器在你业务上有同样的优势。凡是一份报告只给peak不给base，我都按“没做完”处理。执行层面，在runcpu命令里加--tune=base或--tune=peak来切档，配置文件里也可以写默认档位。

2.3 参考机与归一化：分数是比值，不是绝对性能

SPEC CPU2017的分数算法是：被测机运行时间与SPEC固定参考机的运行时间相比，参考时间÷被测时间×100。所以分数表达的是倍率关系，不是fps、IOPS那样的绝对单位。因为参考机是固定的，同版本之间的分数可以跨平台直接比；但有三个前提：套件版本一致、参考机一致、base/peak档一致。

整数分和浮点分不能交叉相加。intrate的60分和fprate的30分没有算术关系，一个测整数吞吐，一个测浮点吞吐，合起来做加权只能按场景配权重，不能简单求和。另一个坑是“只报总分不报明细”：总分是各benchmark的平均，某个程序特别强或特别弱会被平均吃掉。做对比分析时务必看分项明细，许多选型结论都是被明细改写的。

3. 把SPEC CPU2017跑起来：环境清单、配置文件与最小命令

套件选对了，接下来是环境。这一步的问题很少出在“不会敲命令”，而是出在环境没准备好——内存不够、频率不稳、放网络盘上跑，这些到最后都会变成不可信的分数。

3.1 前置环境：这些不准备好，跑分注定白费

内存方面，rate模式跑ref集强烈建议32GB以上。ref是完整输入集，部分浮点程序单副本就要占用数GB内存，rate多副本并发后工作集会叠加到几十GB。speed模式16GB勉强能跑，但如果你同时开编译和跑测试，32GB更稳。磁盘预留40GB，编译产物、中间文件和结果日志加起来很可观。

最关键的一条：不要把套件和临时目录放在NFS或网络盘上，第一次跑就吃过这个亏，网络IO抖动会直接污染运行日志，分数忽高忽低。本地SSD即可，NVMe更好。文件系统上，建议临时目录放到本机磁盘，不要用tmpfs硬扛ref级运行。

频率策略同样重要。跑分前把CPUFreq governor切到performance，再确认当前频率：

sudo cpupower frequency-set -g performance cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

这两条命令分别负责切调度策略和验证实际生效。cpupower在多数发行版里属于linux-cpupower或linux-tools包，没有的话直接写/sys下的节点也能改。注意performance并不等于锁频，它只是让CPUFreq尽量保持高频；服务器BIOS里的功耗限制、散热策略仍可能把频率拉下来。要做到真正可复现，建议在BIOS里关掉动态超频与节能档，并让散热风扇全速运转，细节在第5章展开。

3.2 写一份最小配置文件

SPEC CPU2017用配置文件控制编译器、优化级别和运行参数。第一次跑，不需要一上来就追peak调优，一份能跑通base的最小配置足够。参考写法如下。

# myconfig.cfg —— 最小可跑的 GCC 配置 CC = gcc CXX = g++ FC = gfortran COPTIMIZE = -O3 -march=native CXXOPTIMIZE = -O3 -march=native FOPTIMIZE = -O3 -march=native # rate 模式副本数，按物理核数改 rate_spin_count = 48 default = base

说明：CC/CXX/FC分别指定C、C++和Fortran编译器，SPEC CPU2017的浮点程序有不少是Fortran写的；COPTIMIZE这一系列键控制base档统一优化选项。-O3是常用优化级；-march=native让编译器按当前CPU指令集生成代码，能比通用版本多榨出几个百分点，但编译产物只在当前CPU架构上可运行，所以只用于本机自测。

rate_spin_count决定rate副本数，设为物理核数或略低即可。不要图好看把它设成逻辑核数×2，副本太多反而增加调度噪声。首次跑通建议先去掉-march=native，用保守选项确认链路没问题，再逐步放开。default = base表示默认跑base档。

3.3 最小可运行命令：test集先验证，ref集再正式跑

进入套件目录，加载环境变量，然后提交任务：

cd /your/SPEC/CPU2017 source shrc runcpu --config=myconfig.cfg --tune=base --size=test intrate

test是最小输入集，每个程序十几秒，几分钟就能把编译、运行、采分整条链路走通，第一次跑必须用它。链路没问题后，再跑正式量级：

runcpu --config=myconfig.cfg --tune=base --size=ref intrate

ref是完整输入集，一个套件在主流服务器上通常要跑数小时；intrate和fprate两个ref合集，常见安排是早上提交、第二天早上收结果。runcpu支持--copies=N临时覆盖副本数，不需要改配置文件；speed模式忽略这个参数，因为speed固定单副本。

这里建议把每个测试跑的中间产物也留一段时间，别跑完就删。后面如果做perf归因或者复核某条编译flag，中间产物是唯一现场。删了就只能重跑ref，代价是数小时起步。

3.4 结果文件在哪里收

正常跑完，结果在result/目录下，有.log、.csv、.rsf三种主要文件。CSV适合脚本化提取，log里能看到每个benchmark的运行日志和编译日志。快速看总分：

cd result grep -h "Est. SPEC" *.log

Est. SPEC是预估总分，完整ref跑完后会给出最终分。如果log里出现INVALID，说明配置或运行存在问题，分数不可用，具体排查方法在第5章的5.5。要养成习惯：每次跑分把log开头那段环境信息一起存档，里面记录了CPU型号、内存、系统版本等关键上下文，分析时不用回头猜。

4. 多CPU横向对比：实验设计、数据提取与perf差异归因

跑分只是拿到原料，横向对比才是这个标题真正值钱的部分。对比做不好，最容易把“CPU差异”和“环境差异”搅在一起，得出来的结论经不起反问。

4.1 公平实验：先定环境矩阵，再动手

多台机器对比，我会先写一张环境矩阵，把不变量写死：同一发行版、同一内核参数、同一编译器版本、同一份配置文件、同样数量和频率的内存、同一块SSD、同样的BIOS功耗策略、超线程开关一致、散热器规格一致。矩阵里任何一项不一致，对比结论就要打折扣。

常见误区是只盯着CPU型号，忽略了内存通道数，结果浮点分数差15%，最后查出来是8通道对2通道，和CPU本身无关。另一个容易被忽视的是后台任务：systemd定时任务、监控agent、别人正跑着的训练任务，都会污染跑分。跑ref之前先top和systemd-analyze看一眼，再停掉无关服务。

每台机器至少跑3次ref，取中位数，不要拿单次分直接对比。单次跑分的波动受温度、后台任务、本轮调度影响，3次取中位数能把噪声压到你能为结论承担责任的程度。

4.2 从CSV提取分数：写几行脚本而不是手抄

result目录里的CSV，每个benchmark一行，列里包含分数。手抄费时且容易抄错，写个几行的提取脚本，按benchmark聚合出中位数：

import csv, glob, statistics, collections scores = collections.defaultdict(list) for path in glob.glob("result/*.csv"): with open(path, newline="") as fp: for row in csv.reader(fp): if len(row) < 8: continue name, score = row[1], row[8] # 列位置以实际CSV表头为准 if name.startswith("6") and score.replace(".", "").isdigit(): base_name = name.replace("_base", "").replace("_peak", "") scores[base_name].append(float(score)) for name, vals in sorted(scores.items()): print(f"{name}\t{statistics.median(vals):.2f}")

逻辑说明：先用glob匹配所有CSV，逐行读取；row[1]是benchmark名，row[8]是分数列，不同小版本的SPEC输出列位置不完全一致，所以脚本里我写死了“以实际CSV表头为准”。采集分数时多做一步：检查该batch里有没有INVALID日志，有就直接剔除，不能混进聚合。

把两台机器各跑3次的分数放到同一张表里，按benchmark对齐，才能看出哪些程序在拉分、哪些在失分。总分差异可能由两三个程序主导，而这些程序往往正好对应你的业务负载特征。

4.3 用perf做单benchmark归因：IPC和访存命中率

总分差出来之后，下一个问题是“差在哪”。我的习惯是挑差异最大的三五个benchmark，用perf做归因。以speed模式的单个整数程序为例：

perf stat -r 3 -e cycles,instructions,branches,branch-misses,\ L1-dcache-load-misses,LLC-load-misses \ ./specspeed -n 1 600.perlbench_s

-r 3表示重复3次，-e指定要采集的计数器。重点关注两个指标：IPC反映单核流水线效率，等于instructions÷cycles；LLC miss率反映访存压力。同一微架构、同频率下IPC低，说明流水线在空转，背后通常是分支预测失效、缓存缺失或依赖等待；跨代CPU比较IPC时要先校正频率与微架构差异，别拿不同架构的IPC直接比大小。

perf在部分发行版上需要root权限，或者调低kernel.perf_event_paranoid。跑归因时建议只跑那一个benchmark，别同时跑整个套件，否则计数器会被其他进程污染。

4.4 业务场景加权：把分数翻译成选型结论

裸分数回答的是“SPEC基准下谁快”，真实采购还要回答“我的业务场景下谁划算”。我一般会给场景配权重，比如虚拟化混部场景intrate权重0.8、fprate 0.2；科学计算反过来intrate 0.3、fprate 0.7；数据库单机事务型业务把intspeed作为主指标。加权只用于排序，不用于精确容量预算；真正的预算要回到业务benchmark，SPEC的定位是初筛。

还有一种做法是把最贴近业务的单个benchmark单独拉出来比。比如编译类业务重点看600.perlbench_s和602.gcc_s这类字符串处理程序；气象类业务重点看621.wrf_s这类浮点密集程序。总分做横向排序，明细做业务映射，两者结合才是完整结论。

5. SPEC CPU2017跑分避坑：五个翻车现场与排查路径

下面这些坑，有环境问题也有方法论问题。每个都按“现象→原因→解决”写，照着排查能省半天。

5.1 分数比同型号低三成：撞上功耗墙

现象：同一型号CPU、同配置，一台机器分数正常，另一台整数分低20%~30%，跑分日志里CPU频率持续走低。

原因：散热器压不住，或BIOS功耗限制、风扇策略没放开，负载一上来就触发降频。SPEC rate几十个副本并发，功耗比普通业务高得多，散热短板被放大。

解决：先固定频率再跑分，用cpupower切performance并在BIOS里锁倍频；监控每个核的scaling_cur_freq，跑分期间每10秒采样一次，如果频率掉到基频以下，说明散热或功耗墙没解除。塔式和机架式服务器要检查风道，别把机器贴着墙放；风扇策略切到全速。功耗受限的机器，比如某些刀片服务器，跑出来的分数只能说明“这台机器的持续性能上限”，不代表CPU本身的算力。

5.2 浮点分数撕裂：内存通道与频率不一致

现象：两台机器fprate差距15%以上，intspeed却只有2%~3%的差异。

原因：浮点程序里像bwaves这类流程序列对内存带宽极敏感，内存从8通道降到2通道，或频率从高配降到低配，直接影响分数；整数单任务对访存带宽的压力相对小，所以差距不明显。

解决：对比前用dmidecode核对内存条数、通道拓扑、运行频率，写入环境矩阵。规范做法是：对比实验中内存配置必须一致，否则浮点分数没有可比性。

5.3 超线程开关导致rate结果畸形

现象：同一机器开启SMT后intrate只提高5%，fprate却能提高20%，和“核心翻倍”的宣传预期完全不符。

原因：rate副本数按逻辑核配时，整数负载的前端宽度已经碰到物理核瓶颈，超线程争抢前端单元；浮点负载的瓶颈更多在访存和运算单元，超线程能利用空隙。

解决：对比时必须固定SMT开关，并在报告里明确写“SMT on/off”。rate副本建议按物理核数设置，不要盲目等于逻辑核数。如果业务本身会开超线程，那两种状态都跑一遍，对比时分开看。

5.4 peak分数虚高：业务场景复现不出来

现象：某份报告peak比base高25%，据此选型后业务上毫无体现。

原因：peak允许对单个benchmark加激进优化flag甚至PGO类调优，这些flag在业务代码的成熟编译链上根本不敢上，或者复现成本极高。

解决：选型对比只用base列；peak分数最多作为理论上限参考。如果一份报告声称可复现，至少要给出完整flag列表，否则默认不可复现。被一份peak单次分带偏选型，亏的不只是采购预算，是半年的业务性能。

5.5 结果被标INVALID：编译配置不完整

现象：runcpu跑完，log里总分前出现了INVALID，分数不能用。

原因：配置文件没有把优化flag和编译器信息完整登记，SPEC的校验认为结果不可复现。常见于直接改默认配置却不补充flags数据，或者编译器版本没写清楚。

解决：按SPEC要求写全配置文件里的编译信息；检查result/下对应的.rsf文件，看校验模块报了哪一项。别抱有“先出分再说”的侥幸，INVALID的分数拿出去做选型是自砸招牌。

6. 让分数站得住：稳定性验证、有效性检查与业务校准

分数跑出来只是第一步，出报告前我只做三件收尾工作。

先验证稳定性。三次复跑取中位数之外，算一遍变异系数CV=标准差÷均值。整数分CV超过2%、浮点分超过3%，基本判定环境不稳，回去查风扇、后台定时任务和调度干扰。有效性检查一句话：log里有没有INVALID，有就是废数据，再好看的分数也不能用。

再做业务校准。SPEC分数是通用负载画像，离真实业务仍有距离。拿业务里典型的负载原型——一个数据库压力样例、一个编译任务——在候选机上同步跑一遍，把业务耗时和对应SPEC分数画个散点，看相关性够不够。我在模拟项目X里遇到过某业务耗时与intspeed相关性明显高于intrate的情况，从此这类场景的选型就不止看rate，也把speed放进主指标。

最后把环境矩阵和中位数一起写进结论。报告里永远写“这台机器在base、ref、3次中位数下的分数，以及当时的完整软硬件配置”，不写单次最好成绩。一次选型差点因为单次peak分拍板，后来用这个流程复核才纠正过来。这几步做完，结论才是能进决策流程的东西。

希望帮到你。

本文还有配套的精品资源，点击获取