为什么编译起来 aarch64 比 x86_64 要慢，单核 benchmark 却相反
dangyuluo · 2022-01-14 07:18:10 +08:00 · 7471 次点击这是一个创建于 1044 天前的主题，其中的信息可能已经有所发展或是发生改变。
我手里有两台台式机，
- i9-9900K 3.6Ghz, 8 核，2 线程 /核，共 16 线程
- 某厂商 aarch64 CPU 1.7Ghz, 32 核，1 线程 /核，共 32 线程
CPU bench 结果：
x86_64: events per second: 637.69
aarch64: events per second: 745.31
看起来 Aarch64 机器算质数会更快一些，但实际上编译 CMake 来看：
x86_64: 1m12.78s
aarch64: 1m20.135s
另一个项目更加明显
x86_64: 5m14s
aarch64: 9m9s
显然 x86_64 机器会更快。我已经尽可能排除两台机器其他变量的干扰（均有 64GB 内存，NVME 固态硬盘）。
请问还有其他什么可能的原因么？谢谢
 |
1
matolv 2022-01-14 07:50:12 +08:00 via iPhone
首先 1.7g 的 armv8 不可能打赢能 boost 5G 的 9900k ，ipc 持平就不错了。即便 m1 也做不到，你不如跑下 geekbench
其次 gcc/icc 等编译器是影响最大的因素，skylake 已经很老了，优化已经到位了，新出的 adl 有新编译器的加持，性能能增加 15% 编译主要为整数运算，这方面 skylake 并不弱，相反 zen2 没比它强多少。新出的 cpu 主要都是增加浮点能力，比如 avx512 和 amx 之类，arm 方面 v9 也要把 128bit 的指令宽度增加到 256bit |
 |
2
Rheinmetal 2022-01-14 08:29:21 +08:00
影响因素很多 软件优化 微架构实现
arm 优势是能耗比 而不是不考虑功耗情况下的性能 |
 |
4
ziseyinzi 2022-01-14 08:48:12 +08:00
一个 benchmark 的结果只能代表一个 benchmark 的性能，甚至不能代表另一个 benchmark 的性能。编译的结果也只能代表编译的性能。
|
 |
5
lixile 2022-01-14 10:05:38 +08:00
是 gcc vs ARM64 GCC
还是交叉编译器 vs ARM64 GCC |
 |
6
youxiachai 2022-01-14 10:24:45 +08:00
你应该,在算算功耗吧...
|
 |
7
liuxu 2022-01-14 11:02:57 +08:00
x86-64 编译 64 位 x86 的目标程序，aarch64 编译 64 位 aarch 的目标程序吗，你说为什么
|
 |
8
dangyuluo OP |
 |
9
ragnaroks 2022-01-14 12:19:39 +08:00
不同架构基本不具备可比性，geekbench 上 m1 max 和 5950x 单核分相当接近，实际上嘛，就算考虑到模拟 x86 的损失，也基本处于不可用级别，当然 5950x 的功耗也是压死 m1 了
就如同楼上说的，arm 更考虑低功耗下能尽可能提供一个还不错的性能 |
|
10
dangyuluo OP 功耗和价格不是考虑的重点。是 AWS 找我们合作，希望我们团队转型到他们的云端 aarch64 来做编译，给了我们一台测试样机
我好奇的是，既然主频上 Aarch64 差这么多，为什么算质数居然比 i9 9900K 还要块 |
|
11
ragnaroks 2022-01-14 12:22:47 +08:00
白嫖王用 csgo 测试，用 1060 都比 m1max 帧数高，m1max 可是宣传有 3060 的水平（实际理论浮点相当于 1080 ）
|
|
13
ragnaroks 2022-01-14 12:26:36 +08:00
想起来几个月前还有一个关于 jm9 国产显卡的争论，jm9 理论性能相当于 1080 （官方也是这么宣传的），结果有人搞到一个实测也就 gtx750
|
|
15
dangyuluo OP 好吧，只能从概念上理解算质数 i9 CPU 没有办法发挥强项。但是还是希望能够得到更多技术上的解释。
|
 |
