我手里有两台台式机,
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 支持更给力。
|