先说个有点劝退的事实我第一次打开 ARM Compute Library 的源码目录时第一反应是“这玩意怎么这么大”。目录树拉到底要滚好几屏SCons、CMake、NEON 汇编、OpenCL 内核源码混在一起看起来不像一个库更像一座小型操作系统。但真的花时间把里面的工程结构摸清之后我才意识到这套设计的高明之处它用一套公共 API 同时支撑 CPU 和 GPU 两套后端把 NEON 向量化、OpenCL 内核、交叉编译工具链这些东西全部收纳进一个可维护的工程里。如果你平时做嵌入式开发、搞 AI 推理部署或者只是对高性能计算库的结构感兴趣这篇笔记应该能帮你少走不少弯路。下文就抓着标题里的三个关键词拆解CMake解决“怎么组织构建”NEON解决“CPU 上如何用 SIMD 提速”OpenCL解决“GPU 后端如何与 CPU 保持同一套接口”。最后我会结合自己实际编译、移植、调试中踩过的坑把纯看代码看不出来的经验一并补上。1. 先看全局Compute Library 到底长什么样1.1 一套代码两个后端ARM Compute Library下面用 ACL 指代的定位很明确给 ARM 平台上的神经网络推理、图像处理和数学运算提供高性能实现。它的特别之处是“掐着硬件特性做分叉”——同一份功能你在源码里能看到两个并行分支NEGEMM、NEGEMMConvolutionLayer这类以NE开头的跑在 CPU 上底层是 NEON/SVE 指令CLGEMM、CLGEMMConvolutionLayer这类以CL开头的跑在 GPU 上底层是 OpenCL 内核。初学者第一次看会觉得这是“重复代码”。实际上这正是高性能计算库常用的工程手段接口层收口实现层按后端分家。你在应用层写的“做一次卷积”概念是统一的但底层的内存布局、线程调度、缓存友好处理完全不同硬塞进一个公共抽象里反而会让每一条路径都被拖累。分成两套实现才能让 NEON 和 OpenCL 各自做到极致。1.2 目录层级的“三层分离”ACL 的目录结构可以粗略理解成三层arm_compute/ 公开 API 和核心接口头文件 src/ 实现CPU/GPU kernel、执行器、调度器 examples/ tests/ 示例、验证用例、benchmark如果你是做二次开发主要看arm_compute/下面的头文件和src/core、src/runtime这两块。src/core里NEON/kernels/放 CPU kernel 实现CL/kernels/放 OpenCL kernel 的 C 封装类而真正的.cl内核源码在src/core/CL/cl_kernels/。这种“接口头文件 实现源文件 平台内核源码”的分离最大好处是上层调用方看到稳定的头文件内部换成什么指令集、怎么调整内核都不需要惊动调用方。更细一点看include/arm_compute/core/下面还能见到CPP、NEON、CL这种子目录分别对应纯 C 参考实现、CPU SIMD 实现、GPU 实现所需的数据结构和接口。每个新算子加入时基本都要在这几层里同步补上对应文件这也是仓库体量大的原因之一。1.3 构建脚本为什么两套并存这是很多人刚上手时最容易懵的地方为什么一个库既有SConscript又有CMakeLists.txtACL 最早的主力构建工具是 SCons一条典型命令长这样scons Werror1 -j8 debug0 asserts1 neon1 opencl1 examples1 archarmv8-aSCons 用 Python 写构建脚本可读性不错但在对接大型工程比如 Android NDK、AI 推理框架的第三方库集成时生态上早就是 CMake 的天下。所以新版本 ACL 补上了 CMake 支持为的就是让外部工程能更顺滑地把 ACL 当普通 CMake 依赖引用也让 CI 里做“架构 x 编译器 x 开关”的构建矩阵更便捷。我的个人建议是单独编译、跑样例、折腾 kernel 时用 SCons 更顺手要集成进别的 CMake 工程或者需要按不同架构批量交叉编译时优先看 CMake 这条路。2. CMake 构建从零把库编出来2.1 关键 CMake 开关与语义CMake 方式的最外层入口是根目录的CMakeLists.txt。你会在里面看到一大批ARM_COMPUTE_*开头的选项常见几个如下选项作用常用值ARM_COMPUTE_NEON是否编译 CPU NEON 后端ON/OFFARM_COMPUTE_OPENCL是否编译 GPU OpenCL 后端ON/OFFARM_COMPUTE_ARCH目标架构armv7-a/armv8-a/armv8.2-aARM_COMPUTE_EXAMPLES是否编译 examplesON/OFFARM_COMPUTE_ASSERTS是否开启断言ON/OFFrelease 建议 OFF具体选项名会随版本小改以你拉下来的源码和根目录 README 为准。这组开关背后的设计逻辑很值得学构建配置不做自动探测而是显式声明。高性能计算场景里“编译产物服务于什么平台”直接决定内部用哪套指令集自动探测在这种场景下反而容易埋雷。比如你要编 armv7 版本明确指定架构比依赖编译器默认值靠谱得多。2.2 交叉编译工具链文件怎么配ARM 平台上最常见的需求就是“在 x86 的 Linux 机器上编出 ARM 版”CMake 里靠 toolchain 文件解决。ACL 仓库的cmake/toolchains/目录自带多个现成文件比如aarch64-linux-gnu.cmake。一个典型的交叉编译命令行是cmake -S . -B build-aarch64 \ -DCMAKE_TOOLCHAIN_FILEcmake/toolchains/aarch64-linux-gnu.cmake \ -DARM_COMPUTE_ARCHarmv8-a \ -DARM_COMPUTE_NEONON \ -DARM_COMPUTE_OPENCLOFF \ -DARM_COMPUTE_EXAMPLESON cmake --build build-aarch64 -j8toolchain 文件本质做的事就三件告诉 CMake 目标系统是 Linux、目标 CPU 架构是 aarch64、C/C 编译器用aarch64-linux-gnu-gcc和aarch64-linux-gnu-g。如果本机没有配套的交叉工具链需要先装gcc-aarch64-linux-gnu和g-aarch64-linux-gnu这类包否则 CMake 在第一步编译器检测就会失败。2.3 完整编译步骤主机版与 ARM 版我自己常用的流程分两种都验证过很多次主机版先验证逻辑-DARM_COMPUTE_NEONON -DARM_COMPUTE_OPENCLOFF直接cmake --build即可。适合跑 examples、改 kernel 验功能不用碰任何 ARM 交叉环境。ARM 版真正部署到板子必须在干净的交叉工具链下编译并且把 NEON、OpenCL 按目标平台的能力明确打开或关闭。比如树莓派 4B 是 aarch64 平台-DARM_COMPUTE_ARCHarmv8-a -DARM_COMPUTE_NEONON编出来的库才能吃满 NEON 指令。编译完产物在build/examples/下能看到一堆可执行文件比如neon_convolution、cl_convolution。我曾在树莓派 4B 上跑neon_convolution对比同功能朴素 C 实现做了缓存友好处理之后耗时能缩短接近一个数量级。性能差异非常直观这也是为什么值得折腾这套构建流程。2.4 我在 CMake 上踩过的三个坑坑一CMake 版本过老。报错里那句“CMake 3.1.3...3.26 or higher is required. You are running version 2.8.12.2”我见过不止一次。很多老系统的包管理器默认带的 CMake 还是 2.8 或 3.10而新版 ACL 要求 CMake 3.26 起步。解决办法是去官网下新版二进制包或者用 pip 装的cmake不要指望系统源自动帮你升级到足够新的版本。坑二只装了 gcc 没装 g。做 aarch64 交叉编译时如果只装了gcc-aarch64-linux-gnu没装g-aarch64-linux-gnuCMake 检测编译器会在奇怪的地方崩溃提示信息也不直接。建议配置环境前先执行dpkg -l | grep aarch64确认gcc、g、binutils齐全。坑三OpenCL 头文件或 ICD 缺失。打开 OpenCL 后端后ACL 需要 OpenCL 头文件和运行时 loader。很多嵌入式 Linux 板子默认不带得先装opencl-headers、ocl-icd-libopencl1或者厂商提供的 OpenCL SDK。如果你只是调试 CPU 路径建议先关掉 OpenCL别让环境问题挡在 NEON 前面。3. NEON 源码解剖CPU 上如何榨干 SIMD3.1 NEON 背后其实是“四路浮点”NEON 是 ARM 的 SIMD 扩展一次寄存器操作可以同时处理 128 位数据。对 fp32 来说就是 4 个 float 一起算对 fp16 是 8 个对 int8 能达到 16 个。理解这个数量级再看源码里的 NEON 内核就顺畅了它们大量使用vld1q_f32、vaddq_f32、vmlaq_f32这类 intrinsics名字末尾的q表示 128 位寄存器宽度f32表示单精度浮点类型。ACL 的 NEON 代码有个明显特点内核内部很少写“逐个元素处理”的朴素循环而是把运算组织成“向量级”操作。这样 CPU 每执行一条向量指令相当于把循环展开 4 倍甚至 16 倍再配合乱序执行和 FMA乘加融合吞吐量自然就上去了。3.2 Window、Iterator 与 kernel 骨架NEON 内核实则上非常规整基本骨架可以看成三步拿到运行窗口、构造迭代器、在窗口内做向量计算。一个极简化的示意如下void MyNeonKernel::run(const Window window, const ThreadInfo info) { Window win window.collapse_if_possible(Window::DimX, 1); Iterator in(_input, win); Iterator out(_output, win); execute_window_loop(win, [](const Coordinates id) { float32x4_t a vld1q_f32(reinterpret_castconst float *(in.ptr())); float32x4_t b vaddq_f32(a, vdupq_n_f32(1.0f)); vst1q_f32(reinterpret_castfloat *(out.ptr()), b); }, in, out); }这里的Window定义整个张量的迭代空间Iterator负责在迭代空间里移动指针真正干活的是 lambda 里的向量指令。这种抽象的好处非常明显调度器可以随意切分Window交给不同线程每个线程各跑一段kernel 作者完全不用关心线程同步问题。我在自己项目的多线程改造里也复制过这个模式确实省心。3.3 从 GEMM 看数据布局的重要性如果只看逐元素算子你会觉得 NEON 不过如此。真正体现工程功力的地方是 GEMM通用矩阵乘数据越接近缓存、访存越连续向量化收益越大。ACL 里NEGEMM相关代码会看到大量关于数据布局的操作比如把输入张量整理成 NHWC高度、宽度、通道、批次的连续排布或者做 interleave/block 预处理目的是让后续的vmlaq_f32能持续吃到连续内存数据。这也是我建议初学者先看 GEMM、而不是先看 ReLU 之类算子的原因只有在访存密集的负载里你才能体会“数据布局决定性能上限”这句话的分量。换个角度说NEON 向量指令只是最后一步的“临门一脚”前面还有一整条数据排布和缓存优化流水线等着你去理解。3.4 什么时候需要手写汇编intrinsics 已经很方便但 ACL 源码里仍保留了不少手写汇编主要集中在src/core/NEON/kernels/assembly/下面。原因是关键 Hot Loop 里手写汇编可以精确控制寄存器分配、减少不必要的保存恢复开销。编译器有时候会保守地多保存寄存器汇编作者可以“用完即弃”把循环体压到最短。不过手写汇编代价是移植性差换一个微架构可能要重新调优。ACL 的策略很典型把汇编限制在最核心的 GEMM、卷积路径上普通算子还是用 intrinsics。这既保住了关键路径性能又照顾到整体可维护性。这个“二八原则”非常值得在自己的项目里借鉴不要一上来就全员上汇编。4. OpenCL 后端GPU 内核的工程化组织4.1 .cl 文件与内核库的封装GPU 分支的核心代码在src/core/CL/下真正的工作负载全部体现在.cl内核源码里。ACL 把大量内核文件放在src/core/CL/cl_kernels/目录卷积、池化、激活、GEMM 各自有对应的.cl文件命名也和 C 层函数一一对应。这带来一个实际工程问题一堆.cl文件运行时去哪儿找如果目标平台文件系统受限运行时加载源文件很容易失败。ACL 的做法是提供嵌入机制构建时把.cl源码打包进库产物或生成头文件部署时不需要额外携带多个 kernel 文件也降低了路径配置出错的概率。CLKernelLibrary这个类就是运行时统一管理内核 sources 和 program 的入口。4.2 内核怎么从源码变成可执行程序OpenCL 和 CUDA 有个很大的区别OpenCL 内核是运行时才编译的。ACL 里CLKernelLibrary拿到一段.cl源码后会在第一次使用时调用clBuildProgram编译出cl_kernel再放进缓存。第二次用到同一个内核时直接取缓存省掉编译时间。这里有几个调优点值得关注编译选项里常见的-cl-fast-relaxed-math能显著提升 FP32 吞吐但会牺牲部分精度是否开启要看算法容错度缓存策略很关键ACL 会尽量让同一批内核编译结果复用避免每帧重复触发编译如果目标 GPU 支持 OpenCL 2.0还可以启用 SVM、子组等功能但兼容性会变差所以 ACL 里往往有成对的条件编译分支。从调试角度说遇到“第一次调用卡顿很久”的现象多半就是 OpenCL 正在现场编译内核。性能测试时必须提前跑几轮热身否则测出来的数据全是编译开销不具备参考性。4.3 调度器与队列一次 enqueue 的完整旅程OpenCL 后端的执行逻辑可以简化成函数层调用kernel.run(window)内部走CLScheduler把命令提交到cl_command_queue再由 GPU 驱动派发到硬件。CLScheduler::get().enqueue(kernel, window);这段代码看起来简单背后有个关键设计调度器是单例。整个进程共享一个CLScheduler它维护着与设备绑定的cl_context、cl_command_queue也决定了命令是按顺序执行还是允许乱序。ACL 默认让每次 enqueue 之间保持合理依赖同时允许驱动在允许范围内做优化。这种“调度器单例 队列统一提交”的模式在各类多后端计算库中非常典型建议直接抄进自己的 GPU 加速模块里。4.4 双后端切换代码怎么写才不“精神分裂”同时开启 NEON 和 OpenCL 后如何在代码里选后端ACL 的答案很粗暴也很实用不搞运行时自动选择而是让用户通过选择不同的函数类来决定路径。想跑 CPU 就用NEGEMM想跑 GPU 就用CLGEMM同一个应用如果两套代码都写了就相当于各自独立的两条流水线。这种设计的优势是可控性和可预测性。嵌入式场景里“自动选择最优后端”听起来美好但不同板上驱动、内存带宽差异太大自动判断经常猜错。ACL 宁可把选择权交给开发者配合 profiling 工具人工决定。你如果也在做跨平台计算库这个取舍值得参考不要过度设计调度器先把两条路径都做扎实。5. 从这套源码里能带走什么5.1 多后端共存的“命名即接口”套路ACL 最值得学的工程模式是用名称前缀表达后端归属。NE开头是 CPU NEONCL开头是 GPU OpenCLCPP开头是纯 C 参考实现无 SIMD。这种命名规范等于零成本的接口表达不需要查文档看一眼类名就知道它跑在什么硬件上、该去看哪一份实现。在新增算子时这个套路还会强制贡献者同时考虑 CPU 和 GPU 两条路径避免出现“核心算法一边实现了另一边忘了补”的情况。我自己维护的小型算子库也沿用了这套命名法确实让多后端代码的导航效率高了很多。5.2 测试与验证的组织方式ACL 的测试放在tests/下不是简单堆几个单元测试而是分层的结构tests/validation/跑功能性验证tests/benchmark/跑性能基准tests/datasets/提供大量输入数据组合。验证用例能覆盖不同后端、不同数据类型、不同维度组合看起来就像一本“活的使用说明书”。我自己的经验是想搞懂一个新 kernel 的语义与其逐行猜源码不如直接看它对应的 validation 测试怎么构造输入、怎么标定输出。很多时候一个数据布局为什么要那么排、一个边界条件为什么要那么处理跑一遍对比测试就全明白了。5.3 后续可以怎么继续深入如果你已经能把 CMake 那套流程跑通下一步我建议按这个顺序深入挑一个最简单的算子比如 Add 或 Activate从 Function 层追到 Kernel 层最后看到 intrinsics打开NEGEMM源码配合 NHWC 布局搞懂 interleave 到底在干什么找一块带 Mali 或 Adreno GPU 的开发板跑cl_convolution观察第一次内核编译带来的延迟如果手上是支持 SVE 的 CPU再看看 SVE 路径体会从“定长向量”到“可变长向量”的变化是如何反馈到工程组织上的。说实话我编译、移植 ACL 到不同板子时最大的体会不是某个具体函数写得多巧妙而是这套工程把“性能”当成第一等公民来组织构建时显式声明架构实现时按后端分流运行时用调度器统一收口。这三层结构互相支撑才让一个同时覆盖 CPU、GPU、不同指令集的库变得可维护。最后分享一个小技巧如果你看源码被某个内核绕晕就在tests/validation/里找对应名字把输入输出形状打印出来做对比很多“为什么这么写”的疑问跑一遍自然就通了。