📚 课程目录第4章 ARM端算法落地

4. ARM端算法落地：NEON指令集优化、查表法加速CRF、定点化与浮点化取舍

ARM端落地，说白了就是让HDR融合算法在手机、平板的CPU上跑得又快又稳。很多同学在PC上调好了算法，一搬到ARM平台就卡成PPT。嗯，这里面的坑，我踩过不少。

我个人习惯把ARM端优化分成三个层次：计算加速、数据查找、精度取舍。咱们一个一个来拆。

4.1 NEON指令集：让CPU一次干四份活

NEON是ARM平台的SIMD（单指令多数据）扩展。你想想看，普通指令一次处理一个像素，NEON一次能处理四个、八个甚至十六个。这不就是白送的性能吗？

我在项目中遇到过最典型的场景——图像卷积。一个3x3的卷积核，用C语言写循环，处理一帧1080p图像要15ms。换成NEON intrinsics，直接降到4ms。差距就是这么明显。

4.1.1 核心操作：加载、计算、存储

NEON编程其实就三步：把数据装进128位寄存器，用SIMD指令算完，再把结果存回去。我常用的数据类型是 uint8x8_t（8个8位像素）和 float32x4_t（4个32位浮点）。

// 示例：NEON实现4个像素的加权融合
// 权重 w1 = 0.3, w2 = 0.7
float32x4_t v_pix1 = vld1q_f32(ptr1);   // 加载4个像素
float32x4_t v_pix2 = vld1q_f32(ptr2);
float32x4_t v_w1   = vdupq_n_f32(0.3f); // 复制权重
float32x4_t v_w2   = vdupq_n_f32(0.7f);

float32x4_t v_out = vmlaq_f32(vmulq_f32(v_pix1, v_w1), v_pix2, v_w2);
vst1q_f32(out_ptr, v_out);              // 存储结果

我的习惯：先写纯C版本验证逻辑，再逐函数替换成NEON。别一上来就全改，调试起来你会怀疑人生。

4.1.2 内存对齐：性能翻倍的关键

NEON对内存对齐非常敏感。数据如果没对齐到16字节边界，加载指令会慢30%-50%。我曾经因为一个结构体没加 __attribute__((aligned(16)))，性能死活上不去，查了两天才找到原因。

对齐方式	加载指令	性能损耗
16字节对齐	`vld1q_f32`	无
未对齐	`vld1q_f32`（自动处理）	约30%
手动处理未对齐	`vld1q_lane_f32` + 拼接	约50%

避坑：malloc分配的内存不一定16字节对齐。用 posix_memalign 或自己手动对齐。我吃过这个亏，图像边缘出现奇怪的条纹，就是因为对齐问题导致数据错位。

4.2 查表法加速CRF：空间换时间的老手艺

CRF（Camera Response Function）是HDR融合中的核心环节。它本质是一个非线性映射——输入像素值，输出校正后的值。如果每个像素都实时计算多项式或指数函数，那计算量就太大了。

查表法（LUT）的思路很简单：提前算好所有可能的输入对应的输出，存成一张表。运行时直接查表，一次内存访问代替几十次浮点运算。

4.2.1 构建LUT

对于8位图像，输入范围0-255，表大小只有256个元素。对于10位或12位RAW图，表大小是1024或4096。我建议在初始化阶段一次性构建好。

// 构建CRF查表
float lut[4096]; // 12位RAW图
for (int i = 0; i < 4096; i++) {
    float x = i / 4095.0f;           // 归一化到[0,1]
    lut[i] = crf_model(x);           // 调用CRF模型计算
}

4.2.2 查表 vs 实时计算

方法	单像素耗时	1080p总耗时	内存开销
实时浮点计算	~50ns	~100ms	0
查表法（8位）	~5ns	~10ms	256字节
查表法（12位）	~5ns	~10ms	4KB

  关键点：查表法加速比约10倍，而且内存开销几乎可以忽略。对于嵌入式设备，这是性价比最高的优化手段之一。

4.2.3 查表法的陷阱

查表法不是万能的。我遇到过两个坑：

缓存污染：如果表太大（比如16位输入，表大小65536），频繁查表会把CPU缓存冲垮，性能反而下降。解决方案：用二级查表或插值查表。
精度损失：表是离散的，输入值落在两个表项之间时，直接取整会有误差。我习惯用线性插值：out = lut[floor(x)] * (1-frac) + lut[ceil(x)] * frac。

4.3 定点化与浮点化：精度和速度的博弈

ARM平台有硬件浮点单元（FPU），但浮点运算还是比定点慢。尤其是老一些的ARM Cortex-A系列，浮点吞吐量只有定点的1/3到1/2。

定点化的思路：把浮点数放大成整数，用整数运算代替浮点运算，最后再缩回去。

4.3.1 Q格式定点数

我常用Q15格式（1位符号，15位小数）和Q31格式（1位符号，31位小数）。比如浮点数0.5，用Q15表示就是 0.5 * 2^15 = 16384。

// 浮点版本
float a = 0.3f, b = 0.7f;
float c = a * b;  // 0.21

// Q15定点版本
int16_t a_q = (int16_t)(0.3f * 32768);  // 9830
int16_t b_q = (int16_t)(0.7f * 32768);  // 22938
int32_t c_q = ((int32_t)a_q * b_q) >> 15;  // 6881
float c_f = c_q / 32768.0f;  // 0.20999

4.3.2 什么时候用定点，什么时候用浮点？

场景	推荐方案	理由
CRF查表构建	浮点	只在初始化执行一次，精度优先
像素级融合	定点或NEON浮点	计算量大，定点更快；NEON浮点也可接受
权重计算	浮点	涉及指数、除法，定点实现太复杂
直方图统计	定点	纯整数累加，没必要用浮点

我的建议：不要全盘定点化。把热点函数（占80%时间的20%代码）定点化就够了。其他部分保持浮点，开发效率更高。

4.4 本章知识体系

下面这张图总结了ARM端算法落地的三个核心维度，以及它们之间的关系。

4.5 实战建议：从PC到ARM的迁移步骤

最后，我分享一下从PC原型到ARM落地的标准流程。这套流程我在三个项目里验证过，基本没出过大问题。

第一步：PC上跑通浮点版本。用OpenCV或纯C实现，确保算法逻辑正确。
第二步：交叉编译到ARM，跑基准性能。别优化，先看原始速度。我见过有人一上来就NEON，结果算法本身有bug，白忙活一周。
第三步：性能分析。用perf或简单的计时器，找到热点函数。记住，不要猜，要测。
第四步：热点函数逐个优化。先上查表法（改动最小，收益最大），再上NEON，最后考虑定点化。
第五步：验证精度。优化后的输出与原始浮点版本对比，PSNR要大于45dB，肉眼不能看出差异。

我曾经踩过的坑：在一个项目中，我优化完NEON版本，速度提升了5倍，但图像出现了轻微的偏色。查了两天发现是NEON加载数据时字节序搞反了。所以，每优化一步，都要做一次像素级对比验证。

ARM端优化没有银弹。查表法、NEON、定点化，每个工具都有适用场景。我的经验是：先做对，再做快。优化到满足帧率要求就停手，别追求极致性能而牺牲了代码可维护性。