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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@ragnaroks 行吧，你说的对

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

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

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

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

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

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

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

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

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

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

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

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

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

@hjc4869 直接运行的 sysbench

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

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

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

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

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

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

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

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

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

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

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

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

@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

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

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

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

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

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

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

@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 机器快

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

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

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

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

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

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

好奇哪家出了 32 核的 arm PC

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

@dangyuluo 5950X, WSL2

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

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

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

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