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

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

  •  
  •   dangyuluo · 318 天前 · 6067 次点击
    这是一个创建于 318 天前的主题,其中的信息可能已经有所发展或是发生改变。

    我手里有两台台式机,

    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  
       318 天前 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  
       318 天前
    影响因素很多 软件优化 微架构实现
    arm 优势是能耗比 而不是不考虑功耗情况下的性能
    liprais
        3
    liprais  
       318 天前 via iPhone   ❤️ 1
    @matolv 要不是我两个都有我就信了
    ziseyinzi
        4
    ziseyinzi  
       318 天前
    一个 benchmark 的结果只能代表一个 benchmark 的性能,甚至不能代表另一个 benchmark 的性能。编译的结果也只能代表编译的性能。
    lixile
        5
    lixile  
       318 天前
    是 gcc vs ARM64 GCC
    还是交叉编译器 vs ARM64 GCC
    youxiachai
        6
    youxiachai  
       318 天前
    你应该,在算算功耗吧...
    liuxu
        7
    liuxu  
       318 天前
    x86-64 编译 64 位 x86 的目标程序,aarch64 编译 64 位 aarch 的目标程序吗,你说为什么
    dangyuluo
        8
    dangyuluo  
    OP
       318 天前
    @liprais 嗯?请说说见解?我感觉挺有道理的。

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

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

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

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

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

    两句话就 block ,互联网容忍傻逼的能力还是太强了
    liuxu
        22
    liuxu  
       318 天前
    @ragnaroks 我以为的原生支持就是没有虚拟化就算,不是按 fps 算的吧
    ragnaroks
        23
    ragnaroks  
       318 天前
    @liuxu 是这个意思,即对应平台可以直接执行 opcode ,上面那个就只拿 fps 高的说才是原生支持
    hjc4869
        24
    hjc4869  
       318 天前
    楼主方便给更多的细节吗,比如第一个“CPU bench”到底是什么 benchmark ,代码是怎么写的。
    YuiTH
        25
    YuiTH  
       318 天前
    我在 M1 上跑了个 MinGW 的交叉编译 windows 的 Rust 项目,和 11 代 i9 比最终速度是 35s VS 56s 。
    i9 那边的可能不利因素是系统盘不是一块特别好的 SSD ,但是毕竟也是 M2 的 SSD 了。

    Rust Cross Compile 特别方便,建议可以找一些 Rust 的项目交叉编译试试。
    libook
        26
    libook  
       318 天前   ❤️ 2
    两个编译目标使用的指令集不一样,编译器的行为不一样,编译完生成的文件也不一样,不能假定做的是相同的工作。

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

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

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

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

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

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

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

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

    另外 gcc 是挺慢的... arm 目前还算可以了
    cattyhouse
        55
    cattyhouse  
       311 天前 via iPhone
    upgrade your gcc ... ubuntu 20.04 太老了。新版本 gcc 对 arm64 支持更给力。
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2814 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 80ms · UTC 15:59 · PVG 23:59 · LAX 07:59 · JFK 10:59
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.