为什么编译起来 aarch64 比 x86_64 要慢，单核 benchmark 却相反

[dangyuluo]

我手里有两台台式机，

1. i9-9900K 3.6Ghz, 8 核，2 线程 /核，共 16 线程
2. 某厂商 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 固态硬盘）。

请问还有其他什么可能的原因么？谢谢

[matolv]

首先 1.7g 的 armv8 不可能打赢能 boost 5G 的 9900k ，ipc 持平就不错了。即便 m1 也做不到，你不如跑下 geekbench
其次 gcc/icc 等编译器是影响最大的因素，skylake 已经很老了，优化已经到位了，新出的 adl 有新编译器的加持，性能能增加 15%
编译主要为整数运算，这方面 skylake 并不弱，相反 zen2 没比它强多少。新出的 cpu 主要都是增加浮点能力，比如 avx512 和 amx 之类，arm 方面 v9 也要把 128bit 的指令宽度增加到 256bit

[Rheinmetal]

影响因素很多 软件优化 微架构实现
arm 优势是能耗比 而不是不考虑功耗情况下的性能

[liprais]

@matolv 要不是我两个都有我就信了

[ziseyinzi]

一个 benchmark 的结果只能代表一个 benchmark 的性能，甚至不能代表另一个 benchmark 的性能。编译的结果也只能代表编译的性能。

[lixile]

是 gcc vs ARM64 GCC
还是交叉编译器 vs ARM64 GCC

[youxiachai]

你应该,在算算功耗吧...

[liuxu]

x86-64 编译 64 位 x86 的目标程序，aarch64 编译 64 位 aarch 的目标程序吗，你说为什么

[dangyuluo]

@liprais 嗯？请说说见解？我感觉挺有道理的。

@lixile 都是编译本地架构下的程序，没有交叉编译

@liuxu 不会好好说话么？ block 了

[ragnaroks]

不同架构基本不具备可比性，geekbench 上 m1 max 和 5950x 单核分相当接近，实际上嘛，就算考虑到模拟 x86 的损失，也基本处于不可用级别，当然 5950x 的功耗也是压死 m1 了

就如同楼上说的，arm 更考虑低功耗下能尽可能提供一个还不错的性能

[dangyuluo]

功耗和价格不是考虑的重点。是 AWS 找我们合作，希望我们团队转型到他们的云端 aarch64 来做编译，给了我们一台测试样机

我好奇的是，既然主频上 Aarch64 差这么多，为什么算质数居然比 i9 9900K 还要块

[ragnaroks]

白嫖王用 csgo 测试，用 1060 都比 m1max 帧数高，m1max 可是宣传有 3060 的水平（实际理论浮点相当于 1080 ）

[ragnaroks]

@dangyuluo 指令集优化、编译器优化，想不到别的了

[ragnaroks]

想起来几个月前还有一个关于 jm9 国产显卡的争论，jm9 理论性能相当于 1080 （官方也是这么宣传的），结果有人搞到一个实测也就 gtx750

[ch2]

@dangyuluo #10 比赛跑马拉松被编译器优化成 1 米冲刺了

[dangyuluo]

好吧，只能从概念上理解算质数 i9 CPU 没有办法发挥强项。但是还是希望能够得到更多技术上的解释。

[kera0a]

@ragnaroks
你这举例也太离谱了，你咋不用 win 装 MacOS 虚拟机来和 MacOS 原生游戏比帧数呢

[ragnaroks]

@kera0a 冷知识，csgo 原生支持 windows/linux/macOS 平台

[kera0a]

@ragnaroks wow 博德之门 3 才叫原生支持

[ragnaroks]

@kera0a 古墓丽影还是编辑推荐呢，只能完美运行但是帧数不高的都不叫原生支持是吧，BUG 多还需要改各种设置但是帧数刚好能过 60 就算原生支持是吧，那你快去苹果给他们商店的运营开了，30fps 都跑不到的东西也敢编辑推荐

