Post #981

终于检查完这篇文章了： https://skoredin.pro/blog/golang/cpu-cache-friendly-go TLDR，AI 文可能性很大，正确内容里夹着部分错误，误导性高，但具有启发性，需读者花时间检查错误和内化。 那我就不要脸地带大家读一遍吧😋 False Sharing: The Silent Killer 这第一小节就给我这种非科班出身一个震撼，怀着巨大好奇让 AI 写 benchmark 又发现测不出差距转而痛骂 AI，但其实文章是对的，在多核 lock prefix insn 并行执行下 false sharing 真的可能导致六倍性能差距，见评论区 https://t.me/danteslimbo/5575 Measure Cache Misses (Linux) 我的评价是不如直接 perf stat -d 啥都有；此外 false sharing 在 TopdownL4 里。 Data-Oriented Design: Array of Structs vs Struct of Arrays 这是对的，也比较好理解。 Prefetching: Help the CPU Predict 这是对的，尤其要注意最后那个线性迭代本身就已经有 cpu prefetch，但在线性迭代里手动 prefetch 下一个 cacheline 依然能让性能 +25% func SumLinearWithManualPrefetch(data []int, prefetchDistance int) int { sum := 0 for i := 0; i < len(data); i++ { j := i + prefetchDistance if j < len(data) { _ = data[j] } sum += data[i] } return sum } QC 前几天分享了一篇文章测试了 Go 程序迭代模式对 prefetch 的影响： https://lemire.me/blog/2025/08/15/predictable-memory-accesses-are-much-faster/ 其中最令我印象深刻的结论是 bouncing access （读 a[i] 和 a[len-i] 一头一尾弹跳式非线性读）居然能有最好的性能，原因是指令级并行，我已有 perf 验证。 Hot/Cold Data Splitting 是对的，容易理解。 NUMA-Aware Allocation 没有条件测试🤬下一题 Branch Prediction Friendly Code 这是错的，错得非常彻底，因为 Go (1.22 ~ 1.24) 会把 if v > 128 { count++ } 编译成为无分支跳转的指令 0x000000000049fe33 <+19>: inc %rcx 0x000000000049fe36 <+22>: cmp $0x80,%rsi 0x000000000049fe3d <+29>: cmovg %rdi,%rdx cmovg (条件 move) 保证了原文里 CountCondition 函数在有序或者无序输入下的分支预测错误率是一样低的。 Cache-Conscious Hash Table 居然是对的。RobinHoodMap Set 性能不行，但是 Get 指令可以达到 go map 的五倍性能，在小 value 的时候往后检查一个 cacheline 的 distance 性能真的很炸裂。 SIMD-Friendly Layouts 错误的，里面两个观点都是错的： 1. Padding for 16-byte alignment 可以让编译器编译出 SIMD 指令。实际上不需要 pad 也是 SIMD 指令，而且 pad 之后影响了 cache miss rate 导致性能下降。 2. _ [0]byte 可以强制结构体对齐 cacheline。错误的，随便测一下就知道是错的。 其实我觉得 cache friendly 还只是高性能 CPU 程序的冰山一角，我今年学到的 CPU 指令级并发 (tma_ports_utilized_3m) 才是最黑魔法的，比如浮点乘法 sum = sum * (b[i] * c[i]) vs sum = sum * b[i] * c[i] 前者比后者快了 1.5 倍 (0.842 vs 1.345 ns/elem)，这些都是 x64 特供魔法，非常有趣。 大部分内容都是年轻聪明的 QC 老师教我的，请大家多多关注他的频道： https://t.me/QC_Grove BTW， https://uica.uops.info/ 503 Service Unavailable，悲！