正常。CPU微架构、指令集扩展、缓存层级和分支预测器差异会导致ARM64与AMD64的bench结果显著不同，尤其影响内存或算术密集型测试。
Go
结果在 ARM64 和 AMD64 上差异大，正常吗？
正常。CPU 微架构、指令集扩展（如 AVX）、缓存层级、分支预测器行为都会直接影响
的纳秒级计时结果，尤其对内存密集或算术密集型测试更敏感。
实操建议：
立即学习
“
go语言免费学习笔记（深入）
”；
不要跨架构直接比对
绝对值，重点看同一台机器上不同实现的相对变化
用
多次运行取中位数，避免单次抖动干扰
ARM64（如 Apple M系列）默认启用
兼容模式，但 Go 1.22+ 在 ARM64 上不生效——这点常被忽略，实际影响不大，但别误以为能“开启 AVX 加速”
如何让
排除 CPU 频率波动干扰？
Go 自身不控制 CPU 频率，
依赖系统时钟和调度器，而 Linux/Windows/macOS 的节能策略会动态降频，导致结果飘忽。
实操建议：
立即学习
“
go语言免费学习笔记（深入）
”；
Linux 下临时禁用 cpufreq：运行
macOS（M 系列）无法手动锁频，但可关闭
中的“自动切换图形卡”和“优化电池充电”，并在插电状态下测试
Windows 建议切到“高性能”电源计划，并确认 BIOS 中关闭
或
无论哪平台，跑基准前先
，避免旧编译产物干扰
和
对跨架构 bench 影响大吗？
影响存在，但通常次要。真正起作用的是 Goroutine 调度与底层线程绑定方式，而 ARM64 和 x86_64 的线程调度器路径略有不同。
实操建议：
立即学习
“
go语言免费学习笔记（深入）
”；
保持
默认（逻辑 CPU 数），除非你明确在测并发瓶颈；强行设为 1 可能掩盖 NUMA 或 cache line false sharing 问题
仅用于调试调度行为，**会显著拖慢 benchmark**，切勿用于性能采集
ARM64 上某些老版本 Go（atomic 指令生成冗余 barrier 的问题，升级到 1.21+ 可规避，错误现象是
类函数在 ARM64 上比 x86_64 慢 10%+ 且无合理解释
为什么
火焰图里 ARM64 的调用栈更深？
不是栈真的更深，而是 ARM64 的帧指针（frame pointer）默认启用，且 Go 编译器对
的激进程度略低于 x86_64，导致更多函数未内联，pprof 解析出更多中间层。
实操建议：
立即学习
“
go语言免费学习笔记（深入）
”；
用
关闭内联再对比，能验证是否为内联差异所致
火焰图中若出现大量
或
，说明测试函数触发了 goroutine 切换——这在 ARM64 上因调度器微小延迟可能更易被采样到，不代表性能差，只是采样偏差
真要对比 CPU 指令级开销，用
（Linux）或
（macOS）更可靠
跨架构做基准测试，最难控的其实是内存带宽和 L3 cache 共享行为——比如 AMD64 的 chiplet 架构下，跨 CCD 访存延迟可能翻倍，而 ARM64（M2 Ultra 除外）目前仍是单 die 设计。这点几乎无法通过 Go 代码规避，只能靠
或绑核来逼近稳定条件。
benchBenchmarkns/opgo test -bench=. -benchmem -count=5GOAMD64=v1go test -benchbenchsudo cpupower frequency-set -g performanceEnergy SaverIntel SpeedStepAMD Cool’n’Quietgo clean -cache -testcacheruntime.GOMAXPROCSGODEBUGGOMAXPROCSGODEBUG=schedtrace=1000atomic.LoadUint64go tool pprofinlininggo build -gcflags="-l" -o bench.bin .runtime.mcallruntime.goparkperf record -e cycles,instructions,cache-misses Instruments → Counters numactl