16
kera0a 2022-01-14 12:30:14 +08:00 via iPhone
@ragnaroks
你这举例也太离谱了，你咋不用 win 装 MacOS 虚拟机来和 MacOS 原生游戏比帧数呢 |
|
19
ragnaroks 2022-01-14 12:46:17 +08:00
@kera0a 古墓丽影还是编辑推荐呢，只能完美运行但是帧数不高的都不叫原生支持是吧，BUG 多还需要改各种设置但是帧数刚好能过 60 就算原生支持是吧，那你快去苹果给他们商店的运营开了，30fps 都跑不到的东西也敢编辑推荐
|
|
21
liuxu 2022-01-14 12:53:04 +08:00
@dangyuluo 给我整无语了，一个精简指令集编译的东西，一个复杂指令集编译的东西，编译目标都不一样时间自然不一样，没有没多线程编译，开了各开的多少也不说，nvme 同一型号还说的过去。。都是 64G 内存，aarch 的内存能和 x86 的内存能是同一型号么。。内存带宽能一样吗
bench 跑的都是 cpu 指令速度，编译不仅 cpu ，还有磁盘 io ，内存速度，这也能问为什么 注册了七八年的号，年纪也不小了，初中生都理解的逻辑，一个在沙地跑，一个在水泥地跑，为什么一个快一个慢？ 两句话就 block ，互联网容忍傻逼的能力还是太强了 |
 |
24
hjc4869 2022-01-14 13:23:59 +08:00
楼主方便给更多的细节吗，比如第一个“CPU bench”到底是什么 benchmark ，代码是怎么写的。
|
 |
25
YuiTH 2022-01-14 13:35:18 +08:00
我在 M1 上跑了个 MinGW 的交叉编译 windows 的 Rust 项目，和 11 代 i9 比最终速度是 35s VS 56s 。
i9 那边的可能不利因素是系统盘不是一块特别好的 SSD ，但是毕竟也是 M2 的 SSD 了。 Rust Cross Compile 特别方便，建议可以找一些 Rust 的项目交叉编译试试。 |
 |
26
libook 2022-01-14 13:50:02 +08:00  2
两个编译目标使用的指令集不一样，编译器的行为不一样，编译完生成的文件也不一样，不能假定做的是相同的工作。
也就是说，两个编译任务没有可比性，不能说明 aarch64 的 CPU 慢，也不能说明 x86_64 的 CPU 快。 就好比是用菜刀切沙瓤瓜，和用武士刀切脆瓤瓜，因为瓜的品种不一样，所以没法评判出哪种刀快、哪种刀慢。 如果真的想使用编译工作来对比 CPU 性能的话，就得控制变量，可以考虑把编译目标设置为相同的，比如用 aarch64 和 x86_64 交叉编译一同个第三方指令集的程序，当编译器在两种架构上的 CPU 使用完全相同的程序方案来编译 的情况下，编译时间就可以比较客观地反应硬件在这个任务上的性能。只不过现实情况下为了充分利用两种指令集的特性，两个平台上交叉编译器很可能也是不一样的。 编译工作和 Benchmark 也是不同的，一般来说 Benchmark 不能代表所有使用场景下硬件的性能表现，所以有些硬件测评都会同时使用 Benchmark 、游戏实测、软件编译来综合说明硬件性能。 |
 |
29
461da73c 2022-01-14 16:21:56 +08:00
@libook 这不搞笑吗？不都是编译同一份代码，最后的 binary 的逻辑也是一样的，怎么就没有可比性。
我的测试也是一样的，x64 比 aarch64 编译快很多很多。 只能说 aarch64 还是太拉胯。 |
 |
30
jedihy 2022-01-14 16:28:40 +08:00
@461da73c 当然不一样。编译出的二进制不一样，二进制大小都不一样。编译项目里面你怎么知道没有类似#ifdef ARM64 这样子的东西。
|
 |
33
ScepterZ 2022-01-14 16:49:54 +08:00
更换编译机，是编译自己这个平台的程序吗，还是编译 Java 之类的，感觉如果目标也不同的话，确实本身编译难度就不一样（但是如果相同的话，有一方就吃亏了
看到你说没交叉编译，可是如果不是编译 java 这种，你编译机换平台了，运行的机器岂不是也得换 |
 |
34
shayuvpn0001 2022-01-14 19:40:36 +08:00
@dangyuluo 盲猜 ARM 架构寄存器多为优势一，不同于 x86 的内存访问机制为优势二。
|
|
35
shayuvpn0001 2022-01-14 19:44:31 +08:00
@dangyuluo 上面回复应该是取反。。。
x86 厉害的话，首当其冲是主频高，其次还要比较 L2 和 L3 的 Cache 大小，命中率高的话，性能提升很显著。然后 AWS 的这个 1.7G AArch64 是物理机么？还是隔了一层虚拟化的玩意儿？ |
 |
36
ungrown 2022-01-14 20:32:30 +08:00
@461da73c #31
你这叫问的什么话，因为架构不同，所以有可能支持的功能不同，说不定#ifdef 里面就有禁用 /略过某些功能模块，这编译的工作量不就大相径庭了吗 |
|
37
hjc4869 2022-01-14 20:53:41 +08:00
@dangyuluo 具体运行 sysbench 的参数？如果是默认参数（ sysbench cpu run ）的话这 i9 得分也太低了。我 x86 机器随便一跑都是 5268.14
> sysbench cpu run sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3) Running the test with following options: Number of threads: 1 Initializing random number generator from current time Prime numbers limit: 10000 Initializing worker threads... Threads started! CPU speed: events per second: 5268.14 General statistics: total time: 10.0002s total number of events: 52685 Latency (ms): min: 0.18 avg: 0.19 max: 0.35 95th percentile: 0.19 sum: 9995.13 Threads fairness: events (avg/stddev): 52685.0000/0.00 execution time (avg/stddev): 9.9951/0.00 |
 |
