汇编语言测评：别被这6个坑误导
汇编语言测评最容易失真：只比一段短循环、只看源码行数，或把调试版本拿去对抗优化后的 C 程序，都能得出漂亮却无用的结论。本篇不做空泛打分，而是围绕性能、难度、工具和可维护性逐问逐答，拆开常见测试陷阱。
问：手写汇编一定比C语言快吗？
答：不一定。现代编译器会做内联、常量折叠、向量化、循环展开和寄存器分配。手写代码若忽略缓存访问、分支预测或指令依赖，即使指令更少，也可能因流水线停顿而更慢。
可靠测评要固定编译器版本与参数，至少使用 `-O2` 或符合项目实际的优化级别，并多次运行。微秒级函数还要扣除计时开销。结果应同时报告中位数、数据规模和硬件型号，不能只挑最快的一次。
问：指令少就代表性能好吗？
答：这是最常见的坑。不同指令的延迟、吞吐量和微操作数量不同，一条复杂指令未必胜过数条简单指令。内存未命中可能消耗远多于一次整数加法的时间，源码表面上的“短”几乎说明不了什么。
测评时应配合性能计数器观察周期数、指令数、缓存未命中和分支失误。Linux 可用 `perf stat` 获取基础数据。若两版代码处理的数据布局不同，先统一算法和访存模式，否则比较的是设计差异，不是语言差异。
问：能运行就说明汇编写对了吗？
答：远远不够。破坏非易失寄存器、栈未对齐或遗漏展开信息，可能在简单测试中毫无异常，换个调用者、开启优化或触发异常后才崩溃。跨语言调用尤其要逐条核对平台 ABI。
测试清单至少包括：边界输入、不同优化级别、多个调用位置、调试器回溯、寄存器保存和内存检查。涉及 SIMD 时还要检查地址对齐与指令集支持，不能假定所有 x86-64 处理器都具备同一扩展。
问：怎样做一份可信的汇编语言测评？
答：先定义目标。若测学习体验，就记录环境搭建、报错定位和完成任务所需时间；若测性能，就保持算法、输入和输出一致；若测工程价值，还要统计代码体积、平台适配成本、测试覆盖和后续修改难度。
最值得警惕的是“快了百分之几”却不公开代码、参数与机器。一次合格测评应可复现，并解释收益来自向量化、减少访存还是更好的分支布局。说清原因，比给汇编语言打一个笼统分数有用得多。
推荐阅读
常见问题
汇编语言性能怎么测试？
使用发布构建、固定输入并预热缓存，多轮运行后看中位数。配合 perf 等工具记录周期、指令、缓存未命中和分支失误，同时公开 CPU、编译参数与源码。
汇编语言是不是代码越短越快？
不是。代码长度只影响部分取指和缓存行为，真实速度还受指令延迟、吞吐量、数据依赖、访存与分支预测影响。
为什么汇编调试版特别慢？
调试构建可能保留栈帧、插入检查代码并禁用关键优化。比较语言性能时，必须使用与实际部署一致的构建方式，不能拿调试版对比发布版。