性能调优案例2：视频编解码器优化，SIMD指令集应用

视频编解码，说白了就是跟像素点打交道。一帧1080p的画面，1920×1080个像素，每秒30帧，你算算数据量有多大？我早年做嵌入式视频播放器时，CPU跑得直冒烟，画面还卡成PPT。后来才明白，瓶颈不在算法逻辑，而在数据搬运和计算方式。

今天我们就拿一个实际的视频编解码优化案例，聊聊SIMD指令集怎么派上用场。嗯，这里说的SIMD，就是单指令多数据——一条指令同时处理多个数据，比如一次算8个像素点。

1. 先看痛点：像素处理为什么慢？

视频编解码里有个基础操作：像素差值计算。比如运动估计时，需要计算两个宏块（16×16像素）的绝对差值和（SAD）。

传统写法长这样：

// 普通C实现：逐像素计算SAD
uint32_t sad_c(uint8_t *src1, uint8_t *src2, int stride, int block_size) {
    uint32_t sum = 0;
    for (int y = 0; y < block_size; y++) {
        for (int x = 0; x < block_size; x++) {
            int diff = src1[x] - src2[x];
            sum += (diff >= 0) ? diff : -diff;
        }
        src1 += stride;
        src2 += stride;
    }
    return sum;
}

这段代码逻辑没错，但性能惨不忍睹。为什么？
因为每次循环只处理1个像素，CPU大部分时间花在循环控制和分支判断上。我当年用perf工具一跑，发现这个函数占了编码器总时间的40%以上——这就是典型的“计算密集+数据并行”场景，SIMD的天生舞台。

2. SIMD优化实战：从SSE到AVX2

我个人习惯先看指令集支持情况。x86平台，从SSE2（128位）到AVX2（256位），宽度翻倍，性能也翻倍。ARM平台则是NEON，道理一样。

咱们先看SSE2版本：

#include <emmintrin.h>  // SSE2头文件

uint32_t sad_sse2(uint8_t *src1, uint8_t *src2, int stride, int block_size) {
    __m128i sum_vec = _mm_setzero_si128();
    
    for (int y = 0; y < block_size; y++) {
        // 一次加载16个字节（128位）
        __m128i a = _mm_loadu_si128((__m128i*)src1);
        __m128i b = _mm_loadu_si128((__m128i*)src2);
        
        // 计算绝对差值（SSE2没有直接的abs指令，需要技巧）
        __m128i diff = _mm_subs_epu8(a, b);  // 无符号饱和减
        __m128i diff2 = _mm_subs_epu8(b, a); // 反过来减
        __m128i abs_diff = _mm_adds_epu8(diff, diff2); // 两者相加得到绝对值
        
        // 累加到16位宽的向量中（避免溢出）
        sum_vec = _mm_add_epi16(sum_vec, _mm_unpacklo_epi8(abs_diff, _mm_setzero_si128()));
        sum_vec = _mm_add_epi16(sum_vec, _mm_unpackhi_epi8(abs_diff, _mm_setzero_si128()));
        
        src1 += stride;
        src2 += stride;
    }
    
    // 将向量中的8个16位数水平相加
    uint32_t sum = 0;
    uint16_t temp[8];
    _mm_storeu_si128((__m128i*)temp, sum_vec);
    for (int i = 0; i < 8; i++) sum += temp[i];
    return sum;
}

这段代码一次处理16个像素，比逐像素快了将近10倍。但别急着高兴——还有优化空间。

3. 再进一步：AVX2与循环展开

AVX2寄存器宽度256位，一次能处理32个像素。配合循环展开，效果更猛：

#include <immintrin.h>  // AVX2头文件

