如何处理SIMD循环中无法填满寄存器的剩余窄数据？

在处理32位像素数据的AVX512循环中，通常会采用如下结构的代码：

fnAVX512(npixels) {
    while (npixels >= 16) {process_row; npixels -= 16;}
}

循环结束后，npixels可能不为0，或是初始传入的数据本身就属于窄数据（像素数少于16）。针对这类剩余数据的处理，可采用以下三种方案：

• 掩码加载处理：使用掩码将数据加载到寄存器，排除无关内存区域。需要明确的是，_mm256_maskz_loadu_epiN这类带掩码的非对齐加载指令不会读取掩码为0对应的内存位置，因此不会引发内存访问异常，是安全的处理方式。
• 标量回退处理：直接用标量代码处理剩余1-15个像素，但标量性能仅为AVX的约10%，剩余像素较多时会显著拉低整体执行效率。
• 向量降级处理：基于已有的128/256位向量代码逐层降级处理，示例代码如下：

fnAVX512(npixels) {
    while (npixels >= 16) {process_row; npixels -= 16;}
    fnAVX2(npixels);
}

fnAVX2(npixels) {
    while (npixels >= 8) {process_row; npixels -= 8;}
    fnSSE(npixels);
}
// 后续可扩展SSE处理逻辑，最终对3个及以下像素用标量处理

2023年MMX指令集在特定场景的实用性 #

针对8位颜色通道打包的32位整数这类场景，MMX指令集在2023年已无实用价值：

• 现代CPU虽仍支持MMX，但MMX寄存器与X87浮点寄存器共享，使用时需额外的状态切换开销，会干扰浮点运算执行。
• MMX仅支持64位向量宽度，处理效率远低于SSE/AVX等128位及以上的后续向量指令集。
• 现代编译器对MMX的优化支持已非常有限，编写MMX代码开发成本高，且难以获得稳定性能收益。
• 对于8位颜色通道的打包处理，SSE2的pack/unpack指令、AVX系列的向量操作已能更高效完成，完全可替代MMX的功能。

内容的提问来源于stack exchange，提问作者martona