为什么编译起来 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 固态硬盘）。

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

[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 也行