39
secondwtq 2022-01-15 02:36:49 +08:00
同怀疑 9900k 数据有问题，我这 8500:
sysbench cpu --num-threads=1 run sysbench 1.0.20 (using system LuaJIT 2.0.5) ... Prime numbers limit: 10000 ... CPU speed: events per second: 1378.00 |
|
40
secondwtq 2022-01-15 02:38:59 +08:00
另外我这个数据跟#37 的比也有点离谱 ... 感觉这个 benchmark 就不太靠谱
整个 GB5 或者 Phoronix 不行么，再不济 Blender Benchmark 也行 |
|
41
dangyuluo OP |
|
42
secondwtq 2022-01-15 03:26:55 +08:00
重新下了个 VTune ，进去一个大大的 div %rcx 真是开幕雷击 ...
可能能解释 #37 的数据，因为在某乎上对 #37 有印象，用的应该是 AMD 。然后翻一下 uops.info 就知道了： https://uops.info/table.html?search=div&cb_lat=on&cb_tp=on&cb_uops=on&cb_ports=on&cb_SKL=on&cb_ZEN3=on&cb_measurements=on&cb_doc=on&cb_base=on https://www.realworldtech.com/forum/?threadid=200021&curpostid=200021 但是楼主的数据还是很神秘。不过他这个貌似是 LuaJIT 给 JIT 出来的，究竟拉出什么代码还不一定呢 |
|
43
dangyuluo OP |
|
45
secondwtq 2022-01-15 03:44:10 +08:00
@dangyuluo #43
1640 还比较科学，跟我这个数据比差不多就是频率的比利关系 我感觉你这个 benchmark 测试的主要是 sqrt 和 idiv 的性能 (源码应该是 https://github.com/akopytov/sysbench/blob/df89d34c410a2277e19f77e47e535d0890b2029b/src/lua/prime-test.lua#L15-L30 )，SKL 的 idiv 确实不太行。LuaJIT 要是搞个库进来可能会好一点（或者换 ICL 之后的 u ）。 另外 Docker 性能损失这么大是什么原理，设置了 cpu-quota 了？ |
|
46
dangyuluo OP @secondwtq 并没有设置 CPU 配额，所以我也有点惊讶 Docker 损失居然这么大，按照我的理解只是 namespace 不同呀
|
|
47
ungrown 2022-01-15 09:55:50 +08:00
@461da73c #38
你自己的言行正是诠释了这四个字 编译过程是可以选用、禁用功能模块的，这你不知道？ 如果少了几个模块，那编译时就直接没了这几个模块的工作量，你说差距大不大？ 因为架构不同所以编译时采用不同的模板来分支处理，导致整个编译运算量出现差异，这种事你是真没见过？ |
 |
48
AlexaZhou 2022-01-15 10:10:32 +08:00
国内程序员压力太大了，讨论个啥都能吵起来
|
 |
49
dreamramon 2022-01-15 11:08:34 +08:00
我之前做了大概几十组编译对比测试（公司的内部项目和一堆 github 的开源项目），都是默认配置，下下来不会再去手工改配置为 aarch 做优化，如果要那样做工作量太大了，而且很多开源项目里面一堆 ifdef ，哪里改的过来。然后都是 x86 快，没有一次 aarch64 胜出的。
凭心而论，现在的历史环境，还有一大堆软件代码没有开始针对 aarch64 做优化。如果是做业务的部门，可能真心没有资源去搞这些。 |
 |
50
LANB0 2022-01-15 11:14:05 +08:00
好奇哪家出了 32 核的 arm PC
|
 |
51
redsonic 2022-01-15 15:57:02 +08:00
除了单核性能外还是看看 ARM64 那双位数的 NUMA 把，不改架构不改代码的话还不如 intel 的本子性能高。
|
|
53
hjc4869 2022-01-16 01:05:01 +08:00
拿 3.7 GHz 左右的 1130G7 跑了一下也有 3242.27
|
 |
54
james122333 2022-01-17 19:21:13 +08:00
|
 |
55
cattyhouse 2022-01-21 03:33:33 +08:00 via iPhone
upgrade your gcc ... ubuntu 20.04 太老了。新版本 gcc 对 arm64 支持更给力。
|
Select Language