Forwarded From Welcome to the Black Parade

发现 go 的 chan 性能比我想象中好很多，大吃遗精。

一开始是我有个 SPSC 的场景，一个 goroutine 从内核读数据塞给 chan，另一个 goroutine 读 chan 处理事件。perf 一下发现 25% 的 cpu 浪费在 chan 通知机制，我才想起这里应该用 buffered chan 减少通知次数。linux kernel 收包流程有类似的工程设计了，NAPI 处理 rx 时硬中断通知网络收包，然后 mask rx queue、用软中断持续 poll 直到没有流量再重新打开硬中断，显著降低通知次数。

然后我冲冠一怒，觉得区区 SPSC，手搓场景特化 ringbuf 轻轻松松快到飞起，弱智 golang 快来见识我的神力吧！

第一版是用 bpf ringbuf 的设计，裸字节消息 + 双重 mmap (Welcome to the Black Parade)，SPSC 也不需用原子指令，仔细编排一下 x64 Load-Store Load-Load order 就可以保证内存序了（手搓 amd.s 嘻嘻），没想到 benchmark 结果不堪入目，就算加上 prod/cons 指针的缓存也不堪入目。

做了一下 perf-c2c，发现 hitm 依然是个悲剧，原来在生产消费速度不一样的时候会退化到 producer 每个消息发送都会 load 一次其他核心的 consumer 的指针，造成一次 ocr.demand_data_rd.l3_hit.snoop_hitm，IPC 都小于 1 了，per op 耗时来到了 100ns，纯辣鸡，而 go chan 还稳稳在 30ns/op，此为 go chan 一胜。

想了一下，发现可以用 linux kernel sk cookie 分配思路 (Welcome to the Black Parade)，producer 每次 reserve 一大块 ring，这样对于这一批 ring 就保证了无需 snoop_hitm，就算在极端情况下每次 snoop_hitm 的成本也被均摊了，这样立刻就把 IPC 提到了接近 2，但由于裸字节 ring 的消息体 header decode 等额外操作，此时才勉强追平 buffered go chan，此为 go chan 二胜。

要注意这一番猴戏下来，整个 API 难用得要死，发消息只能 batch 批量发，但性能依然和 go chan 坐一桌，肯定在源头上就有设计问题，那就是不应该用裸字节消息流 bytes ring，而且用固定类型 slots ring。一番改造后，在强制 batch op 的场景下总算达到惊人的 2 ns/op。

但此时 ring 只能批量收发且没有阻塞机制，在生产消费不平衡的状态下，快的那一方会不断浪费 CPU 去 TryReserve/TryRead，还是要设计一下阻塞通知机制，就用 futex 随便糊一下吧，只要注意只在对方 park 时才通知就行了，NAPI！

一番华丽的 CAS 和 futex 操作后，测试了一下生产消费速率不平衡的场景，虽然在多核心并发 benchmark 时候我依然小优 (0.99x)，但在单核心时 go chan 还稳在 85 ns/op，而我的性能已经退到了 124 ns/op，悲！

这是因为 go chan 可以使用 runtime gopark 来 **暂停 goroutine**，而我却只能用 futex 来 **暂停 thread**，两者在单核心调度时显现出巨大的差异，此为 go chan 三胜！

想利用 gopark 的话可以考虑 sync. Cond 条件变量，但又会涉及复杂的 mutex 协作，复杂度就更恶心了，目测性能会更烂，不值得。

所以，go chan 其实还挺好的，虽然在特化场景下并非最优，但综合表现非常均衡，实在是高手中的高手，这还只是最简单的 SPSC 都打得这么吃力，某些狂妄之徒实属小丑。

（皈依 LLM 之前的最后一舞了，谢谢大家😭）

喵喵小喵喵