前言
在某无两相流体数值仿真程序从 X86 向鲲鹏处理器 + openEuler 操作系统迁移适配过程中，依托平台 devkit 微架构性能分析工具，分两轮（Task6/Task7、各 300s 采样）完成流水线瓶颈定位，程序先后经历「Core Bound 执行端口阻塞→Memory Bound 多级 Cache 缺失阻塞」两类典型瓶颈演变。本文结合两次性能剖面数据，梳理瓶颈演进逻辑、落地鲲鹏平台专属优化手段，为同类型科学计算类应用迁移提供参考思路。
一、两次测试环境与测试基线
- 硬件：鲲鹏处理器；OS：openEuler；采样工具：鲲鹏 Devkit 微架构分析；单轮采样：300s；
- 约束：两轮均使用原始 x86 迁移源码、同一套默认编译参数，未做任何代码改造、编译优化与系统调参；
- 全局指标：两轮总周期、总指令数基本持平，原生 IPC 稳定 1.11，显著低于鲲鹏处理器最优 IPC（2.0~3.0），流水线整体利用率偏低；
- 瓶颈大类共性：两次测试 Backend Bound 均为绝对瓶颈（76.30% / 76.04%），Frontend Bound、分支预测失准占比均不足 5%，取指、译码、分支逻辑无明显短板，非优化关注点。
二、第一轮采样：原生瓶颈 ——Backend 内部以 Core Bound（执行端口受限）为主
首轮性能拆解，Backend 内部阻塞以Core Bound=54.18%为首要矛盾，访存 Memory Bound (22.12%) 为辅：
- 核心阻塞来源：
0 ports non serialize占20.26%，大量周期指令就绪，但鲲鹏全量整数 / 浮点执行端口被占满、无空闲端口发射新指令；1~6 多端口并发使用率逐级递减，大部分周期仅能使用 1~2 个执行端口，处理器多发射硬件能力闲置，程序指令级并行 ILP 严重不足； - 除法、浮点除法等运算阻塞占比不足 3.5%，浮点运算时延不是端口拥堵诱因；
- 访存受限 22.12% 属于次要拖累，在端口资源紧缺的场景下，访存延迟被执行瓶颈掩盖。
成因小结：原程序基于 x86 架构编码，指令排布、数据依赖关系适配 x86 流水线，迁移鲲鹏 ARM 架构后，指令串行度高、无法充分利用鲲鹏多组异构执行端口，形成 CPU 计算受限瓶颈。
三、第二轮同环境复测：瓶颈自然切换至 Memory Bound（缓存访存受限）
源码、编译、系统环境无改动、负载不变的前提下复测，Backend 内部瓶颈重心发生迁移：原 Core Bound 压力回落，Memory Bound=21.95% 成为新的首要短板，访存瓶颈拆解：
- L1 Bound=11.15%：L1 数据 Cache 缺失是访存最大瓶颈，由 DTLB 缺页（1.62%）+L1 Cache 硬件结构资源冲突（3.82%）共同导致；
- L3 Bound=9.84%：数据无法在 L1/L2 命中，频繁穿透至共享 L3 缓存，多线程并发访问争抢 L3 资源进一步放大阻塞；
- L2、主存带宽、存储写回阻塞占比极低，无显著瓶颈。
瓶颈切换原因分析
在无人工优化前提下，系统调度、CPU 硬件动态预取、进程瞬时内存布局波动小幅缓解了执行端口瞬时拥堵，原本被 Core 瓶颈掩盖的ARM 与 x86 缓存架构、缓存行、TLB 管理差异带来的访存缺陷暴露。本质是：原生代码访存逻辑适配 x86 缓存机制，不匹配鲲鹏 L1/L3 分级缓存、CCL 架构、ARM64 页表机制，缓存命中率偏低成为新的性能天花板。
四、两轮对比总结：原生应用瓶颈演化规律
- 前端、分支预测全程无瓶颈：Frontend Bound、Bad Speculation 占比长期低于 5%，后续优化无需投入指令预取、分支改写工作；
- 瓶颈演化逻辑：未优化原生程序，优先暴露 CPU 执行端口瓶颈；执行压力轻微释放后，架构差异化带来的缓存访存瓶颈成为主要矛盾，是 x86 应用裸迁移鲲鹏非常典型的瓶颈演变特征；
- IPC 偏低根源分两阶段：第一轮由执行端口资源耗尽拉低 IPC，第二轮由多级 Cache 缺失拖慢流水线。
五、总结
借助鲲鹏 Devkit 精细化微架构采样能力，仅通过两轮重复测试即可定位裸迁移程序的动态瓶颈变化。对于 CFD、无两相仿真这类浮点密集型应用从 x86 迁移鲲鹏，原生负载普遍遵循「先 Core 端口瓶颈、后 Memory 缓存瓶颈」的暴露规律。先优化指令并行解决 Core Bound、再优化缓存适配解决 Memory Bound，是科学计算应用鲲鹏迁移的标准调优顺序。本文完成全链路瓶颈定位，后续将按照既定优化方案落地改造，并补充优化前后性能对比数据。
'%3e%3c/path%3e%3c/g%3e%3c/g%3e%3c/svg%3e)
'%3e%3c/path%3e%3c/g%3e%3c/g%3e%3c/svg%3e)
前言
在某无两相流体数值仿真程序从 X86 向鲲鹏处理器 + openEuler 操作系统迁移适配过程中，依托平台 devkit 微架构性能分析工具，分两轮（Task6/Task7、各 300s 采样）完成流水线瓶颈定位，程序先后经历「Core Bound 执行端口阻塞→Memory Bound 多级 Cache 缺失阻塞」两类典型瓶颈演变。本文结合两次性能剖面数据，梳理瓶颈演进逻辑、落地鲲鹏平台专属优化手段，为同类型科学计算类应用迁移提供参考思路。
一、两次测试环境与测试基线
二、第一轮采样：原生瓶颈 ——Backend 内部以 Core Bound（执行端口受限）为主
首轮性能拆解，Backend 内部阻塞以Core Bound=54.18%为首要矛盾，访存 Memory Bound (22.12%) 为辅：
0 ports non serialize占20.26%，大量周期指令就绪，但鲲鹏全量整数 / 浮点执行端口被占满、无空闲端口发射新指令；1~6 多端口并发使用率逐级递减，大部分周期仅能使用 1~2 个执行端口，处理器多发射硬件能力闲置，程序指令级并行 ILP 严重不足；成因小结：原程序基于 x86 架构编码，指令排布、数据依赖关系适配 x86 流水线，迁移鲲鹏 ARM 架构后，指令串行度高、无法充分利用鲲鹏多组异构执行端口，形成 CPU 计算受限瓶颈。
三、第二轮同环境复测：瓶颈自然切换至 Memory Bound（缓存访存受限）
源码、编译、系统环境无改动、负载不变的前提下复测，Backend 内部瓶颈重心发生迁移：原 Core Bound 压力回落，Memory Bound=21.95% 成为新的首要短板，访存瓶颈拆解：
瓶颈切换原因分析
在无人工优化前提下，系统调度、CPU 硬件动态预取、进程瞬时内存布局波动小幅缓解了执行端口瞬时拥堵，原本被 Core 瓶颈掩盖的ARM 与 x86 缓存架构、缓存行、TLB 管理差异带来的访存缺陷暴露。本质是：原生代码访存逻辑适配 x86 缓存机制，不匹配鲲鹏 L1/L3 分级缓存、CCL 架构、ARM64 页表机制，缓存命中率偏低成为新的性能天花板。
四、两轮对比总结：原生应用瓶颈演化规律
五、总结
借助鲲鹏 Devkit 精细化微架构采样能力，仅通过两轮重复测试即可定位裸迁移程序的动态瓶颈变化。对于 CFD、无两相仿真这类浮点密集型应用从 x86 迁移鲲鹏，原生负载普遍遵循「先 Core 端口瓶颈、后 Memory 缓存瓶颈」的暴露规律。先优化指令并行解决 Core Bound、再优化缓存适配解决 Memory Bound，是科学计算应用鲲鹏迁移的标准调优顺序。本文完成全链路瓶颈定位，后续将按照既定优化方案落地改造，并补充优化前后性能对比数据。