ARM NEON向量代码为何比标量代码运行更慢？

我正在使用ARM NEON汇编（实际通过Intrinsics生成代码），发现一段展开的向量指令序列执行时间是等效标量循环的两倍。该向量序列可得到8个结果：

...
    vmov      r10, r11, d18
    vld1.32   {d21}, [r10]
    vadd.i32  d21, d21, d20
    vst1.32   {d21}, [r10]
    vld1.32   {d21}, [r11]
    vadd.i32  d21, d21, d20
    vst1.32   {d21}, [r11]
    vmov      r10, r11, d19
    ...
    vmov      r10, r11, d16
    ...
    vmov      r10, r11, d17
    ...

标量循环每次迭代生成1个结果，包含6条指令：

loop:
    ldr.w   r1, [r2], #4
    ldr.w   r3, [r4, r1, lsl #2]
        adds    r3, #1
    str.w   r3, [r4, r1, lsl #2]
        cmp r0, r2
        bhi.n   118 <loop>

按初步假设，向量序列约3条指令得1个结果，标量需6条，理论应快2倍，实际却慢2倍。即使进一步展开向量序列，仍比标量慢一倍。

我查阅《DEN0018A_neon_programmers_guide》及Cortex-A处理器手册，猜测影响性能的三个因素：

• ARM与NEON寄存器频繁转移
• 内存访问模式的缓存问题对NEON影响更大
• ARM与NEON流水线在LOAD/STORE序列上存在问题

因刚接触NEON架构，猜测可能偏离实际，恳请提供编写高效NEON Intrinsics代码的指导建议。

使用工具：arm-linux-gnueabihf-gcc-8.2.1

性能瓶颈分析与优化建议 #

一、你的猜测验证 #

1. ARM与NEON寄存器频繁转移：代码中大量vmov指令在通用寄存器（r10/r11）和NEON寄存器（d18/d19等）之间搬运地址，这是核心开销之一。Cortex-A系列中，ARM和NEON寄存器文件物理分离，vmov属于跨域访问，延迟高且占用流水线资源，频繁调用会严重拖慢执行速度。
2. 内存访问模式问题：标量循环是小粒度间接寻址，而NEON的vld1/vst1每次处理64位数据。如果地址来自分散存储，会导致缓存命中率暴跌——NEON宽内存访问对连续对齐的内存依赖极强，随机访问触发的缓存缺失开销远大于标量访问。
3. LOAD/STORE流水线冲突：NEON与ARM核心共享内存接口，若两者的load/store指令频繁交替执行，会引发带宽竞争，再加上vmov的跨域延迟，进一步加剧性能恶化。

二、高效NEON Intrinsics编写建议 #

1. 减少跨寄存器域交互

   • 避免手动用vmov在ARM和NEON寄存器间传递地址，尽量让编译器自动分配寄存器。用Intrinsics时，直接通过C变量传递地址，不要拆分到通用寄存器再转递。
   • 若需批量处理地址，提前将所有地址一次性加载到NEON寄存器，减少vmov调用次数。

2. 优化内存访问模式

   • 强制对齐：编译时添加-malign-neon选项，确保NEON访问的内存按数据宽度对齐（64位数据8字节对齐，128位16字节对齐），避免未对齐访问的额外开销。
   • 连续化分散数据：若处理的是分散地址数据，先批量加载到连续的NEON寄存器组完成计算，再统一写回，减少随机访问次数。
   • 预加载缓存：使用vld1的预加载变体或PLD指令，提前将后续需要的数据载入缓存，降低load操作的等待延迟。

3. 流水线并行调度

   • 让NEON计算指令（如vadd）与load/store指令重叠执行，利用处理器乱序执行能力。例如先发起多个load操作，再执行计算，最后执行store，避免load→计算→store的串行依赖链。
   • 合理循环展开：不要过度展开（避免寄存器压力过大），可通过-funroll-loops让编译器自动优化，或手动控制展开次数（如一次处理16个结果）。

4. 利用宽寄存器提升吞吐量

   • 若目标处理器支持128位NEON寄存器（如Cortex-A7/A15及以上），使用q寄存器替代d寄存器，一次处理4个32位数据。对应Intrinsics如vld1q_s32、vaddq_s32等，大幅提升数据处理量。

5. 编译器选项优化

   • 启用O2/O3优化：-O2或-O3，让编译器自动优化指令序列、寄存器分配和内存访问。
   • 指定目标架构：-mcpu=cortex-aXX（如-mcpu=cortex-a9），生成针对特定处理器的优化代码。
   • 开启NEON支持：添加-mfpu=neon选项（针对支持NEON的Cortex-A处理器）。

三、调试与验证方法 #

• 用perf分析瓶颈：通过perf stat查看缓存缺失率、指令周期数，确认是内存访问还是寄存器转移导致的性能问题。
• 检查生成的汇编：用gcc -S -O2 -mcpu=cortex-aXX -mfpu=neon your_code.c生成汇编代码，排查是否存在冗余vmov、未对齐内存访问等问题。

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