背景本项目基于TensorFlow v2.20+openEuler 24.03软件栈，挖掘鲲鹏处理器微架构潜力，在搜索/推荐/广告等典型稀疏模型推理场景中构建核心竞争力。 KDNN算子适配与优化在TensorFlow框架中，x86通过onednn算子库显著提升了tensorflow在推理等场景的性能，而onednn在arm场景下表现不佳。将kdnn算子库适配至onednn下后又出现了线程数爆炸等问题。本节介绍通过在tensorflow算子库中直接调用KDNN并将eigen线程池作为参数传入来约束线程数，提升arm架构上单算子性能表现。线程池直通 KDNN提供了推理核心算子基于鲲鹏处理器硬件的高性能实现，在原有的Kernels实现层使用dispatch组件将支持KDNN的算子分发到KDNN后端。KDNN线程直通是通过KDNN将计算任务提交到框架线程池的统一调度方式。复用框架线程池，减少线程创建销毁的时间损耗。原理介绍如上图所示，OMP版本的KDNN中，每个算子将创建N个OMP线程计算，M个Kernel并发则会创建M*N个OMP线程。如上图所示，使能线程直通后，会复用框架线程池。KDNN将计算任务提交到框架线程池统一调度，降低了线程创建的损耗同时避免了线程数爆炸的问题。 Matmul 算子优化现状概述 ●硬件、指令集演进差异化，无法用单一静态代码路径最优适配所有CPU。 ●不同模型问题输入存在差异，问题规模 (batch,m,n,k)、数据排布、转置类型等参数组合多，单一静态算子实现无法保证所有场景性能最优。 ●算子内部实现的数据排布影响Cache 命中率、Eltwise类算子访存瓶颈，通用算子实现难以兼顾，易造成带宽浪费。优化策略 KDNN矩阵乘法使用高性能的JIT内核。JIT机制允许开发者在程序运行时动态地生成并执行机器码。核心组件包含：代码生成器、代码缓冲区、标签管理器、操作码编码器。相比通用静态 kernel 实现，JIT机制有以下优势。 ●可利用运行时信息如：形状（batch, m, k, n）、数据布局等信息，为特定参数生成专用代码。 ●支持后操作融合，消除中间结果的内存读写。 ●运行时确定ISA分支等。基于JIT编译的算子优化执行流程图性能收益 ●单算子测试：使能KDNN前后，单线程情况下单算子平均性能提升24.22%。 ●端到端推理：某粗排模型推理性能提升10%。 FusedMatmul算子优化优化策略 ●图优化增强：通过ANNC Rewriter在图优化层面增强Pattern匹配能力，支持匹配Matmul+AddV2+Relu 等非标准Pattern（开源TensorFlow仅支持Matmul+BiasAdd+Activation）。 ●Kernel劫持与融合：劫持Eigen实现，将符合条件的Fusion类型转发到KDNN FusedMatmul接口。KDNN通过post-ops将算子融合信息传递给JIT，在控制K循环中加载对应的post-ops，生成融合内核，将中间结果保留在寄存器中，避免额外内存读写。性能收益 ●单算子测试：使能KDNN前后，单算子平均性能提升34.45%。 ●模型端到端推理性能平均提升4%。其他KDNN算子适配优化策略 ●Sigmoid算子：在UnaryOp内部判断，调用KDNN Sigmoid算子完成运算。 ●Softmax算子：在SoftmaxOp内部判断，调用KDNN Softmax算子完成运算。 ●Concat算子：在ConcatBaseOp内部调用KDNN Concat算子完成运算。性能收益即便算子热点占比不大，在多个模型下仍带来1%-3%的端到端性能收益。算子间调度优化现状概述在ARM64架构上，GetCurrentClockCycle()读取的是CNTVCT_EL0（虚拟定时器计数器）。其频率是固定的（通常为100 MHz），与CPU核心主频无关。而x86架构上读取的是TSC（时间戳计数器），频率等于CPU主频（如2.3 GHz）。TensorFlow的executor使用周期计数来动态估计op的代价，并据此决定是在线程池中调度还是内联执行。关键阈值kOpIsExpensiveThresholdCycles=8000是基于x86 TSC校准的。当前实现如下图所示。成本估计值函数。在ARM64上，由于CNTVCT频率远低于CPU主频，同样的op产生的周期数约为x86的1/23（以100 MHz vs 2.3 GHz 计算）。这导致本应被标记为“昂贵”的op被错误地判定为“廉价”，最终这些op被内联执行，无法利用线程池并行，整体推理性能不及预期。优化策略在ARM64 Linux平台上，自动检测CNTVCT频率和CPU主频，并将二者的比值作为缩放因子，在更新代价估计时应用该因子。具体逻辑如下。 1. 通过mrs cntfrq_el0汇编指令读取CNTVCT频率（ARM架构保证用户态可访问）。 2. 读取cpuinfo_max_freq文件获取CPU最大频率。 3. 计算scale=cpu_freq/cntfrq。 4. 在UpdateCostEstimate()中将elapsed_cycles乘以scale。如果sysfs文件不可读（如某些容器环境），则保持默认值scale=1，不会崩溃或产生错误行为。性能收益 GatherV2等算子由串行执行变为并行执行，时延大幅降低。此项工作已合入上游社区。