【免费下载链接】cpu-performance-engineeringA reading path for CPU performance engineering, from one instruction to production inference. Primary sources only, with a runnable benchmark for every section.项目地址https://gitcode.com/gh_mirrors/cp/cpu-performance-engineering点击查看免费下载CPU performance engineeringCPU 性能工程不只是把代码写快更是用可复现的测量证明提速从哪来。本文基于开源项目 cpu-performance-engineering 中可运行的基准测试在 Apple M4 Pro 的性能核上实测 CPU 推理的核心负载 SGEMM单精度矩阵乘法从朴素三重循环的 2.54 GFLOP/s到编译器自动向量化再到手写 NEON 寄存器分块微内核的 111.77 GFLOP/s一路加速约44 倍微内核最终摸到实测 NEON FMA 峰值的86.6%。为什么 CPU 推理绕不开 SGEMM神经网络在 CPU 上的推理瓶颈几乎都落在矩阵乘法上前向计算全连接层、卷积展开后都是 GEMMGeneral Matrix MultiplyDecode 阶段batch1 的自回归生成每个 token 都要把所有权重从内存读一遍做几次浮点运算跑在内存带宽的天花板上量化、矩阵扩展、线程调度llama.cpp、oneDNN、OpenVINO 这些 CPU 推理运行时的优化最终都汇聚到 GEMM 微内核的质量。所以 cpu-performance-engineering 项目专门用一节 Inference on CPU 讲 CPU 推理并配了第 13 个基准SGEMM 朴素循环 vs 微内核 vs 厂商 BLAS这正是本文的实测对象。实验设计1024³ 矩阵乘法四份代码同场竞技测试源码在 bench.c计算 C A × BM N K 1024float32每次调用 21.5 亿 flops。同一颗 P-core、单线程对比四个版本版本特点naive i-j-k 三重循环内层是依赖同一个累加器的串行fmadd链B 矩阵还要按列跳着读i-k-j 自动向量化交换循环顺序后clang 在-O2下自动把内层向量化8×8 NEON 寄存器分块微内核手写Goto 式分块 数据打包packing16 个 128-bit 累加寄存器整个 k 循环不碰内存Accelerate cblas_sgemm厂商 BLAS分别测 1 线程和默认线程数微内核的关键在于寄存器分块每个 k 步只做 4 次 load却支撑 16 条fmla融合乘加而自动向量化版本平均每条fmla要拖 2 次 load 1 次 store。项目同时实测了两个天花板作为参照单条依赖fmadd的延迟0.690 ns以及 16 条独立寄存器链的NEON FMA 峰值129.12 GFLOP/s——任何 NEON 代码都不可能超过它。 测量方法CLOCK_MONOTONIC_RAW计时1 次预热丢弃每版本 11 次计时取中位数并报告变异系数cv 1.4%所有结果逐元素比对参考值防止被编译器优化掉。完整方法见 results/raw.txt。实测结果44 倍提速是怎么逐级拿到的完整数据见 results/summary.md版本中位 GFLOP/s相对朴素版naive i-j-k 三重循环2.541.0×i-k-j 自动向量化32.9412.9×8×8 NEON 寄存器分块微内核111.7743.9×Accelerate BLAS1 线程1588.13624×Accelerate BLAS默认线程3180.081249.5×朴素循环只有 2.54 GFLOP/s被 FMA 依赖链锁死朴素版的内层循环里每个fmadd都要等前一个的结果而实测单条fmadd延迟约 0.690 ns约 3.1 个周期。理论上界的理论上限是每个延迟 2 个 flops≈ 2.90 GFLOP/s——朴素循环拿到了其中的 87.8%说明它已经卡死在自身累加器的延迟上跳步读 B 只占掉了剩下的一点空间。优化方向因此很明确打断依赖链。自动向量化与寄存器分块12.9× 和 3.4× 的分别来源循环重排i-k-j内层变成对连续内存的 saxpy编译器顺利向量化拿到 12.9×——但每条fmla仍背着 2 次 load、1 次 store只摸到 NEON FMA 峰值的 25.5%瓶颈转移到了 load/store 端口手写 8×8 微内核分块 打包让 16 条fmla只摊 4 次 load累加器常驻寄存器。结果43.9×达到实测 FMA 峰值的86.6%、理论32 flops/cycle上限的 77.6%。剩下的 ~13% 是打包开销、循环开销和缺少预取——生产级内核如 BLIS、KleidiAI还会再抠几个百分点。 这就是微内核的全部价值朴素版 → 手写微内核44 倍加速且几乎打满向量单元的天花板。在 x86 上如 AVX-512 的 FMA 端口微内核与厂商 BLAS 通常只差几十个百分点微内核 ≈ 整个差距的说法在那里成立。厂商 BLAS 为何仍快 14.2 倍SME 矩阵单元单线程的 Accelerate BLAS 跑出 1588.13 GFLOP/s是微内核的 14.2 倍、实测 NEON 峰值的 12.3 倍——任何 NEON 代码都到不了这里。原因是 Accelerate 把 SGEMM 派发到独立的SME 矩阵单元一个编译器从普通 C 代码里不会生成的执行单元。默认线程下再翻倍到 3180.08 GFLOP/sCPU/wall 时间比 1.97约用了 2 个核。int8 点积实测CPU 推理量化的 4× 免费午餐同一套代码还测了 1677 万元素的流式点积int8 用 NEONsdot每条指令 16 个乘加float32 用fmla4 个内核数据ops/ns相对 f32 fmlaint8 sdot流式超 L2118.63.97×f32 fmla流式29.91.00×int8 sdotL1 驻留191.04.02×f32 fmlaL1 驻留47.51.00×两组速度都在同一带宽水平上流式时两者字节/纳秒几乎相等118.6 vs 119.5说明 int8 的 4× 来自每个字节多带 4 倍乘加L1 驻留时两者都被 load 端口限制约 1.33 条/周期int8 依然稳定 4×。这就是 int8 量化在 CPU 推理里还没用上查表或矩阵扩展之前就能白拿的收益对应 13. Inference on CPU — Quantization 一节的一手文献。复现指南两条命令跑完全部基准项目里每个章节都配了一个可运行的基准benchmarks 总览每个数字都带齐 7 个字段CPU 型号、核数、频率由 clock_estimate.c 用依赖加法链估算、编译器与参数、负载、基线、统计方法。git clone https://gitcode.com/gh_mirrors/cp/cpu-performance-engineering cd cpu-performance-engineering cd misc/benchmarks/13-sgemm-naive-vs-blas ./run.sh # 完整跑约 15 秒 QUICK1 ./run.sh # 冒烟测试约 2 秒源码为 C11 pthreadsNEON/Accelerate 都在#if守卫内Linux x86-64 上可用 OpenBLAS 作为 BLASUSE_OPENBLAS1。所有基准也可用 run_all.sh 一键串行跑完。结论44 倍加速给出的 3 个启示先打断依赖链再谈向量朴素 GEMM 只拿到延迟链上限的 87.8%说明它已经最快了真正的空间在寄存器分块。微内核摸到 FMA 峰值的 86.6% 就到头了向量单元有硬天花板再往上要换执行单元矩阵扩展或换精度int8 白拿 4×。没有 7 个字段的数字不引用这个项目坚持任何性能数字必须带齐 CPU、频率、编译器、方法等全部字段缺一项就进 watchlist——这正是 CPU 性能工程区别于跑个分截图的地方。从一条指令到生产级 CPU 推理完整的阅读路径见项目 README其中 03-延迟与吞吐、06-roofline 等基准与本文互为表里。赞分享【免费下载链接】cpu-performance-engineeringA reading path for CPU performance engineering, from one instruction to production inference. Primary sources only, with a runnable benchmark for every section.项目地址https://gitcode.com/gh_mirrors/cp/cpu-performance-engineering点击查看免费下载相关推荐从1.58-bit到TL2内核BitNet如何让LLM在CPU端实现5倍速推理从1.58 bit到TL2内核BitNet如何让LLM在CPU端实现5倍速推理 你是否还在为大模型本地部署时的龟速响应烦恼BitNet框架带来了革命性突人工智能大模型推理引擎本地部署模型量化模型优化ml-engineering 算力实战加速器选型、TFLOPS 实测与 CPU/内存资源规划指南ml engineering 算力实战加速器选型、TFLOPS 实测与 CPU/内存资源规划指南 本文以 ml engineeringMachine Lea人工智能大模型AI 技能/插件分布式训练微调深度学习LMCache CPU Offloading 实战指南将 KV Cache 卸载到 CPU 内存加速长上下文推理LMCache CPU Offloading 实战指南将 KV Cache 卸载到 CPU 内存加速长上下文推理 LMCache 将 KV cache 视为人工智能大模型缓存抽象模型推理服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/15 16:39:22 · 阅读 1.2k CPU Performance Engineering 实测：手写 NEON 微内核逼近 FMA 峰值，CPU 推理 44 倍加速之路
【免费下载链接】cpu-performance-engineeringA reading path for CPU performance engineering, from one instruction to production inference. Primary sources only, with a runnable benchmark for every section.项目地址https://gitcode.com/gh_mirrors/cp/cpu-performance-engineering点击查看免费下载CPU performance engineeringCPU 性能工程不只是把代码写快更是用可复现的测量证明提速从哪来。本文基于开源项目 cpu-performance-engineering 中可运行的基准测试在 Apple M4 Pro 的性能核上实测 CPU 推理的核心负载 SGEMM单精度矩阵乘法从朴素三重循环的 2.54 GFLOP/s到编译器自动向量化再到手写 NEON 寄存器分块微内核的 111.77 GFLOP/s一路加速约44 倍微内核最终摸到实测 NEON FMA 峰值的86.6%。为什么 CPU 推理绕不开 SGEMM神经网络在 CPU 上的推理瓶颈几乎都落在矩阵乘法上前向计算全连接层、卷积展开后都是 GEMMGeneral Matrix MultiplyDecode 阶段batch1 的自回归生成每个 token 都要把所有权重从内存读一遍做几次浮点运算跑在内存带宽的天花板上量化、矩阵扩展、线程调度llama.cpp、oneDNN、OpenVINO 这些 CPU 推理运行时的优化最终都汇聚到 GEMM 微内核的质量。所以 cpu-performance-engineering 项目专门用一节 Inference on CPU 讲 CPU 推理并配了第 13 个基准SGEMM 朴素循环 vs 微内核 vs 厂商 BLAS这正是本文的实测对象。实验设计1024³ 矩阵乘法四份代码同场竞技测试源码在 bench.c计算 C A × BM N K 1024float32每次调用 21.5 亿 flops。同一颗 P-core、单线程对比四个版本版本特点naive i-j-k 三重循环内层是依赖同一个累加器的串行fmadd链B 矩阵还要按列跳着读i-k-j 自动向量化交换循环顺序后clang 在-O2下自动把内层向量化8×8 NEON 寄存器分块微内核手写Goto 式分块 数据打包packing16 个 128-bit 累加寄存器整个 k 循环不碰内存Accelerate cblas_sgemm厂商 BLAS分别测 1 线程和默认线程数微内核的关键在于寄存器分块每个 k 步只做 4 次 load却支撑 16 条fmla融合乘加而自动向量化版本平均每条fmla要拖 2 次 load 1 次 store。项目同时实测了两个天花板作为参照单条依赖fmadd的延迟0.690 ns以及 16 条独立寄存器链的NEON FMA 峰值129.12 GFLOP/s——任何 NEON 代码都不可能超过它。 测量方法CLOCK_MONOTONIC_RAW计时1 次预热丢弃每版本 11 次计时取中位数并报告变异系数cv 1.4%所有结果逐元素比对参考值防止被编译器优化掉。完整方法见 results/raw.txt。实测结果44 倍提速是怎么逐级拿到的完整数据见 results/summary.md版本中位 GFLOP/s相对朴素版naive i-j-k 三重循环2.541.0×i-k-j 自动向量化32.9412.9×8×8 NEON 寄存器分块微内核111.7743.9×Accelerate BLAS1 线程1588.13624×Accelerate BLAS默认线程3180.081249.5×朴素循环只有 2.54 GFLOP/s被 FMA 依赖链锁死朴素版的内层循环里每个fmadd都要等前一个的结果而实测单条fmadd延迟约 0.690 ns约 3.1 个周期。理论上界的理论上限是每个延迟 2 个 flops≈ 2.90 GFLOP/s——朴素循环拿到了其中的 87.8%说明它已经卡死在自身累加器的延迟上跳步读 B 只占掉了剩下的一点空间。优化方向因此很明确打断依赖链。自动向量化与寄存器分块12.9× 和 3.4× 的分别来源循环重排i-k-j内层变成对连续内存的 saxpy编译器顺利向量化拿到 12.9×——但每条fmla仍背着 2 次 load、1 次 store只摸到 NEON FMA 峰值的 25.5%瓶颈转移到了 load/store 端口手写 8×8 微内核分块 打包让 16 条fmla只摊 4 次 load累加器常驻寄存器。结果43.9×达到实测 FMA 峰值的86.6%、理论32 flops/cycle上限的 77.6%。剩下的 ~13% 是打包开销、循环开销和缺少预取——生产级内核如 BLIS、KleidiAI还会再抠几个百分点。 这就是微内核的全部价值朴素版 → 手写微内核44 倍加速且几乎打满向量单元的天花板。在 x86 上如 AVX-512 的 FMA 端口微内核与厂商 BLAS 通常只差几十个百分点微内核 ≈ 整个差距的说法在那里成立。厂商 BLAS 为何仍快 14.2 倍SME 矩阵单元单线程的 Accelerate BLAS 跑出 1588.13 GFLOP/s是微内核的 14.2 倍、实测 NEON 峰值的 12.3 倍——任何 NEON 代码都到不了这里。原因是 Accelerate 把 SGEMM 派发到独立的SME 矩阵单元一个编译器从普通 C 代码里不会生成的执行单元。默认线程下再翻倍到 3180.08 GFLOP/sCPU/wall 时间比 1.97约用了 2 个核。int8 点积实测CPU 推理量化的 4× 免费午餐同一套代码还测了 1677 万元素的流式点积int8 用 NEONsdot每条指令 16 个乘加float32 用fmla4 个内核数据ops/ns相对 f32 fmlaint8 sdot流式超 L2118.63.97×f32 fmla流式29.91.00×int8 sdotL1 驻留191.04.02×f32 fmlaL1 驻留47.51.00×两组速度都在同一带宽水平上流式时两者字节/纳秒几乎相等118.6 vs 119.5说明 int8 的 4× 来自每个字节多带 4 倍乘加L1 驻留时两者都被 load 端口限制约 1.33 条/周期int8 依然稳定 4×。这就是 int8 量化在 CPU 推理里还没用上查表或矩阵扩展之前就能白拿的收益对应 13. Inference on CPU — Quantization 一节的一手文献。复现指南两条命令跑完全部基准项目里每个章节都配了一个可运行的基准benchmarks 总览每个数字都带齐 7 个字段CPU 型号、核数、频率由 clock_estimate.c 用依赖加法链估算、编译器与参数、负载、基线、统计方法。git clone https://gitcode.com/gh_mirrors/cp/cpu-performance-engineering cd cpu-performance-engineering cd misc/benchmarks/13-sgemm-naive-vs-blas ./run.sh # 完整跑约 15 秒 QUICK1 ./run.sh # 冒烟测试约 2 秒源码为 C11 pthreadsNEON/Accelerate 都在#if守卫内Linux x86-64 上可用 OpenBLAS 作为 BLASUSE_OPENBLAS1。所有基准也可用 run_all.sh 一键串行跑完。结论44 倍加速给出的 3 个启示先打断依赖链再谈向量朴素 GEMM 只拿到延迟链上限的 87.8%说明它已经最快了真正的空间在寄存器分块。微内核摸到 FMA 峰值的 86.6% 就到头了向量单元有硬天花板再往上要换执行单元矩阵扩展或换精度int8 白拿 4×。没有 7 个字段的数字不引用这个项目坚持任何性能数字必须带齐 CPU、频率、编译器、方法等全部字段缺一项就进 watchlist——这正是 CPU 性能工程区别于跑个分截图的地方。从一条指令到生产级 CPU 推理完整的阅读路径见项目 README其中 03-延迟与吞吐、06-roofline 等基准与本文互为表里。赞分享【免费下载链接】cpu-performance-engineeringA reading path for CPU performance engineering, from one instruction to production inference. Primary sources only, with a runnable benchmark for every section.项目地址https://gitcode.com/gh_mirrors/cp/cpu-performance-engineering点击查看免费下载相关推荐从1.58-bit到TL2内核BitNet如何让LLM在CPU端实现5倍速推理从1.58 bit到TL2内核BitNet如何让LLM在CPU端实现5倍速推理 你是否还在为大模型本地部署时的龟速响应烦恼BitNet框架带来了革命性突人工智能大模型推理引擎本地部署模型量化模型优化ml-engineering 算力实战加速器选型、TFLOPS 实测与 CPU/内存资源规划指南ml engineering 算力实战加速器选型、TFLOPS 实测与 CPU/内存资源规划指南 本文以 ml engineeringMachine Lea人工智能大模型AI 技能/插件分布式训练微调深度学习LMCache CPU Offloading 实战指南将 KV Cache 卸载到 CPU 内存加速长上下文推理LMCache CPU Offloading 实战指南将 KV Cache 卸载到 CPU 内存加速长上下文推理 LMCache 将 KV cache 视为人工智能大模型缓存抽象模型推理服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考