ARM NEON问题：简单数组乘法场景普通C代码比NEON快如何优化？

首先纠正一个认知误区：你注释掉vst1q_u16语句后速度变快是假象，此时编译器会判定整个循环的计算结果没有被使用，直接将循环代码全部优化删除，得到的性能数据没有参考意义。你遇到的性能瓶颈核心是内存访问对齐失效、流水线停顿、没有利用预取隐藏内存延迟三个问题，具体优化方案如下：

优化建议 #

• 强制输入输出地址对齐 #

  NEON的128位加载/存储指令(vld1q_u8/vst1q_u16)在访问未对齐地址时，性能会下降3~10倍，这是存储操作慢的最常见原因。要求：

  • 输入的uint8数组首地址16字节对齐：静态声明用__attribute__((aligned(16)))，动态分配用posix_memalign或aligned_alloc分配16字节对齐的内存
  • 输出的uint16数组首地址16字节对齐：要求同上
    如果实在无法保证对齐，可以把存储指令换成未对齐版本vst1q_u16_x，但性能还是会比对齐场景低30%左右。

• 开启正确的编译器优化选项 #

  必须开启-O2/O3优化，同时指定ARM架构参数：32位ARM加编译参数-march=armv7-a -mfpu=neon -mfloat-abi=hard，64位ARM加-march=armv8-a+simd，避免编译器把NEON intrinsic翻译成模拟函数调用。

• 循环展开+内存预取，隐藏访问延迟 #

  你当前的循环单次处理16个元素，加载、计算、存储串行执行，没有利用CPU流水线的并行能力。优化为单次处理4组（共64个输入元素），同时加入预取指令，提前把后续要处理的数据加载到Cache中，完全掩盖内存访问的延迟。

• 优化指令序列，减少数据依赖 #

  调整指令顺序为多块交叉执行：加载块1->计算块1->加载块2->存储块1->计算块2->加载块3->存储块2... 让计算和存储完全并行。

优化后代码示例 #

#include <arm_neon.h>

void neon_multiply(uint8_t *in_ptr, uint16_t *out_ptr, int out_size, uint16_t scale_factor)
{
    // 要求in_ptr 16字节对齐，out_ptr 16字节对齐，out_size为16的整数倍
    const int step = 64; // 单次处理64个输入元素，对应64个输出元素
    int loop_cnt = out_size / step;
    int remain = out_size % step;

    const uint16x8_t scale_v = vdupq_n_u16(scale_factor); // 提前把缩放因子扩成向量复用

    for (int i = 0; i < loop_cnt; i++) {
        // 预取后续256字节的输入、512字节的输出（可根据CPU Cache行大小调整偏移）
        __builtin_prefetch(in_ptr + 256, 0, 1);
        __builtin_prefetch(out_ptr + 256, 1, 1);

        // 加载4组输入，共64个uint8
        uint8x16_t in0 = vld1q_u8(in_ptr);
        uint8x16_t in1 = vld1q_u8(in_ptr + 16);
        uint8x16_t in2 = vld1q_u8(in_ptr + 32);
        uint8x16_t in3 = vld1q_u8(in_ptr + 48);
        in_ptr += step;

        // 转16位+乘法
        uint16x8_t res0_l = vmulq_u16(vmovl_u8(vget_low_u8(in0)), scale_v);
        uint16x8_t res0_h = vmulq_u16(vmovl_u8(vget_high_u8(in0)), scale_v);
        uint16x8_t res1_l = vmulq_u16(vmovl_u8(vget_low_u8(in1)), scale_v);
        uint16x8_t res1_h = vmulq_u16(vmovl_u8(vget_high_u8(in1)), scale_v);
        uint16x8_t res2_l = vmulq_u16(vmovl_u8(vget_low_u8(in2)), scale_v);
        uint16x8_t res2_h = vmulq_u16(vmovl_u8(vget_high_u8(in2)), scale_v);
        uint16x8_t res3_l = vmulq_u16(vmovl_u8(vget_low_u8(in3)), scale_v);
        uint16x8_t res3_h = vmulq_u16(vmovl_u8(vget_high_u8(in3)), scale_v);

        // 批量存储
        vst1q_u16(out_ptr, res0_l);
        vst1q_u16(out_ptr + 8, res0_h);
        vst1q_u16(out_ptr + 16, res1_l);
        vst1q_u16(out_ptr + 24, res1_h);
        vst1q_u16(out_ptr + 32, res2_l);
        vst1q_u16(out_ptr + 40, res2_h);
        vst1q_u16(out_ptr + 48, res3_l);
        vst1q_u16(out_ptr + 56, res3_h);
        out_ptr += step;
    }

    // 处理剩余元素，用C代码即可，不影响主循环性能
    for (int i = 0; i < remain; i++) {
        out_ptr[i] = (uint16_t)in_ptr[i] * scale_factor;
    }
}

优化后性能一般可以达到原生C代码的3~5倍，如果还是达不到预期，可以检查是否有Cache溢出的问题，如果数组大小超过L2 Cache，适当调低单次处理的step大小即可。

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