V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Distributions
Ubuntu
Fedora
CentOS
中文资源站
网易开源镜像站
dangyuluo
V2EX  ›  Linux

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

  •  
  •   dangyuluo · 2022-01-14 07:18:10 +08:00 · 7448 次点击
    这是一个创建于 1031 天前的主题,其中的信息可能已经有所发展或是发生改变。

    我手里有两台台式机,

    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 固态硬盘)。

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

    55 条回复    2022-01-21 03:33:33 +08:00
    matolv
        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
    Rheinmetal
        2
    Rheinmetal  
       2022-01-14 08:29:21 +08:00
    影响因素很多 软件优化 微架构实现
    arm 优势是能耗比 而不是不考虑功耗情况下的性能
    liprais
        3
    liprais  
       2022-01-14 08:48:03 +08:00 via iPhone   ❤️ 1
    @matolv 要不是我两个都有我就信了
    ziseyinzi
        4
    ziseyinzi  
       2022-01-14 08:48:12 +08:00
    一个 benchmark 的结果只能代表一个 benchmark 的性能,甚至不能代表另一个 benchmark 的性能。编译的结果也只能代表编译的性能。
    lixile
        5
    lixile  
       2022-01-14 10:05:38 +08:00
    是 gcc vs ARM64 GCC
    还是交叉编译器 vs ARM64 GCC
    youxiachai
        6
    youxiachai  
       2022-01-14 10:24:45 +08:00
    你应该,在算算功耗吧...
    liuxu
        7
    liuxu  
       2022-01-14 11:02:57 +08:00
    x86-64 编译 64 位 x86 的目标程序,aarch64 编译 64 位 aarch 的目标程序吗,你说为什么
    dangyuluo
        8
    dangyuluo  
    OP
       2022-01-14 12:19:24 +08:00
    @liprais 嗯?请说说见解?我感觉挺有道理的。

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

    @liuxu 不会好好说话么? block 了
    ragnaroks
        9
    ragnaroks  
       2022-01-14 12:19:39 +08:00
    不同架构基本不具备可比性,geekbench 上 m1 max 和 5950x 单核分相当接近,实际上嘛,就算考虑到模拟 x86 的损失,也基本处于不可用级别,当然 5950x 的功耗也是压死 m1 了

    就如同楼上说的,arm 更考虑低功耗下能尽可能提供一个还不错的性能
    dangyuluo
        10
    dangyuluo  
    OP
       2022-01-14 12:22:34 +08:00
    功耗和价格不是考虑的重点。是 AWS 找我们合作,希望我们团队转型到他们的云端 aarch64 来做编译,给了我们一台测试样机

    我好奇的是,既然主频上 Aarch64 差这么多,为什么算质数居然比 i9 9900K 还要块
    ragnaroks
        11
    ragnaroks  
       2022-01-14 12:22:47 +08:00
    白嫖王用 csgo 测试,用 1060 都比 m1max 帧数高,m1max 可是宣传有 3060 的水平(实际理论浮点相当于 1080 )
    ragnaroks
        12
    ragnaroks  
       2022-01-14 12:23:40 +08:00
    @dangyuluo 指令集优化、编译器优化,想不到别的了
    ragnaroks
        13
    ragnaroks  
       2022-01-14 12:26:36 +08:00
    想起来几个月前还有一个关于 jm9 国产显卡的争论,jm9 理论性能相当于 1080 (官方也是这么宣传的),结果有人搞到一个实测也就 gtx750
    ch2
        14
    ch2  
       2022-01-14 12:26:53 +08:00
    @dangyuluo #10 比赛跑马拉松被编译器优化成 1 米冲刺了
    dangyuluo
        15
    dangyuluo  
    OP
       2022-01-14 12:30:01 +08:00
    好吧,只能从概念上理解算质数 i9 CPU 没有办法发挥强项。但是还是希望能够得到更多技术上的解释。
    kera0a
        16
    kera0a  
       2022-01-14 12:30:14 +08:00 via iPhone
    @ragnaroks
    你这举例也太离谱了,你咋不用 win 装 MacOS 虚拟机来和 MacOS 原生游戏比帧数呢
    ragnaroks
        17
    ragnaroks  
       2022-01-14 12:32:56 +08:00
    @kera0a 冷知识,csgo 原生支持 windows/linux/macOS 平台
    kera0a
        18
    kera0a  
       2022-01-14 12:39:12 +08:00 via iPhone
    @ragnaroks wow 博德之门 3 才叫原生支持
    ragnaroks
        19
    ragnaroks  
       2022-01-14 12:46:17 +08:00
    @kera0a 古墓丽影还是编辑推荐呢,只能完美运行但是帧数不高的都不叫原生支持是吧,BUG 多还需要改各种设置但是帧数刚好能过 60 就算原生支持是吧,那你快去苹果给他们商店的运营开了,30fps 都跑不到的东西也敢编辑推荐
    kera0a
        20
    kera0a  
       2022-01-14 12:47:21 +08:00 via iPhone
    @ragnaroks 行吧,你说的对
    liuxu
        21
    liuxu  
       2022-01-14 12:53:04 +08:00
    @dangyuluo 给我整无语了,一个精简指令集编译的东西,一个复杂指令集编译的东西,编译目标都不一样时间自然不一样,没有没多线程编译,开了各开的多少也不说,nvme 同一型号还说的过去。。都是 64G 内存,aarch 的内存能和 x86 的内存能是同一型号么。。内存带宽能一样吗
    bench 跑的都是 cpu 指令速度,编译不仅 cpu ,还有磁盘 io ,内存速度,这也能问为什么

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

    两句话就 block ,互联网容忍傻逼的能力还是太强了
    liuxu
        22
    liuxu  
       2022-01-14 13:08:37 +08:00
    @ragnaroks 我以为的原生支持就是没有虚拟化就算,不是按 fps 算的吧
    ragnaroks
        23
    ragnaroks  
       2022-01-14 13:13:28 +08:00
    @liuxu 是这个意思,即对应平台可以直接执行 opcode ,上面那个就只拿 fps 高的说才是原生支持
    hjc4869
        24
    hjc4869  
       2022-01-14 13:23:59 +08:00
    楼主方便给更多的细节吗,比如第一个“CPU bench”到底是什么 benchmark ,代码是怎么写的。
    YuiTH
        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 的项目交叉编译试试。
    libook
        26
    libook  
       2022-01-14 13:50:02 +08:00   ❤️ 2
    两个编译目标使用的指令集不一样,编译器的行为不一样,编译完生成的文件也不一样,不能假定做的是相同的工作。

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

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

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

    编译工作和 Benchmark 也是不同的,一般来说 Benchmark 不能代表所有使用场景下硬件的性能表现,所以有些硬件测评都会同时使用 Benchmark 、游戏实测、软件编译来综合说明硬件性能。
    dangyuluo
        27
    dangyuluo  
    OP
       2022-01-14 16:15:23 +08:00
    @hjc4869 直接运行的 sysbench
    dangyuluo
        28
    dangyuluo  
    OP
       2022-01-14 16:16:21 +08:00
    @YuiTH 硬盘都是 PCIE 4.0x 的 NVME ,肯定不是瓶颈
    461da73c
        29
    461da73c  
       2022-01-14 16:21:56 +08:00
    @libook 这不搞笑吗?不都是编译同一份代码,最后的 binary 的逻辑也是一样的,怎么就没有可比性。

    我的测试也是一样的,x64 比 aarch64 编译快很多很多。
    只能说 aarch64 还是太拉胯。
    jedihy
        30
    jedihy  
       2022-01-14 16:28:40 +08:00
    @461da73c 当然不一样。编译出的二进制不一样,二进制大小都不一样。编译项目里面你怎么知道没有类似#ifdef ARM64 这样子的东西。
    461da73c
        31
    461da73c  
       2022-01-14 16:29:41 +08:00
    @jedihy 难道整个工程都是 #ifdef ?
    jedihy
        32
    jedihy  
       2022-01-14 16:37:29 +08:00
    @461da73c 就不是 apples to apples 的比较,没有什么意义。项目里面有些什么,只有楼主知道。
    ScepterZ
        33
    ScepterZ  
       2022-01-14 16:49:54 +08:00
    更换编译机,是编译自己这个平台的程序吗,还是编译 Java 之类的,感觉如果目标也不同的话,确实本身编译难度就不一样(但是如果相同的话,有一方就吃亏了

    看到你说没交叉编译,可是如果不是编译 java 这种,你编译机换平台了,运行的机器岂不是也得换
    shayuvpn0001
        34
    shayuvpn0001  
       2022-01-14 19:40:36 +08:00
    @dangyuluo 盲猜 ARM 架构寄存器多为优势一,不同于 x86 的内存访问机制为优势二。
    shayuvpn0001
        35
    shayuvpn0001  
       2022-01-14 19:44:31 +08:00
    @dangyuluo 上面回复应该是取反。。。

    x86 厉害的话,首当其冲是主频高,其次还要比较 L2 和 L3 的 Cache 大小,命中率高的话,性能提升很显著。然后 AWS 的这个 1.7G AArch64 是物理机么?还是隔了一层虚拟化的玩意儿?
    ungrown
        36
    ungrown  
       2022-01-14 20:32:30 +08:00
    @461da73c #31
    你这叫问的什么话,因为架构不同,所以有可能支持的功能不同,说不定#ifdef 里面就有禁用 /略过某些功能模块,这编译的工作量不就大相径庭了吗
    hjc4869
        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
    461da73c
        38
    461da73c  
       2022-01-15 00:39:04 +08:00 via Android
    @ungrown 还大相径庭,无知无畏。
    secondwtq
        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
    secondwtq
        40
    secondwtq  
       2022-01-15 02:38:59 +08:00
    另外我这个数据跟#37 的比也有点离谱 ... 感觉这个 benchmark 就不太靠谱
    整个 GB5 或者 Phoronix 不行么,再不济 Blender Benchmark 也行
    dangyuluo
        41
    dangyuluo  
    OP
       2022-01-15 03:16:22 +08:00
    @shayuvpn0001 AWS 给的机器有 Aarch64 的 CPU ,没有虚拟层。

    另外“首当其冲”不是这么用的
    secondwtq
        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 出来的,究竟拉出什么代码还不一定呢
    dangyuluo
        43
    dangyuluo  
    OP
       2022-01-15 03:35:01 +08:00
    @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
        44
    dangyuluo  
    OP
       2022-01-15 03:36:20 +08:00
    @hjc4869 你这个“随便一跑”的 x86 机器也太快了吧。。这是什么 CPU
    secondwtq
        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 了?
    dangyuluo
        46
    dangyuluo  
    OP
       2022-01-15 05:26:49 +08:00
    @secondwtq 并没有设置 CPU 配额,所以我也有点惊讶 Docker 损失居然这么大,按照我的理解只是 namespace 不同呀
    ungrown
        47
    ungrown  
       2022-01-15 09:55:50 +08:00
    @461da73c #38
    你自己的言行正是诠释了这四个字
    编译过程是可以选用、禁用功能模块的,这你不知道?
    如果少了几个模块,那编译时就直接没了这几个模块的工作量,你说差距大不大?
    因为架构不同所以编译时采用不同的模板来分支处理,导致整个编译运算量出现差异,这种事你是真没见过?
    AlexaZhou
        48
    AlexaZhou  
       2022-01-15 10:10:32 +08:00
    国内程序员压力太大了,讨论个啥都能吵起来
    dreamramon
        49
    dreamramon  
       2022-01-15 11:08:34 +08:00
    我之前做了大概几十组编译对比测试(公司的内部项目和一堆 github 的开源项目),都是默认配置,下下来不会再去手工改配置为 aarch 做优化,如果要那样做工作量太大了,而且很多开源项目里面一堆 ifdef ,哪里改的过来。然后都是 x86 快,没有一次 aarch64 胜出的。
    凭心而论,现在的历史环境,还有一大堆软件代码没有开始针对 aarch64 做优化。如果是做业务的部门,可能真心没有资源去搞这些。
    LANB0
        50
    LANB0  
       2022-01-15 11:14:05 +08:00
    好奇哪家出了 32 核的 arm PC
    redsonic
        51
    redsonic  
       2022-01-15 15:57:02 +08:00
    除了单核性能外还是看看 ARM64 那双位数的 NUMA 把,不改架构不改代码的话还不如 intel 的本子性能高。
    hjc4869
        52
    hjc4869  
       2022-01-15 18:59:42 +08:00
    @dangyuluo 5950X, WSL2
    hjc4869
        53
    hjc4869  
       2022-01-16 01:05:01 +08:00
    拿 3.7 GHz 左右的 1130G7 跑了一下也有 3242.27
    james122333
        54
    james122333  
       2022-01-17 19:21:13 +08:00
    https://openbenchmarking.org/test/pts/sysbench

    另外 gcc 是挺慢的... arm 目前还算可以了
    cattyhouse
        55
    cattyhouse  
       2022-01-21 03:33:33 +08:00 via iPhone
    upgrade your gcc ... ubuntu 20.04 太老了。新版本 gcc 对 arm64 支持更给力。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1958 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 24ms · UTC 00:33 · PVG 08:33 · LAX 16:33 · JFK 19:33
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.