做分布式存储那会儿，我被一个看着很基础的问题折腾了整整两个月：上PB的副本数据要做去重，每个64KB的块都得算出SHA-256摘要才能决定要不要再存一份。初期我们直接调OpenSSL的EVP接口，单核八、九百MB/s的吞吐听起来并不寒酸，可一旦上层几百个线程把成千上万个独立小块无规律地抛过来，实际吞吐直接塌到三成。不是因为OpenSSL慢，而是任务调度、缓存命中率、上下文切换和指令级依赖链这些平时没人盯着的东西，在整条链路里突然全部变成了瓶颈。
我更想强调一点：做算力优化，字节/秒这个指标永远比单次哈希的延迟重要。这道理也简单——你去重、做内容寻址、做数据库校验，关心的是“一小时内能处理多少数据”，而不是“某一个64KB块出摘要有多快”。很多团队上来就追求把单流哈希抡到极限，方向其实就偏了。单流再快，撑不起整个系统的吞吐目标，一样白搭。包括这两年大家天天在谈的AI算力集群、资源调度，本质上也绕不开同一件事：硬件峰值写在那，怎么把每一份执行单元的功率都变成有效产出。
后来我又在几个不同业务里撞见同样的困局：对象存储的静态去重、日志系统的内容寻址、交易系统的海量交易哈希、数据库分库后的全量校验。这些需求底层是同一件事——在单位时间里把尽可能多的SHA-256算完。这篇文章就是我在这几个项目里反复折腾出来的工程笔记，没有多少教科书内容，更多是实测数据、踩坑记录，以及一套套试过之后真正保留下来的“非标准”做法。内容会涉及多缓冲并行、AVX2手写内核、批处理调度、内存预取，以及转向GPU之后的架构取舍。如果你也在做大规模哈希、去重、内容寻址，或者任何对哈希吞吐有硬指标的系统，这篇文章应该能帮你省掉一大截调研时间。
1. 这个项目的起点：当 SHA-256 成了整个链路的瓶颈
先交代具体场景。我们的数据去重服务，一次会收到一批批64KB的块，每块对应文件系统里的一段真实数据。要对块内容算SHA-256，拿摘要去索引里查重。最早架构很朴素：开32个工作线程，每个线程调OpenSSL的EVP_Digest。理论上看，32个核乘上单核800MB/s，怎么也该有20GB/s以上的能力了，但线上实测连3GB/s都到不了。
1.1 标准接口的隐性开销，比你想的狠得多
问题出在哪？拆开看有三层。第一层，OpenSSL的EVP接口绕了好几层函数指针和参数封装，每次调用都有上下文初始化、缓冲管理之类的固定成本。对一次性处理几MB的大文件，这点开销可以忽略；但我们这批场景全是64KB的小块，固定开销摊到单位数据上就非常可观了。第二层，一个64KB的块要被拆成1024个64字节的小块，逐个进压缩函数，块与块之间天然串行，单线程内部根本腾不出可并行空间。第三层最要命，32个线程同时跑，每个线程都在拼命占用L3缓存，哈希的中间状态、输入数据、W数组的临时变量互相踩踏，cache line在核心之间来回搬。这套组合拳下来，以算力利用率的眼光看，CPU里绝大多数执行单元其实都在空转。
1.2 “延迟快”不等于“吞吐高”，这两个指标经常打架
踩过这轮坑之后我做了一次换位思考：如果业务方告诉我的需求是“1毫秒内出一个64KB块的哈希”，那毫无疑问该优化单次延迟；但他们的真实需求是“1小时内处理完10TB数据”，这是纯吞吐问题。吞吐问题的正确答案往往不是把单次做得更快，而是让多个计算单元尽量满负荷地并行工作。
换到SHA-256上，这意味着两件事：第一，在单核内部，要填满执行端口、打散指令级依赖链的瓶颈；第二，在整机层面，要做合理的任务分发和批处理，让每个核都在算哈希而不是等数据、等锁、等上下文切换。后来我把这套思路拆成了三个“板斧”：多缓冲SIMD并行、批处理调度与内存预取、以及算力不够时的GPU并行化。下面逐块展开，每一步背后我都会说清楚为什么这么做，以及实测数据长什么样。
2. 拆开 SHA-256 的算力账本：串行依赖链才是真正的硬伤
在做任何优化之前，得先把SHA-256这顿饭是怎么做的看明白。SHA-256把输入切成64字节的块，每块经过一个压缩函数处理，结果作为下一块的初始状态继续处理。压缩函数内部是64轮迭代，每一轮的操作其实非常规整，但正是这个“规整”里藏着限制算力利用率的关键。
2.1 压缩函数里真正吃计算量的部分
SHA-256的轮函数维护8个32位状态变量：a、b、c、d、e、f、g、h。每一轮要做的事情可以浓缩成两个临时量和一轮状态搬移：
- T1 = h + Σ1(e) + Ch(e, f, g) + K[t] + W[t]
- T2 = Σ0(a) + Maj(a, b, c)
- 然后：h=g，g=f，f=e，e=d+T1，d=c，c=b，b=a，a=T1+T2
其中Ch是选择函数，Maj是多数函数，Σ0和Σ1是三个循环右移的异或组合。把一个块撑起来，还需要消息扩展：前16个W直接来自输入块的16个32位字，后面的W[t]由W[t-2]、W[t-7]、W[t-15]、W[t-16]通过σ0、σ1这两个小函数现算。粗算一下，每处理一个64字节的块，光压缩函数就要64轮×大约10个基础操作，加上消息扩展，总共大概六七百个操作。这么一算，SHA-256的单位运算强度其实很夸张——每字节要消耗十来个整型ALU操作。
2.2 为什么单流实现喂不饱现代CPU的流水线
这就要说到单流实现最大的硬伤了。仔细观察轮函数会发现，每一轮的e和a都依赖上一轮算出来的T1和T2，而T1又依赖上一轮的e和h，T2依赖上一轮的a。换句话说，64轮迭代形成了一条从第0轮一路贯穿到第63轮的串行依赖链。现代CPU虽然有乱序执行引擎，可以在一条链的缝隙里捞一点别的指令来填，可单流场景下你根本没多少“别的指令”可用，乱序窗口再大也只能干等着。
打个比方：一条自动化产线上只有一个工人，所有工序必须按顺序过他的手，那不管设备多先进，产出的上限就是这个工人的手速。SHA-256的单流就是那个工人，ALU、加载端口、移位器再充裕，也得等当前轮的结果出来才能算下一轮。这也是为什么Intel和AMD后来在CPU里专门加了SHA-NI指令集——SHA256RNDs2一次就能推进4轮，等于让硬件直接接管了这条依赖链，才绕开了这个结构性问题。但对一台没有SHA-NI的老至强服务器，或者你在云上开到的某些老款虚拟机，这个问题就是实打实的性能天花板。
2.3 打破依赖链的正道：不是优化单流，而是并行多流
绕过这条串行依靠链的思路，恰恰是SHA-256算法本身“慷慨”的地方：轮函数里所有的操作——按位与、按位或、按位异或、32位加法、循环右移——都是各算各的，天然能放进SIMD向量里。如果同时处理8条相互独立的消息，让每条消息占据向量里的一个“车道”，那么这一轮里需要等依赖链的就从1条变成了8条，乱序执行引擎手里的活一下子多了8倍，执行端口自然就填满了。
这也是我管这叫“非标准工程实践”的原因：标准做法是你调库，库给你一条流一条流地算；非标准做法是把多条流拆开揉进同一个向量寄存器里，让每个ALU周期同时为8条消息服务。后面第三板斧就是沿着这个思路落地的。
3. 第一板斧：多缓冲并行，用 AVX2 同时喂八条消息
多缓冲（multi-buffer）这个思路其实不算新，早年英特尔做IPSec时就在SHA-1上用过类似的招，只是很少有人把它用在通用SHA-256吞吐优化上。我当时的目标很直接：在无SHA-NI的至强节点上，把单核吞吐从OpenSSL的900MB/s左右拉到接近两倍。
3.1 把8条消息的同一状态变量塞进一个256位向量
具体做法是用AVX2的256位寄存器，里面放8个32位整数，每个整数对应一条独立消息的一个状态变量。于是a、b、c、d、e、f、g、h这8个状态，在代码里就变成了8个__m256i向量。每一轮做Ch、Maj、Σ0、Σ1时，整条向量一起算，8条消息同步前进。
最妙的是AVX2的32位加法是逐车道独立的：vpaddd对8个32位通道做加法时，进位不会跨车道传播，这就保证了8条消息的运算彼此完全隔离，不会串味。旋转操作也简单，AVX2没有直接的逐车道循环右移指令，用“右移或左移再或回”三步拼出来就行。下面是一段我在项目里实际用的核心代码骨架，只截了最有代表性的Ch和旋转两个片断：
// AVX2 多缓冲 SHA-256：8 条消息共享同一轮计算 // a..h 各是一个 __m256i 向量，第 N 个车道保存第 N 条消息的状态 static inline __m256i sha256_ch(__m256i e, __m256i f, __m256i g) { // Ch(e,f,g) = (e & f) ^ (~e & g) return _mm256_or_si256( _mm256_and_si256(e, f), _mm256_andnot_si256(e, g)); } static inline __m256i sha256_rotr(__m256i x, int r) { // 循环右移：AVX2 没有逐车道循环指令，用移位+或来拼 return _mm256_or_si256( _mm256_srli_epi32(x, r), _mm256_slli_epi32(x, 32 - r)); } // Σ1(e) = ROTR(6,e) ^ ROTR(11,e) ^ ROTR(25,e) __m256i sigma1 = _mm256_xor_si256( _mm256_xor_si256(sha256_rotr(e, 6), sha256_rotr(e, 11)), sha256_rotr(e, 25));3.2 消息扩展的向量化与寄存器压力控制
压缩函数只是其中一半，消息扩展W[t]也得做同样的向量化。好消息是W[t]的每一条依赖（W[t-2]、W[t-7]、W[t-15]、W[t-16]）都在同一条消息内，天然符合“逐车道独立”的要求，所以σ0、σ1同样可以照搬旋转三步法去算，8条消息的W完全并行推进，没有任何跨车道通信。
真正要小心的是寄存器压力。一次处理8条消息，状态变量8个向量、W可能要同时预留十几个向量、K常量还要随着轮数更新，分分钟把AVX2的16个YMM寄存器全部用光。一旦溢出到栈上，代价是每次访问都要走内存，吞吐直接崩回去。我试过好几版布局，最后稳定下来的做法是：把W的计算拆分进两个临时向量里，前16轮的W直接从输入块加载，后48轮在用到前一刻才算，尽量缩短向量存活时间，让编译器能把热点全部留在寄存器里。不要一上来就无脑展开64轮，编译器在寄存器分配上比你聪明。
3.3 实测：在老至强上，单核吞吐从0.9GB/s提到1.7GB/s以上
我在一台E5-2680 v4（Broadwell，2.4GHz，无SHA-NI）上做了对照测试，消息统一用64KB，分批处理，结果如下：
| 实现方式 | 单核吞吐 | 相对倍数 | 说明 |
|---|---|---|---|
| OpenSSL 1.1.1 汇编单流 | ~0.9 GB/s | 1.0x | 依赖链限制IPC，执行端口大量空闲 |
| 手写AVX2 8路多缓冲 | ~1.7 GB/s | ~1.9x | 8条消息并行填充空闲执行槽 |
| 多缓冲+循环展开优化 | ~1.8-1.9 GB/s | ~2.1x | 受限于加载端口和转移端口 |
这个结果和理论估算基本吻合。算力利用率从三成多提到了七成左右，单核收益接近翻倍。虽然离完美还差一口气，但对一个几十节点的集群来说，单核翻倍就意味着总吞吐能力翻倍，等于省下了一半的哈希服务器。后来我把同样思路移植到一台有SHA-NI的Ice Lake机器上对比，发现SHA-NI单流轻松跑到2.8GB/s，多缓冲反而没优势——所以要不要上多缓冲，第一件事是看清楚你的CPU到底有没有SHA-NI。这一点很多优化教程不会跟你讲清楚，我把话放这儿：有SHA-NI，别折腾AVX2；没有SHA-NI，多缓冲是目前最优解。
4. 第二板斧：批处理调度与内存预取，喂饱你的哈希内核
内核快了，系统没跟上，照样白搭。第一板斧做完之后，我紧接着就撞上了下一个瓶颈：多缓冲内核一次要吞8条消息，但业务层来的请求是随机的、零散的，经常凑不齐8条。要么让线程干等，要么让内核空着车道硬算——前者损吞吐，后者损算力。所以我那段时间的主要工作从“算得快”变成了“喂得匀”。
4.1 把海量小请求整理成稳定批次流
我给哈希服务设计了一个无锁环形队列，业务线程只负责把待哈希的缓冲区和回调信息丢进队列，后端由一组工作线程批量消费。工作线程每次从队列里捞一批消息，攒够8条（或者等待时间超过预设阈值）就交给多缓冲内核去算。这个“攒批”的动作本质上是拿延迟换吞吐：消息在队列里多等了那么几十微秒，换来的是SHA-256执行单元接近满载。在去重这类场景里，几十微秒的额外延迟完全无感。
批量大小也值得讲一讲。我试过4路、8路、16路三档，AVX2下8路最均衡，再往上要么寄存器不够用，要么队列积压变得不可控；如果把批次拆成多个核并行，每核8路，整机吞吐还能线性往上叠。另外，我会刻意把缓冲区按64字节对齐，让每条消息的起始地址都落在缓存行边界上，加载时能少踩一半的cache line。别小看这个对齐，热点代码里一次非对齐的load可能触发额外的内存访问，摊到8条消息上就是成倍的浪费。
4.2 大端加载、填充和预取，三个容易漏掉的点
SHA-256要求输入按大端读成32位字，而x86是小端，所以每次从内存加载16个字后都得做字节序翻转。单流实现里这只是几个bswap的问题，但多缓冲里16个字同时要转，手动转会占掉不少指令槽。我在AVX2下用一条pshufb指令配合预置的掩码完成16个32位字的同时翻转，代价几乎可以忽略。另外，如果业务里所有消息的长度规律一致（比如消息长度对64取模的余数固定），那末尾块的0x80和长度字就能提前算好，生成摘要时少做不少事。
预取这块我走过弯路。一开始我给工作线程加了显式的prefetchnta指令，想把输入数据提前拉进L2，结果在部分机器上反而拖慢了速度。后来发现，对64KB这种中等大小的消息，顺序读取加上硬件预取器已经做得很好，人工干预收益很小；真正吃预取红利的是那种“一批8条消息各来自不同内存区域”的场景，这时用软件预取把8条数据流同时激活，能明显降低TLB和缓存缺失率。所以我的建议是：先用性能计数器看清楚缓存缺失发生在哪一层，再决定要不要上软件预取，别凭感觉加指令。
4.3 一个容易翻车的坑：超线程与NUMA对吞吐的影响
多缓冲内核跑稳之后，我做过一次“理所当然”的尝试：把工作线程数调到逻辑核数，利用超线程再翻一倍的吞吐。结果反而掉了两成。原因很直白：超线程的两个逻辑核心共享同一组执行端口，而SHA-256这种ALU密集型任务恰恰把执行端口喂得满满的，两个逻辑核互相抢，加上L1和L2的竞争，收益是负的。正确做法是让一个物理核心跑一个多缓冲线程，如果还想榨，就再绑定一块独立的内存节点。
NUMA的影响同样容易被忽略。哈希线程处理的数据如果在远端内存，每访问一次都要跨内存总线，多线程一起跨，内存带宽立刻变成瓶颈。后来我按NUMA节点做了数据和线程的亲缘性绑定：线程只处理本节点内存里的数据块，吞吐又稳了一截。这个优化没动一行哈希代码，白捡的收益。
5. 第三板斧：GPU 上的 SHA-256 并行化与数据搬运博弈
CPU侧折腾到顶之后，我们遇到一个更极端的需求：每天要校验几个PB的归档数据，CPU全部砸进去也不够。这时候自然想到GPU。但GPU上的SHA-256和CPU上的思路完全是两码事，踩坑的方式也完全不同。
5.1 GPU并行模型：一条线程一个哈希，靠数量堆吞吐
GPU不像CPU有强大的乱序执行和分支预测，它的算法很直白：每条线程独立负责一个（或几个）消息块，硬件靠几千条线程的并行度掩盖延迟。在GPU上做多缓冲没有意义——每条线程本身就是一条流，你真正要做的是让线程之间尽量不互相干扰。
实现上有几个关键决策。第一，W数组放哪：64个W字每个4字节，全部塞寄存器会爆，全部放共享内存又太慢。我最终的做法是只保留后48轮W里复用频率最高的几个在寄存器里，其余的按需算一遍，牺牲一点计算换来可观的寄存器余量。寄存器余量直接决定每个SM能同时驻留多少线程，也就是决定occupancy，这一步牵一发动全身。第二，绕开重复的字节序转换——数据从CPU侧拷贝过来时如果已经统一成大端整理过的布局，内核里就能省掉整段的加载翻转逻辑。
5.2 共享内存Bank冲突与线程束调度
GPU上还有个性价比很高的优化点：让每条线程连续处理多个消息块（比如4个）再退出，而不是一个线程只算一块。这样做的好处是摊薄线程创建和调度开销，同时让寄存器里的状态尽量被重用。但要注意共享内存的bank冲突：如果多个线程同时访问同一bank的不同地址，访问会被串行化。我在消息调度的临时数组里做过填充位调整，让相邻线程的访问落到不同bank，内核快了约15%。这是CUDA优化里最常见的技巧，放在SHA-256这种访问模式很规整的内核里格外有效。
5.3 实测对比：CPU多缓冲 vs GPU 的性价比与工程成本
我拿RTX 3090（数据已在显存里）和一台16核至强做了一组对照，结论非常有意思：
| 平台 | 可持续吞吐（参考） | 主要瓶颈 | 工程成本 |
|---|---|---|---|
| CPU单核多缓冲 | ~1.8 GB/s | 执行端口/Load端口 | 中 |
| CPU 16核整机 | ~15-20 GB/s | 内存带宽/L3争抢 | 低 |
| GPU（数据已在显存） | 超100 GB/s | 显存带宽/occupancy | 高 |
| GPU（数据在CPU内存，走PCIe） | ~8-16 GB/s | PCIe带宽/拷贝开销 | 高 |
看到了吗？GPU计算本身快得吓人，但只要数据得从CPU内存经PCIe搬过去，优势瞬间蒸发。PCIe 4.0 x16单方向实际可用带宽也就十几GB/s，GPU算得再快，搬不动一样白搭。所以我的判断是：GPU方案只适合数据天然驻留在GPU侧的场景，比如你在GPU上做渲染、训练、图像处理的中间结果顺手做哈希，或者对延迟不敏感、可以事先批量搬到显存的离线归档校验。如果数据是磁盘、网络实时进来的，老老实实优化CPU侧的多核批处理，性价比高得多。
6. 复盘清单：哪些“非标准”手段值得保留，哪些是白折腾
最后写点实在的。经历了这几个项目之后，我把所有试过的招数按“收益/成本”排了个序，也把那些看起来漂亮却没用上的尝试记了下来，算是给后来者的避坑指南。
6.1 按收益排序，真正值得做的优化
- 第一优先：选对硬件路径。有SHA-NI的CPU直接用SHA-NI，单流就足够快；没有SHA-NI的CPU才考虑AVX2多缓冲。这个判断至少帮你省下一个月的无用功。
- 第二优先：任务批处理和队列设计。把零散小请求攒成批次，让哈希内核满负荷工作。收益稳定、通用性强，几乎任何哈希服务都能用。
- 第三优先：多缓冲SIMD内核。在无SHA-NI的旧平台上，这招能把单核吞吐翻倍，但注意要配合寄存器布局和加载端口的平衡，不是无脑展开就行。
- 第四优先：NUMA绑定和物理核调度。零代码改动，纯运维配置就能拿到10%到15%的吞吐提升。
- 第五优先：消息级优化，比如padding预生成和字节序预折叠。收益看业务场景，但改起来简单、风险低。
6.2 那些看起来很美、实际白折腾的尝试
- 手动指令重排。我曾试图手工把每一轮的四五个独立计算重新排序，希望压过编译器的指令调度器，结果在多个平台上的收益平均不到2%，反而让代码变得极难维护。现在的编译器在热循环里的指令调度能力远比你想象中强，你该做的是提供正确的数据依赖信息。
- 极端循环展开。64轮全部展开会让I-cache和uop cache容量告急，老至强上甚至出现回退。最后发现展开到每轮算2个W、约16轮一组时，性能曲线最优。
- 在延迟敏感的小消息场景上硬上GPU。我们已经论证过，PCIe搬运和内核启动开销会吃掉所有收益。小消息、高实时性的业务，CPU多核批处理仍然是最优解。
6.3 生产环境里最终留下的组合
经历了三轮重构，我们生产环境最终的哈希服务形态是：一台无SHA-NI的旧节点池跑AVX2 8路多缓冲内核；新购置的节点直接用SHA-NI路径；所有节点统一使用无锁环形队列做批次分发；线程按物理核绑定，并按NUMA节点划分数据流；上层配合一个很小的最近哈希缓存，对重复出现的块先做廉价校验跳过重算。整套组合跑下来，相比最初OpenSSL直连的方案，总吞吐提升了大约2.5倍，哈希线程的算力利用率从35%上到了85%以上。
如果让我用一句话总结这段经历：榨干算力这件事，算法内核只占一半，剩下的一半全在数据怎么送到内核手里，以及你愿不愿意为了吞吐去接受那点可控的延迟。先把依赖链的账算清楚，再把队列和内存的账算清楚，最后再去碰那些炫酷的底层技巧，顺序反了，多半是要交学费的。
