一条mov如何让CPU干等139毫秒asm-hall-of-shame PCIe/MMIO慢速GPU寄存器寻宝指南【免费下载链接】asm-hall-of-shameRacing to the bottom of CPU performance项目地址: https://gitcode.com/gh_mirrors/as/asm-hall-of-shameasm-hall-of-shame 是一个开源的指令延迟倒数榜项目别的性能分析都在想办法让代码跑得更快它反其道而行专门在 x86 上寻找单条指令能有多慢。其中最经典的案例是一条平平无奇的 4 字节movl内存读取竟让 CPU 干等了整整139 毫秒443,937,696 个周期——罪魁祸首是 PCIe 总线上一个连文档都没写的 GPU 慢速寄存器。️图中从最慢的fxrstor641980亿周期到最快的nop1 周期完整呈现了 asm-hall-of-shame 的 x86 单指令延迟排行一、什么是 asm-hall-of-shameCPU 性能的耻辱榜传统指令延迟研究关注性能优化而这个项目的目标正好相反找到单条指令性能的绝对地板。它的规则很严格见 README.md指令可以任意搭建前置环境但只有一条指令参与计分rep movs、pause这类可中断指令直接淘汰成绩按 CPU 基础频率归一化且所有平台必须是出厂原装配置榜单的起点是nop1 个周期终点则是当前冠军fxrstor64198,002,498,236 个周期约合 62 秒。中间跨越了十几个数量级——这正是寻宝的乐趣所在。二、139毫秒的 mov一次普通的 4 字节读取主角代码在mov/mov.c核心操作其实非常朴素#define PHYS_ADDR 0xfcc003b0UL // 位于 Radeon GPU 的 MMIO 空间 void *page mmap(NULL, PAGE_SIZE, PROT_READ, MAP_SHARED, fd, (off_t)PAGE_BASE); uint64_t t MEASURE_PTR(movl (%%rdi), %%esi\n\t, reg); // 计时一次 movl程序通过/dev/mem以O_SYNC MAP_SHARED映射物理页确保这是一次无缓存、强序的读取。于是这条movl的真实旅程是CPU 发起读请求 → PCIe 根复合体 → 交换链路 → GPU 端点 → 等 GPU 应答 → 数据回传 → 指令才能退休也就是说CPU 必须老老实实等完整个 PCIe 往返。而这个地址0xfcc003b0恰好落在 Radeon GPU 的 MMIO 空间里对应一个** undocumented无文档的 GPU 寄存器**——那近 5 亿个周期的卡顿很可能反映了 GPU 深处某个缓慢的内部状态机或跨时钟域逻辑。 有个容易踩的坑据mov/README.md记录这片区域的高延迟可能要先访问某个邻近地址预热后才会显现需要用 mmiotic 工具做一次 prime 探测否则可能测不出满血延迟。三、为什么 MMIO 读取这么慢看宽度倍增的寻宝梯度PCIe 上 MMIO 的天然粒度是32 位一个 dword而且 CPU 读取 MMIO 无法发了就忘——它必须等 completion 回来。于是读得越多排队的时间就越长指令读取宽度拆分成的 dword 事务耗时movl 0xfcc003b0, %esi4 字节1139.01 msmovq 0xfcc003b0, %rax8 字节2277.97 msvmovdqu ..., %xmm016 字节4555.66 msvmovdqu ..., %ymm032 字节81.11 svmovdqu 0xfcc003b1, %ymm0未对齐32 字节91.39 s几个有趣的细节64 位的movq和 128/256 位的vmovdqu根本不是合法的 MMIO 访问宽度但硬件有求必应老老实实拆成连续多个 dword 事务未对齐版本最骚地址偏移 1 字节后32 字节窗口横跨 9 个 dword 槽位多一个事务就多排一次队详见vmovdqu_ymm_unaligned/README.md各案例源码分别在mov/mov.c、mov_rax/mov_rax.c、vmovdqu_xmm/vmovdqu_xmm.c等目录下四、从 512 字节到 62 秒冠军 fxrstor64 与锤芯策略沿着同一条路继续放大fxrstor64指令一次从 MMIO 拉取512 字节的 FPU/MMX/XMM 状态镜像——512 个字节每个都要穿越 PCIe 才能退休单条指令就耗掉23.35 秒fxrstor64/README.md。当前榜单冠军lock_hammer_fxrstor64更进一步lock_hammer_fxrstor64/README.mdCPU 0 执行 512 字节的fxrstor64其余所有核心组成锤芯舰队用紧凑的 4 字节读循环疯狂敲打另一个高延迟 MMIO 寄存器。每条读都是 non-posted 事务把 PCIe 根复合体和 GPU 端点塞满在途事务——CPU 0 的加载只能排在所有插队流量后面。结果62 秒1980 亿周期断层式第一。五、动手复现本地跑一遍 PCIe 慢速寄存器寻宝如果你有一台 AMD 平台机器参考平台为 Ryzen 7 5800H Radeon可以完整复现这套测试克隆项目git clone https://gitcode.com/gh_mirrors/as/asm-hall-of-shame构建在仓库根目录执行make根 Makefile 会递归编译所有子目录运行 mov 测试sudo ./bin/mov/mov输出最小周期数加-v可看地址、基线与均值详情换算时间周期数转秒可借助tools/cycles2time.c榜单图表则由tools/make_graph.py生成⚠️ 几点提醒所有测试都需sudo要读/dev/mem且只读访问请勿修改寄存器写入类目标高延迟区域可能需要先用 mmiotic 做一次 prime参考mov/README.md中的探测命令项目作者为 Christopher Domas整个榜单的探索过程在根目录 README.md 的 x86 Leaderboard 一节中有完整记录六、写在最后一条mov的 139 毫秒背后是 CPU、PCIe 协议与 GPU 内部实现三方合谋的延迟奇观CPU 等 completion、MMIO 逐 dword 拆事务、GPU 内部慢状态机兜底。asm-hall-of-shame 用最硬核的方式告诉我们——性能优化的尽头不是更快而是先知道最慢能慢到什么程度。从 1 周期的nop到 62 秒的fxrstor64这份耻辱榜就是 x86 世界最生动的一份 PCIe/MMIO 寻宝地图。️【免费下载链接】asm-hall-of-shameRacing to the bottom of CPU performance项目地址: https://gitcode.com/gh_mirrors/as/asm-hall-of-shame创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 一条mov如何让CPU干等139毫秒？asm-hall-of-shame PCIe/MMIO慢速GPU寄存器寻宝指南
一条mov如何让CPU干等139毫秒asm-hall-of-shame PCIe/MMIO慢速GPU寄存器寻宝指南【免费下载链接】asm-hall-of-shameRacing to the bottom of CPU performance项目地址: https://gitcode.com/gh_mirrors/as/asm-hall-of-shameasm-hall-of-shame 是一个开源的指令延迟倒数榜项目别的性能分析都在想办法让代码跑得更快它反其道而行专门在 x86 上寻找单条指令能有多慢。其中最经典的案例是一条平平无奇的 4 字节movl内存读取竟让 CPU 干等了整整139 毫秒443,937,696 个周期——罪魁祸首是 PCIe 总线上一个连文档都没写的 GPU 慢速寄存器。️图中从最慢的fxrstor641980亿周期到最快的nop1 周期完整呈现了 asm-hall-of-shame 的 x86 单指令延迟排行一、什么是 asm-hall-of-shameCPU 性能的耻辱榜传统指令延迟研究关注性能优化而这个项目的目标正好相反找到单条指令性能的绝对地板。它的规则很严格见 README.md指令可以任意搭建前置环境但只有一条指令参与计分rep movs、pause这类可中断指令直接淘汰成绩按 CPU 基础频率归一化且所有平台必须是出厂原装配置榜单的起点是nop1 个周期终点则是当前冠军fxrstor64198,002,498,236 个周期约合 62 秒。中间跨越了十几个数量级——这正是寻宝的乐趣所在。二、139毫秒的 mov一次普通的 4 字节读取主角代码在mov/mov.c核心操作其实非常朴素#define PHYS_ADDR 0xfcc003b0UL // 位于 Radeon GPU 的 MMIO 空间 void *page mmap(NULL, PAGE_SIZE, PROT_READ, MAP_SHARED, fd, (off_t)PAGE_BASE); uint64_t t MEASURE_PTR(movl (%%rdi), %%esi\n\t, reg); // 计时一次 movl程序通过/dev/mem以O_SYNC MAP_SHARED映射物理页确保这是一次无缓存、强序的读取。于是这条movl的真实旅程是CPU 发起读请求 → PCIe 根复合体 → 交换链路 → GPU 端点 → 等 GPU 应答 → 数据回传 → 指令才能退休也就是说CPU 必须老老实实等完整个 PCIe 往返。而这个地址0xfcc003b0恰好落在 Radeon GPU 的 MMIO 空间里对应一个** undocumented无文档的 GPU 寄存器**——那近 5 亿个周期的卡顿很可能反映了 GPU 深处某个缓慢的内部状态机或跨时钟域逻辑。 有个容易踩的坑据mov/README.md记录这片区域的高延迟可能要先访问某个邻近地址预热后才会显现需要用 mmiotic 工具做一次 prime 探测否则可能测不出满血延迟。三、为什么 MMIO 读取这么慢看宽度倍增的寻宝梯度PCIe 上 MMIO 的天然粒度是32 位一个 dword而且 CPU 读取 MMIO 无法发了就忘——它必须等 completion 回来。于是读得越多排队的时间就越长指令读取宽度拆分成的 dword 事务耗时movl 0xfcc003b0, %esi4 字节1139.01 msmovq 0xfcc003b0, %rax8 字节2277.97 msvmovdqu ..., %xmm016 字节4555.66 msvmovdqu ..., %ymm032 字节81.11 svmovdqu 0xfcc003b1, %ymm0未对齐32 字节91.39 s几个有趣的细节64 位的movq和 128/256 位的vmovdqu根本不是合法的 MMIO 访问宽度但硬件有求必应老老实实拆成连续多个 dword 事务未对齐版本最骚地址偏移 1 字节后32 字节窗口横跨 9 个 dword 槽位多一个事务就多排一次队详见vmovdqu_ymm_unaligned/README.md各案例源码分别在mov/mov.c、mov_rax/mov_rax.c、vmovdqu_xmm/vmovdqu_xmm.c等目录下四、从 512 字节到 62 秒冠军 fxrstor64 与锤芯策略沿着同一条路继续放大fxrstor64指令一次从 MMIO 拉取512 字节的 FPU/MMX/XMM 状态镜像——512 个字节每个都要穿越 PCIe 才能退休单条指令就耗掉23.35 秒fxrstor64/README.md。当前榜单冠军lock_hammer_fxrstor64更进一步lock_hammer_fxrstor64/README.mdCPU 0 执行 512 字节的fxrstor64其余所有核心组成锤芯舰队用紧凑的 4 字节读循环疯狂敲打另一个高延迟 MMIO 寄存器。每条读都是 non-posted 事务把 PCIe 根复合体和 GPU 端点塞满在途事务——CPU 0 的加载只能排在所有插队流量后面。结果62 秒1980 亿周期断层式第一。五、动手复现本地跑一遍 PCIe 慢速寄存器寻宝如果你有一台 AMD 平台机器参考平台为 Ryzen 7 5800H Radeon可以完整复现这套测试克隆项目git clone https://gitcode.com/gh_mirrors/as/asm-hall-of-shame构建在仓库根目录执行make根 Makefile 会递归编译所有子目录运行 mov 测试sudo ./bin/mov/mov输出最小周期数加-v可看地址、基线与均值详情换算时间周期数转秒可借助tools/cycles2time.c榜单图表则由tools/make_graph.py生成⚠️ 几点提醒所有测试都需sudo要读/dev/mem且只读访问请勿修改寄存器写入类目标高延迟区域可能需要先用 mmiotic 做一次 prime参考mov/README.md中的探测命令项目作者为 Christopher Domas整个榜单的探索过程在根目录 README.md 的 x86 Leaderboard 一节中有完整记录六、写在最后一条mov的 139 毫秒背后是 CPU、PCIe 协议与 GPU 内部实现三方合谋的延迟奇观CPU 等 completion、MMIO 逐 dword 拆事务、GPU 内部慢状态机兜底。asm-hall-of-shame 用最硬核的方式告诉我们——性能优化的尽头不是更快而是先知道最慢能慢到什么程度。从 1 周期的nop到 62 秒的fxrstor64这份耻辱榜就是 x86 世界最生动的一份 PCIe/MMIO 寻宝地图。️【免费下载链接】asm-hall-of-shameRacing to the bottom of CPU performance项目地址: https://gitcode.com/gh_mirrors/as/asm-hall-of-shame创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考