该项目收集了CPU单指令性能最差的案例，通过特殊方法使指令执行时间极长，如利用fxrstor64从高延迟MMIO区域加载数据并制造PCIe拥塞，以探索指令性能的极限下限。

汇编指令延迟排行榜：CPU性能的“下限”探索

该项目名为“汇编指令耻辱堂”，其目标与常规的指令延迟分析（追求性能优化）相反，专注于寻找单条指令执行时间的绝对下限——即最慢的指令。

当前冠军

x86架构冠军：fxrstor64 指令

策略：在AMD Ryzen 7 5800H处理器上，通过fxrstor64指令从PCIe架构中的高延迟MMIO区域加载512字节的FPU/MMX/XMM状态。同时，利用多个核心持续向另一个高延迟MMIO寄存器发起密集的4字节读取操作，以此饱和PCIe根复合体和端点的事务处理能力。这使得CPU 0的512字节fxrstor64加载操作必须排队等待所有竞争流量处理完毕。

得分：198,002,498,236 个时钟周期（约62秒）

荣誉提名

一个违反规范的未对齐ymm0加载指令（vmovdqu），通过从停滞的GPU寄存器强制进行非投递式双字事务，被用于突破系统管理模式（SMM）的基本设计。

规则说明

• 指令可以使用任何必要的设置，但只有一条指令有资格被计分
• 被捕获/模拟/虚拟化的指令只能计时捕获过程，而非处理程序
• 指令必须不可中断（rep movs、pause等被取消资格）
• 时间基于CPU基础时钟频率进行归一化
• 所有平台必须保持出厂默认配置，无硬件修改

x86排行榜亮点

排行榜从最快的指令（nop，1个时钟周期）到最慢的指令（冠军fxrstor64，约1980亿个时钟周期）进行了排序。以下是部分关键条目：

• nop：基准指令，1个时钟周期
• idiv：通过128位被除数和较小除数，触发除法器微码的最长路径，77个时钟周期
• fdiv：使用次正规除数触发FP微码辅助，883个时钟周期
• cpuid：通过特定叶号达到最高延迟，1,248个时钟周期
• rdrand：通过紧密循环耗尽硬件熵池，迫使后续调用等待，5,579个时钟周期
• wrmsr：写入特定模型特定寄存器（MSR），可能触发跨硬件单元的微码同步，34,304个时钟周期
• wbinvd：完全加载L1/L2/L3缓存脏行，强制将整个层次结构写回DRAM，1,616,480个时钟周期
• in：访问映射到ACPI PM块的I/O端口，触发多个非投递式加载，12,524,415个时钟周期
• mov：访问PCIe架构中的高延迟GPU寄存器，4.44亿个时钟周期
• vmovdqu ymm：使用32字节未对齐MMIO读取，触发9次双字寄存器访问，44.5亿个时钟周期
• fxrstor64（基线）：从MMIO加载512字节状态，745.8亿个时钟周期
• fxrstor64（冠军）：通过多核心竞争流量进一步延长延迟，1980亿个时钟周期

未来展望

项目还提出了一个潜在挑战者：在Sapphire Rapids处理器上使用xrstor64指令加载扩展AVX状态（约8KB，是fxrstor64的16倍），预计可能达到1万亿个时钟周期。

作者

该项目由Christopher Domas（@xoreaxeaxeax）发起的研究工作。

根据评论内容，主要观点和论据如下：

1. 资源价值与作者背景
- 评论1（vardump）认为这是“性能优化的绝佳资源”（"A great resource for any performance deoptimization"）。
- 评论7（spoocecow）对作者Chris Domas的活跃表示欣喜（"glad to see Chris Domas active online again"）。
- 评论3（TomatoCo）提及作者其他项目，如仅用mov指令的编译器及干扰反汇编的工具（"a compiler that emits only mov instructions"）。

2. 技术策略与争议
- 评论2（arn3n）指出策略涉及浮点运算中的次正规数及MMIO操作（"floating point operations use subnormals... slowed down by really fucking with MMIO"）。
- 评论11（IshKebab）批评使用MMIO“作弊”，认为仅限主内存的结果更有趣（"Using MMIO is cheating and makes the results very boring"）。
- 评论5（codeshaunted）调侃应“用nop指令做所有事”（"we should be using the nop instruction for everything"），评论8（layer8）附和称nop因“无限慢”应排第一（"infinitely slow for what it does"）。

3. 架构依赖与性能极限
- 评论6（achierius）质疑其他架构（如POWER）的MMIO排序规则是否改变结果，并追问fxrstor64的极限（"why not indefinitely?"）。
- 评论10（michalsustr）对rdtsc指令执行时间之长表示惊讶，并询问是否跨架构通用（"Is that common across architectures?"）。

4. 相关项目与延伸
- 评论9（Retr0id）链接了利用慢指令破坏SMI的项目（"using the slow instructions to break SMI"）。
- 评论4（metadat）感叹计算机性能感知变慢，并提及“程序员用抽象浪费算力”的定律（"programmers wasting all the compute on abstraction"）。