uint32_t sad_avx2_unroll(uint8_t *src1, uint8_t *src2, int stride, int block_size) {
    __m256i sum_vec = _mm256_setzero_si256();
    
    for (int y = 0; y < block_size; y += 2) {  // 一次处理两行
        // 第一行
        __m256i a1 = _mm256_loadu_si256((__m256i*)src1);
        __m256i b1 = _mm256_loadu_si256((__m256i*)src2);
        __m256i diff1 = _mm256_subs_epu8(a1, b1);
        __m256i diff2 = _mm256_subs_epu8(b1, a1);
        __m256i abs1 = _mm256_adds_epu8(diff1, diff2);
        
        // 第二行
        __m256i a2 = _mm256_loadu_si256((__m256i*)(src1 + stride));
        __m256i b2 = _mm256_loadu_si256((__m256i*)(src2 + stride));
        __m256i diff3 = _mm256_subs_epu8(a2, b2);
        __m256i diff4 = _mm256_subs_epu8(b2, a2);
        __m256i abs2 = _mm256_adds_epu8(diff3, diff4);
        
        // 合并两行结果到16位
        __m256i abs_combined = _mm256_hadd_epi16(
            _mm256_unpacklo_epi8(abs1, _mm256_setzero_si256()),
            _mm256_unpackhi_epi8(abs1, _mm256_setzero_si256())
        );
        __m256i abs_combined2 = _mm256_hadd_epi16(
            _mm256_unpacklo_epi8(abs2, _mm256_setzero_si256()),
            _mm256_unpackhi_epi8(abs2, _mm256_setzero_si256())
        );
        
        sum_vec = _mm256_add_epi16(sum_vec, abs_combined);
        sum_vec = _mm256_add_epi16(sum_vec, abs_combined2);
        
        src1 += stride * 2;
        src2 += stride * 2;
    }
    
    // 水平归约
    __m128i sum_high = _mm256_extracti128_si256(sum_vec, 1);
    __m128i sum_low = _mm256_castsi256_si128(sum_vec);
    __m128i sum128 = _mm_add_epi16(sum_high, sum_low);
    
    uint16_t temp[8];
    _mm_storeu_si128((__m128i*)temp, sum128);
    uint32_t sum = 0;
    for (int i = 0; i < 8; i++) sum += temp[i];
    return sum;
}

这段代码一次处理两行、每行32个像素，总共64个像素。相比原始C代码，加速比能达到20~30倍。我在项目中实测过，一个1080p的H.264编码器，运动估计模块从原来的45ms降到了2ms以内。

4. 性能对比：数据说话

咱们用实际数据看看优化效果。测试环境：i7-10750H，单核，16×16宏块SAD计算，重复100万次取平均。

你看，从纯C到AVX2+展开，性能提升了28倍。这还只是SAD一个函数。整个编码器里类似的函数还有十多个——积少成多，整体性能就翻倍了。

5. 知识体系：SIMD优化的核心逻辑

说了这么多，咱们用一张图把思路理清楚：

这张图就是我平时做SIMD优化的标准流程。你想想看，第一步永远是“识别热点”——别上来就优化，先拿perf跑一遍，找到真正耗时的函数。我见过太多人把时间花在优化一个只占1%时间的函数上，得不偿失。

6. 避坑指南：我踩过的几个坑

• 内存对齐问题： 我曾经在ARM NEON上吃过亏。_mm_loadu_si128（非对齐加载）比_mm_load_si128（对齐加载）慢20%左右。如果数据能保证16字节对齐，尽量用对齐版本。视频帧的起始地址通常可以对齐，但行内偏移要注意。
• 寄存器溢出： 循环展开太多，寄存器不够用，编译器会把变量 spill 到栈上。我一般用__attribute__((always_inline))配合-O3，然后看汇编代码确认寄存器使用情况。
• 水平归约的陷阱： 最后把向量数据归约成标量时，别用循环一个个加。用_mm_hadd_epi16（水平相加）或者_mm_sad_epu8（绝对差值和）这类专用指令，效率高得多。
• 跨平台兼容： 别只写x86的SSE/AVX代码。我习惯用#ifdef __SSE2__做条件编译，同时保留纯C fallback。这样在ARM或老CPU上也能跑。

7. 总结：SIMD优化的核心思想

说白了，SIMD优化就三句话：

1. 找对热点——别瞎优化，用数据说话。
2. 用对指令——SSE2够用就别上AVX512，兼容性更重要。
3. 算对结果——优化后一定要做正确性验证，我吃过“加速10倍但画面花屏”的亏。

视频编解码的SIMD优化，本质上就是把串行思维改成并行思维。你想想看，一个像素一个像素地算，跟一次算32个像素，效率能一样吗？但前提是——你得确保数据之间没有依赖关系。好在视频编解码里，大部分像素操作都是独立的，这正是SIMD大显身手的地方。

嗯，今天就聊到这儿。下次你写视频处理代码时，不妨先想想：这段逻辑能不能用SIMD加速？ 如果能，那就动手试试吧。

公众号:蓝海资料掘金营，微信deep3321