先把结论放前面你在手机上跑 TensorFlow Lite、跑 ncnn、跑各种端侧推理引擎底层真正出算力的那一层很大概率就是 Arm Compute Library简称 ACL。这个库用 CMake 把 NEON 和 OpenCL 两条内核路径组织在一个工程里既能在 CPU 上用 SIMD 指令榨干每一条流水线也能在 Mali/Adreno 这类 GPU 上把卷积、矩阵乘甩给 OpenCL 去执行。很多做端侧部署的同学都把它当成黑盒只知道链接 libarm_compute.so却没有想过它的目录为什么这样摆、CMake 的开关为什么这么多、NEON 内核里那个 Window 到底是怎么驱动循环的。这篇文章就把我从构建系统一路看到内核实现的源码阅读笔记整理出来适合想深入 ARM 高性能计算、或者准备自己写算子库底座的工程师参考。基础一般也没关系关键概念我会拆开讲。1. 从仓库布局看架构定位三套后端、两层接口、一个核心迭代模型1.1 镜像目录公共头文件和实现源码各占一层我第一次把 Compute Library 克隆下来的时候第一反应是目录怎么这么“规矩”。顶层的arm_compute/和src/是严格镜像的你在arm_compute/core/NEON/kernels/下能找到某个 kernel 的公开头文件实现就一定在src/core/NEON/kernels/下等着你。这种布局不是随手拍的它保证了“接口稳定、实现随便换”。arm_compute/ # 对外暴露的头文件 ├── core/ # Tensor、Window、Kernel 等核心抽象 ├── runtime/ # 运行时对象NEON/CL 的 Tensor、Scheduler └── graph/ # 图 API可选模块 src/ ├── core/ # 核心实现 │ ├── NEON/kernels/ # CPU 内核实现 │ ├── CL/kernels/ # OpenCL 内核的 C 封装层 │ └── CL/cl_kernels/ # .cl 内核源码 ├── runtime/ # 运行时实现 └── graph/ # 图实现 examples/ tests/ CMakeLists.txt注意arm_compute/下的头文件是“给别人看的”src/下的实现是“能随便折腾的”。性能库最怕什么最怕你为了优化一个算子去改内核结果把外部 API 也震碎了。ACL 用这套镜像布局从物理上把两部分隔开调用方只依赖NEArithmeticAddition::configure/run这种稳定接口至于底层内核是从 NEON intrinsics 换成手写汇编还是从 CPU 换到 GPU都是库内部的事。这一点是后面所有工程设计的基石。1.2 三套后端并存NEON、OpenCL以及新出现的 GpuACL 的命名习惯从类名就能看出来NE前缀是 CPU NEON 后端CL前缀是 OpenCL 后端GC前缀是 OpenGL ES 后端老版本里有后来逐渐边缘化。从 v22 开始NEON 这一侧被重构为Cpu后端类名变成CpuAdd、CpuConv2dOpenCL 侧也出现了实验性的Gpu后端。但无论名字怎么改核心逻辑没变每个算子都有一对配置和运行方法configure()负责根据 tensor 的 shape、data type、backend 特性把 kernel 和 Window 准备好run()只做一件事——把 kernel 丢给 Scheduler 去执行。为什么会拆成多个后端因为“高性能”在不同的硬件上含义完全不同。Cortex-A76 的大核喜欢向量宽度 128 位的 NEON 指令Mali GPU 又希望数据按 NHWC 排布好让纹理单元加速Adreno 更吃 OpenCL 的 work-group 调度。你让 CPU 和 GPU 共用一套 kernel结果必然是两边都跑不快。ACL 的解法简单粗暴同一层语义每个硬件各写一套实现。代价是源码体积大收益是每块硬件都能榨出接近峰值的性能。1.3 configure 重、run 轻接口设计里的性能哲学如果你翻过 ACL 任何一个算子的头文件会发现方法永远就那么几个configure、run、validate。configure里面做的全是重活——检查 shape 是否匹配、计算需要的 padding、推导 kernel 的 Window、给 OpenCL kernel 准备 build options。run则轻得惊人经常只是调一下scheduler-schedule(kernel, window)。这个“重配置、轻执行”的设计有很现实的原因在端侧同一个算子往往要对着同一组 shape 反复跑成千上万次。假设你每一帧都要做一次 224x224 的卷积如果把 shape 检查、窗口计算、甚至 OpenCL program 编译都塞进run()那 90% 的性能都浪费在“准备”而不是“计算”上。ACL 把准备工作全部前移到configure()run()只管执行这就是它能在手机上持续跑满帧率的原因之一。2. CMake 构建系统的关键选择多后端开关、交叉编译与工具链坑2.1 顶层开关一个库如何编译出多种形态ACL 的 CMake 设计和开源界很多库不太一样它的核心思路是“把后端做成编译期开关”。同样是这套源码你可以编译出一个只有 CPU NEON 内核的精简库也可以编译出 CPUGPU 全功能的完整库取决于你给 CMake 传什么参数。git clone https://github.com/ARM-software/ComputeLibrary.git cd ComputeLibrary cmake -S . -B build \ -DARM_COMPUTE_NEON1 \ -DARM_COMPUTE_OPENCL1 \ -DARM_COMPUTE_CPPTHREAD1 \ -DARM_COMPUTE_GRAPH1 \ -DBUILD_TESTING0 cmake --build build -j8我见过不少人直接cmake .. make然后发现编出来的库没有 OpenCL 功能或者编了半天把测试也编了进来。关键开关就几个我用表格整理一下CMake 开关作用我的建议ARM_COMPUTE_NEON编译 CPU NEON/ASIMD 内核纯 CPU 场景也必须开ARM_COMPUTE_OPENCL编译 OpenCL 后端有 GPU 需求才开会引入 OpenCL 头文件和库依赖ARM_COMPUTE_CPPTHREAD用 C 线程池做 CPU 调度通常开着不然单线程跑ARM_COMPUTE_GRAPH编译 Graph API不搞图加速就关掉能缩一点体积BUILD_TESTING编译单元测试平时关提 PR 之前开这些开关在执行的时候会被转成预处理宏源码里到处是#ifdef。所以你打开src/cpu/CpuAdd.cpp这类文件能看到不同后端代码被条件编译包裹这就是“一套工程多种产物”的底层机制。理解这一点后你自己写算子库时也可以把-DWITH_CUDA1、-DWITH_CORE0这种开关设计成标准动作而不是每改一次后端需求就改一次源码。2.2 交叉编译给 aarch64 目标准备 toolchainACL 绝大多数使用场景是“在 x86 开发机上编译部署到 aarch64 设备上跑”。跨平台编译这件事CMake 的标准做法是提供一个 toolchain 文件把目标系统、编译器、架构全部锁死。ACL 仓库里也带了工具链示例但就算没有现成的自己写也很快set(CMAKE_SYSTEM_NAME Linux) set(CMAKE_SYSTEM_PROCESSOR aarch64) set(CMAKE_C_COMPILER aarch64-linux-gnu-gcc) set(CMAKE_CXX_COMPILER aarch64-linux-gnu-g) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)然后构建命令变成cmake -S . -B build \ -DCMAKE_TOOLCHAIN_FILE./toolchain-aarch64.cmake \ -DARM_COMPUTE_NEON1 \ -DBUILD_TESTING0 cmake --build build -j8这里有一个新手必踩的坑交叉编译时 CMake 会去找目标平台的系统库。如果你的程序只依赖 C 标准库那编译器自带的 sysroot 就够了但如果算子内部要链接 OpenCL lib你必须用-DCMAKE_FIND_ROOT_PATH指向目标设备的 rootfs否则 CMake 会莫名找到开发机 x86 的 libOpenCL.so链接阶段报一堆架构不匹配。ACL 的 OpenCL 交叉编译基本都要配 rootfs我建议一开始就把这个变量写进 toolchain 文件别等报错再补。2.3 三个高频翻车现场CMake 版本、CUDA 误检和 Windows 历史包袱读源码也好自己编译也好我在实际环境里遇到过三个特别有代表性的 CMake 报错基本都能在网上热搜里看到它们的影子。第一个是版本问题。较新版本的 ACL 要求 CMake 至少 3.26而很多老服务器上的系统自带 CMake 还停留在 2.8.12.2一跑就报“CMake 3.26 or higher is required. You are running version 2.8.12.2”。这不是 ACL 独有的问题任何现代 C 项目都会遇到。我的处理方式很简单不要用系统源里的 CMake直接pip install cmakepip 会装一个独立的最新版二进制也不影响系统包管理。老系统上这招最省心。第二个是 CUDA 误检。交叉编译时偶尔会出现CMake Error: CMAKE_CUDA_COMPILER not set, after EnableLanguage。遇到这种报错先别慌十有八九是某个子目录或第三方依赖调用了enable_language(CUDA)而你的机器上根本没有 nvcc。解决思路是顺藤摸瓜检查 CMakeCache 里谁拉起了 CUDA 检查把对应模块关掉或者干脆在 toolchain 文件里显式告诉 CMake 不要找 CUDA。ACL 本身和 CUDA 没关系这个报错纯粹是 CMake 全局语言检测被污染的典型案例。第三个是 Windows 上的老版本困境。热词里总能看到“cmake win7 32位下载安装”我劝你直接放弃这种组合。ACL 的 NEON 后端必须在 ARM 交叉工具链下编译Windows 上用 32 位 CMake 环境管理 OpenCL 工程纯属给自己找事。我现在的习惯是在 Linux 容器里做所有交叉编译Windows 只保留一个 CMake Ninja 的环境用来验证 OpenCL 主机端逻辑。3. NEON 内核源码怎么读Window 迭代、wrapper 封装与汇编内核的取舍3.1 一条 NEON 算子的完整调用链读 ACL 的 CPU 内核最忌讳从复杂算子比如 GEMM、Dconv开始。我建议从最简单的张量相加Arithmetic Addition新版里叫 Elementwise Add入手它的调用链干净利落调用方创建NETensor调用NEArithmeticAddition::configure(src0, src1, dst, ConvertPolicy::SATURATE)configure()内部会实例化一个 kernel老版本叫NEArithmeticAdditionKernel新版本叫CpuAddKernel并调用kernel-configure()kernel 的configure()里根据输入 shape 计算Window也就是每个维度迭代的区间run()时算子把 kernel 和 window 交给CPPScheduler调度器按线程数把 window 切成多个子窗分给各线程并行执行。这个流程最值得琢磨的是Window。它不是一个简单的 for 循环边界而是一个多维迭代区间每个维度有start、end、step。CPU 调度器可以沿着某个维度把大窗口切成 N 段扔到 N 个线程上每个线程再按向量化步长在窗口里滑。这样做的好处是第一多维张量的遍历逻辑集中在一个地方不会到处写for (int y...) { for (int x...) }第二线程切分不用改内核代码调度器通过 Splitting 机制就实现了多线程第三Iterator类在窗口滑动时自动处理 tensor 的 padding 偏移边界计算全被封装掉了。我用伪代码还原一下内核的主循环逻辑实际代码会复杂一些但骨架就是这样// 伪代码逻辑上等价于 ACL 内核里的主循环 Window win kernel-window(); // 从 configure() 里得到的迭代窗口 Iterator it_src(src_tensor, win); // 迭代器负责在多维窗口里滑动 Iterator it_dst(dst_tensor, win); execute_window_loop(win, [](const Coordinates id) { // id 是当前迭代的坐标这里就可以安全地取指针了 const float *src0_ptr reinterpret_castconst float *(it_src.ptr()); const float *src1_ptr reinterpret_castconst float *(it_src1.ptr()); float *dst_ptr reinterpret_castfloat *(it_dst.ptr()); // 向量化核心计算后面会讲 float32x4_t a vld1q_f32(src0_ptr); float32x4_t b vld1q_f32(src1_ptr); vst1q_f32(dst_ptr, vaddq_f32(a, b)); });很多人第一次看 ACL 源码会被Window、Iterator、execute_window_loop这一堆概念劝退。你把它们想象成“在矩阵上按块滑动的滑尺”就简单了Window是滑尺的范围Iterator是滑尺当前的位置execute_window_loop负责每次滑到新位置时通知你的 lambda。这套抽象让内核代码基本不关心自己跑在哪个线程、处理哪块数据只关心“给一块数据怎么算最快”。3.2 wrapper 层为什么要给 NEON intrinsics 再套一层如果你去src/core/NEON/kernels/里翻.cpp会看到大量wrapper::vadd、wrapper::vmla、wrapper::vdup这类调用而不是直接用vaddq_f32。这个wrapper目录在arm_compute/core/NEON/wrapper/下是 ACL 对 ARM NEON intrinsics 的一层薄封装。这份封装解决了一个很实际的问题NEON intrinsics 的函数名是跟着数据类型走的。vaddq_f32是 float32 加法vaddq_u8是 uint8 加法写法完全不同。而 ACL 的算子要支持 U8、S8、U16、S16、F16、F32 一堆格式如果每个数据类型都写一遍内核代码量会爆炸。wrapper 层把“数据格式差异”藏到一层函数后面内核主体只用一套模板逻辑编译器再根据模板参数展开成对应的 intrinsics。举个例子如果你自己写算子可以直接这么用 NEONfloat32x4_t a vld1q_f32(src0); float32x4_t b vld1q_f32(src1); float32x4_t r vaddq_f32(a, b); vst1q_f32(dst, r);这段代码一次算 4 个 float已经比标量循环快 4 倍了。但 ACL 要处理的是“数据可能是 float32也可能是 uint8还可能是 int16”的情况所以它会把vadd封装成wrapper::vadd(ptr_a, ptr_b)模板参数一推导编译器自动选对应的 intrinsics。这个设计告诉我一个经验不要在你的业务代码里到处裸写 intrinsics先花一点时间定义一层薄薄的 SIMD wrapper后面加数据格式、换汇编实现都会轻松很多。3.3 手写汇编、intrinsics 和 C 回退性能库的“三级火箭”ACL 更狠的地方在于真正吃性能的算子根本不满足于 intrinsics。以 GEMM 为例src/core/NEON/kernels/assembly/下躺着大量手写汇编——有的直接是.S文件有的用内联汇编写在.cpp里。这些汇编是给特定微架构调的比如 Cortex-A55 和 Cortex-A76 的流水线行为不一样同样的 4x4 内核块在 A76 上能双发射在 A55 上可能就卡在乘加单元上。intrinsics 虽说也能向量化但寄存器分配、指令调度这些细活编译器不一定干得漂亮手写汇编才能精确控制每一条乘法、每一次 load 的发射时机。你可能会问手写汇编虽然快但可移植性怎么保证这就是 ACL 运行期选择机制存在的意义。现代版本里CPU 内核在运行时会通过CpuInfo、CPUModel读取当前 CPU 的特性架构版本、是否支持 SVE、是哪一颗核心然后由一个 KernelSelector 来决定这个算子在这颗 CPU 上是走手写汇编、走 NEON intrinsics还是走普通 C 回退。这其实是一套完整的“三级火箭”策略——汇编追求上限intrinsics 保证跨平台C 回退兜底。你自己写算子里完全可以把这套策略简化后复用先写一个正确性优先的 C 版本再补 intrinsics 版本最后针对销量最大的那几颗 CPU 手调汇编。顺带说一下 SVE。热词里总能看到 “simd neon sve” 一起出现很多人搞不清它们的关系。NEON 是 ARMv7/AArch64 上固定 128 位宽的 SIMD 扩展SVE 是 ARMv8.2 之后出现的可变向量长度扩展可以跑 128/256/512 位。ACL 的很多内核已经补了 SVE 路径理想状态下同一套代码能自动适配 CPU 支持的向量长度。但 SVE 的实际收益受编译器影响很大GCC 对 SVE 自动向量化的水平这几年才逐渐成熟所以 ACL 里 SVE 内核的数量远不如 NEON性能敏感的大头GEMM才单独写了 SVE 版本。读这类代码时建议先把 NEON 路径读透再去看 SVE 差异。4. OpenCL 后端.cl 内核如何编译、调度以及为什么它不能离线预编译4.1 .cl 文件是怎么“塞进”二进制的OpenCL 后端和 NEON 后端有个非常不一样的点OpenCL 内核不是 C 写的而是 OpenCL C 方言写的源文件以.cl结尾放在src/core/CL/cl_kernels/下。你翻这个目录会看到gemm.cl、pooling_layer.cl、elementwise_operation.cl这些文件里面就是一行行跑在 GPU 上的代码。问题来了设备上运行时这些.cl文件从哪来Android 的应用沙箱里没有这一层文件系统所以 ACL 的 CMake 做了一件事——在构建阶段用 Python 脚本把所有.cl文件读进来生成一个包含字符串常量的 C 头文件。大致逻辑等价于# 伪代码把 .cl 内核转成 C 字符串 for name in cl_kernel_files: text open(f{name}.cl).read() print(fconst char *{name}_source R({text});)这样每个 OpenCL kernel 的源码就变成了二进制里的一个字符串运行时直接clCreateProgramWithSource就能拿到完整代码。这个设计的好处是部署时不用管内核源文件坏处是每次改动.cl文件都要重新编译整个库而且二进制体积会明显变大。对端侧部署来说这个取舍相当划算——少一套资源文件就少一堆路径问题的坑。4.2 在线编译为什么 OpenCL 程序必须在设备上现场构建OpenCL 的执行流程和 CUDA 有个很大区别CUDA 可以提前把 kernel 编译成 PTX 或 cubinOpenCL 虽然也有二进制缓存机制但绝大多数场景下你拿到手的只是一个.cl源码必须调用clBuildProgram让设备驱动现场编译。ACL 的CLScheduler和CLKernelLibrary就是干这个的CLScheduler是单例持有cl::Context、cl::Device、cl::CommandQueueCLKernelLibrary负责把 kernel 源码和 build options 组合起来生成cl::Program。判定一个算子走 OpenCL 时执行流程大概是cl::Program program(context, kernel_text); program.build(build_options); // 在线编译 cl::Kernel kernel(program, elementwise_add);// 取 kernel 句柄 queue.enqueueNDRangeKernel(kernel, offset, global, local);你有没有想过为什么 ACL 不给每个 GPU 提前编译好二进制原因很简单OpenCL 二进制和 GPU 驱动、硬件 IP 强绑定。同一个.cl在 Mali-G78 和 Adreno 660 上编译出来的二进制完全不能互换甚至同一颗 GPU 在不同驱动版本下的二进制格式都可能变。Android 设备碎片化严重离线编译的产物没法覆盖那么多组合相比之下在线编译虽然每次启动要多花几十到几百毫秒但它天然兼容所有设备。这就是工程上的“以时间换兼容性”。既然在线编译绕不开性能优化就要从这个点入手。ACL 新版本提供了 program cache 接口允许你把编译好的cl_program二进制缓存到本地文件下次启动直接加载能省掉一大部分冷启动时间。我做端侧推理的时候会在进程退出前把 program cache 落盘下次启动检查缓存是否有效实测在部分 Mali 设备上能把首个推理帧的延迟缩短一半以上。4.3 NEON 还是 OpenCL同一个算子为什么有两条路ACL 里很多算子同时提供 NEON 和 OpenCL 两种实现这既是卖点也是对使用者判断力的考验。Graph API 在构建时会根据你指定的 TargetTarget::NEON、Target::CL来决定算子走哪条路但如果你直接调函数就得自己选了。我总结了几条很实用的选择经验判断维度倾向 NEON倾向 OpenCL张量尺寸小尺寸比如 1x1、少量 channel大尺寸、重计算卷积、GEMM内存布局NCHW 且不想折腾NHWC 且 GPU 是 Mali/Adreno算子类型逐元素、concatenate 等访存密集型convolution、gemm 等计算密集型调度开销延迟敏感、kernel 启动会吞掉收益算力足够大掩盖启动开销执行环境也很关键。同一颗 Mali GPU在 Linux 上 OpenCL 驱动比 Android 上更容易出幺蛾子程序员经常被clEnqueueNDRangeKernel的莫名错误搞到头大。我的习惯是先写 NEON 版本保证正确性和一个性能基线再写 OpenCL 版本做对比OpenCL 没有明显优势的算子就直接放弃 GPU 路径。你要明白高性能库不是“所有算子都要用 GPU”而是“每个算子都用当前硬件上最快的那条路”。5. 从 ACL 抄作业我写小型高性能算子库时复用的四条工程经验5.1 用镜像目录把公共 API 和实现细节彻底隔离ACL 的arm_compute/与src/镜像布局是我见过最直观的接口隔离实践。它带来的直接好处是重构内核时我可以大改src/底下的实现而不伤到调用方增加新后端时我只需要在新目录里实现同一个接口然后让工厂函数返回新对象。我自己写算子库时也照搬了这套结构——include/放对外头文件src/放实现并强制规定头文件里不能出现任何与具体后端相关的类型只暴露抽象基类和工厂方法。坚持这个约定半年后团队里新增算子、新增后端的效率明显比之前高。5.2 编译期开关决定“编译进去什么”运行期选择决定“实际用哪个”这是 ACL 最值得借鉴的架构思想它可以拆成两层编译期CMake 开关决定一个后端是否编译进库。比如ARM_COMPUTE_NEON0CPU 内核的.cpp根本不会被编译器看到产物体积直接瘦身。运行期CpuInfo、CPUModel读取当前硬件能力KernelSelector 决定某一个算子具体走哪个实现甚至到“哪一套汇编块”。这两个层面分开的好处是编译期的决策服务于分发包体积和依赖管理运行期的决策服务于真机性能。你把它们混在一起——比如在代码里根据某个宏去查 CPU 型号——就会导致“编出来的库没包含某个实现运行期无论如何也选不上”的尴尬局面。正确姿势永远是编译期保证功能存在运行期保证选择正确并且一定留一个 C 回退路径兜底。5.3 性能库必须建三层测试正确性、数值验证、基准回归ACL 的tests/目录分得很细单元测试测 kernel 逻辑validation 测试对照参考实现检查数值误差benchmark 和 examples 用来测性能。这个分层不是形式主义它恰好好对应性能库开发的三个问题——功能对不对、精度差多少、快不快。我在实际项目中吃过教训有一版把某个算子的 NEON 内核优化到比原来快 30%但 validation 没过因为浮点累加顺序变了误差超出算子允许的阈值。如果没有 validation 这一层这个 bug 会一直潜伏到上线。另一个教训是基准测试一定要在真机上跑别用qemu-user。qemu 模拟 aarch64 的时候NEON 指令是软件翻译执行的性能和真机能差出一个数量级用它判断算法趋势可以用它调汇编参数完全没意义。ACL 的例子能跑在 x86 的 qemu 上但它是拿来验证逻辑正确性的不是拿来测速的。5.4 把工具链版本装进“保险箱”固定 CMake、编译器和架构标志最后一条经验是从第 2 节的踩坑里总结出来的。ACL 这类底层库对工具链极其敏感编译器版本换一个数可能某个算子的内联汇编就不匹配了性能掉 20% 甚至编译失败。所以无论是给公司做集成还是自己维护算子仓库都要把工具链版本写死CMake 用哪个版本、GCC 用哪个版本、是否带 SVE flag、toolchain 文件长什么样全部提交到仓库里并通过 CI 矩阵同时验证多个编译器版本。我特别建议你在构建脚本里显式设置export CC/opt/gcc-11.2/bin/aarch64-none-linux-gnu-gcc export CXX/opt/gcc-11.2/bin/aarch64-none-linux-gnu-g cmake -S . -B build \ -DCMAKE_BUILD_TYPERelease \ -DCMAKE_TOOLCHAIN_FILE./toolchain-aarch64.cmake \ -DCMAKE_C_FLAGS-marcharmv8.2-asimd \ -DCMAKE_CXX_FLAGS-marcharmv8.2-asimd不要依赖环境的默认编译器不然换一台机器整个库的性能画像就变了。这个习惯帮我在不同项目里少踩了无数次“本地编译好好的、CI 上突然全挂”的坑。最后分享一个我后来一直沿用的读码习惯拿到 ACL 这类大型高性能库别从最复杂的 GEMM 开刀。先挑一个像 elementwise add 这样的小算子从头文件看到src实现再自己写一个最小例子编译一遍最后用perf或者armv8的计数器观测它的实际表现。把一条最小的链路彻底走通比翻一百个 kernel 目录都有用。等你把这个闭环建立起来再看 GEMM 的汇编块、OpenCL 的 kernel 调度就会觉得一切都是水到渠成的。