[kera0a]

@ragnaroks 行吧，你说的对

[liuxu]

@dangyuluo 给我整无语了，一个精简指令集编译的东西，一个复杂指令集编译的东西，编译目标都不一样时间自然不一样，没有没多线程编译，开了各开的多少也不说，nvme 同一型号还说的过去。。都是 64G 内存，aarch 的内存能和 x86 的内存能是同一型号么。。内存带宽能一样吗
bench 跑的都是 cpu 指令速度，编译不仅 cpu ，还有磁盘 io ，内存速度，这也能问为什么

注册了七八年的号，年纪也不小了，初中生都理解的逻辑，一个在沙地跑，一个在水泥地跑，为什么一个快一个慢？

两句话就 block ，互联网容忍傻逼的能力还是太强了

[liuxu]

@ragnaroks 我以为的原生支持就是没有虚拟化就算，不是按 fps 算的吧

[ragnaroks]

@liuxu 是这个意思，即对应平台可以直接执行 opcode ，上面那个就只拿 fps 高的说才是原生支持

[hjc4869]

楼主方便给更多的细节吗，比如第一个“CPU bench”到底是什么 benchmark ，代码是怎么写的。

[YuiTH]

我在 M1 上跑了个 MinGW 的交叉编译 windows 的 Rust 项目，和 11 代 i9 比最终速度是 35s VS 56s 。
i9 那边的可能不利因素是系统盘不是一块特别好的 SSD ，但是毕竟也是 M2 的 SSD 了。

Rust Cross Compile 特别方便，建议可以找一些 Rust 的项目交叉编译试试。

[libook]

两个编译目标使用的指令集不一样，编译器的行为不一样，编译完生成的文件也不一样，不能假定做的是相同的工作。

也就是说，两个编译任务没有可比性，不能说明 aarch64 的 CPU 慢，也不能说明 x86_64 的 CPU 快。

就好比是用菜刀切沙瓤瓜，和用武士刀切脆瓤瓜，因为瓜的品种不一样，所以没法评判出哪种刀快、哪种刀慢。

如果真的想使用编译工作来对比 CPU 性能的话，就得控制变量，可以考虑把编译目标设置为相同的，比如用 aarch64 和 x86_64 交叉编译一同个第三方指令集的程序，当编译器在两种架构上的 CPU 使用完全相同的程序方案来编译 的情况下，编译时间就可以比较客观地反应硬件在这个任务上的性能。只不过现实情况下为了充分利用两种指令集的特性，两个平台上交叉编译器很可能也是不一样的。

编译工作和 Benchmark 也是不同的，一般来说 Benchmark 不能代表所有使用场景下硬件的性能表现，所以有些硬件测评都会同时使用 Benchmark 、游戏实测、软件编译来综合说明硬件性能。

[dangyuluo]

@hjc4869 直接运行的 sysbench

[dangyuluo]

@YuiTH 硬盘都是 PCIE 4.0x 的 NVME ，肯定不是瓶颈

[461da73c]

@libook 这不搞笑吗？不都是编译同一份代码，最后的 binary 的逻辑也是一样的，怎么就没有可比性。

我的测试也是一样的，x64 比 aarch64 编译快很多很多。
只能说 aarch64 还是太拉胯。

[jedihy]

@461da73c 当然不一样。编译出的二进制不一样，二进制大小都不一样。编译项目里面你怎么知道没有类似#ifdef ARM64 这样子的东西。

[461da73c]

@jedihy 难道整个工程都是 #ifdef ？

[jedihy]

@461da73c 就不是 apples to apples 的比较，没有什么意义。项目里面有些什么，只有楼主知道。

[ScepterZ]

更换编译机，是编译自己这个平台的程序吗，还是编译 Java 之类的，感觉如果目标也不同的话，确实本身编译难度就不一样（但是如果相同的话，有一方就吃亏了

看到你说没交叉编译，可是如果不是编译 java 这种，你编译机换平台了，运行的机器岂不是也得换

[shayuvpn0001]

@dangyuluo 盲猜 ARM 架构寄存器多为优势一，不同于 x86 的内存访问机制为优势二。

[shayuvpn0001]

@dangyuluo 上面回复应该是取反。。。

x86 厉害的话，首当其冲是主频高，其次还要比较 L2 和 L3 的 Cache 大小，命中率高的话，性能提升很显著。然后 AWS 的这个 1.7G AArch64 是物理机么？还是隔了一层虚拟化的玩意儿？

[ungrown]

@461da73c #31
你这叫问的什么话，因为架构不同，所以有可能支持的功能不同，说不定#ifdef 里面就有禁用 /略过某些功能模块，这编译的工作量不就大相径庭了吗

[hjc4869]

@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

[461da73c]

@ungrown 还大相径庭，无知无畏。

[secondwtq]

同怀疑 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

[secondwtq]

另外我这个数据跟#37 的比也有点离谱 ... 感觉这个 benchmark 就不太靠谱
整个 GB5 或者 Phoronix 不行么，再不济 Blender Benchmark 也行

[dangyuluo]

@shayuvpn0001 AWS 给的机器有 Aarch64 的 CPU ，没有虚拟层。

另外“首当其冲”不是这么用的

[secondwtq]

重新下了个 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 出来的，究竟拉出什么代码还不一定呢

[dangyuluo]

@secondwtq
@hjc4869

忘了说了，以上测试两台机器均是在 Ubuntu 20.04 Docker 环境下进行测试的，性能比直接跑在 host 上相比确实有损失，不过我更关注的是对比数据。

刚在 host 上跑了下`sysbench cpu run`
1. x86_64, events per second: 1640.55
2. aarch64, events per second: 1992.70

还是 aarch64 机器快

[dangyuluo]

@hjc4869 你这个“随便一跑”的 x86 机器也太快了吧。。这是什么 CPU

[secondwtq]

@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 了？

[dangyuluo]

@secondwtq 并没有设置 CPU 配额，所以我也有点惊讶 Docker 损失居然这么大，按照我的理解只是 namespace 不同呀

[ungrown]

@461da73c #38
你自己的言行正是诠释了这四个字
编译过程是可以选用、禁用功能模块的，这你不知道？
如果少了几个模块，那编译时就直接没了这几个模块的工作量，你说差距大不大？
因为架构不同所以编译时采用不同的模板来分支处理，导致整个编译运算量出现差异，这种事你是真没见过？

[AlexaZhou]

国内程序员压力太大了，讨论个啥都能吵起来

[dreamramon]

我之前做了大概几十组编译对比测试（公司的内部项目和一堆 github 的开源项目），都是默认配置，下下来不会再去手工改配置为 aarch 做优化，如果要那样做工作量太大了，而且很多开源项目里面一堆 ifdef ，哪里改的过来。然后都是 x86 快，没有一次 aarch64 胜出的。
凭心而论，现在的历史环境，还有一大堆软件代码没有开始针对 aarch64 做优化。如果是做业务的部门，可能真心没有资源去搞这些。

[LANB0]

好奇哪家出了 32 核的 arm PC

[redsonic]

除了单核性能外还是看看 ARM64 那双位数的 NUMA 把，不改架构不改代码的话还不如 intel 的本子性能高。

[hjc4869]

@dangyuluo 5950X, WSL2

[hjc4869]

拿 3.7 GHz 左右的 1130G7 跑了一下也有 3242.27

[james122333]

https://openbenchmarking.org/test/pts/sysbench

另外 gcc 是挺慢的... arm 目前还算可以了

[cattyhouse]

upgrade your gcc ... ubuntu 20.04 太老了。新版本 gcc 对 arm64 支持更给力。