Ascend C 算子极致调优实战：从 Row-Pack、双缓冲到 L2 Cache 旁路

核心结论：在 Ascend 910B 算子优化中，当单次搬运数据量远超片上 L2 Cache 容量（例如 C2 场景的 165 MiB 单次流式输入）且算子处于极端 Memory-Bound（MTE2 占比 >95%）时，通过 SetL2CacheHint(CacheMode::CACHE_MODE_DISABLE) 非对称地旁路大输入流的 L2 缓存，不仅能避免 Cache Line 剧烈颠簸并保留高频广播行在 L2 的命中，还能大幅降低 MTE2 与 MTE3 的总线带宽争抢，在纯内核层带来 16% 的确定性降耗。结合此前的行打包（Row-Pack）与软件流水编排，算子整体耗时从 616.5 µs 暴降至 346.17 µs（耗时降低 43.8%）。

1. 算子背景与问题画像

在算子挑战赛的 Greater 算子（ $x_1 > x_2 \to y$ ）中，算子需支持 5 种数据类型（int32, fp32, fp16, bf16, int8）以及最高 8 维的复杂广播规则。

在竞赛官方评测集（Score 权重分布）中，有一个决定总成绩生死的超大用例 C2：

Shape 规格： $x_1 \in [40320, 1023]$ ，输入类型为 int32； $x_2 \in [1, 1023]$ （或对称的左广播形式）。
总元素规模： $40320 \times 1023 = 41,247,360$ 个元素（约 41.25 M 元素）。
数据吞吐量：输入张量单体大小为 $41.25\text{ M} \times 4\text{ B} \approx 164.99\text{ MiB}$ ；输出 uint8 为 $41.25\text{ MiB}$ ；有效访存总量达 206.24 MiB。
评测权重：在官方得分矩阵中，C2 场景单项耗时占据了总耗时的 58.7%，是名副其实的“胜负手”。

初始基线的核心痛点

初始功能对齐的正确性基线在 910B 上的 Task Duration 高达 616.53 µs。分析其底层硬件行为，暴露出多重致命缺陷：

[GM: 40320 行 × 1023 int32]
      │
      │ 40,320 次单独的短 DMA (每次仅 1023 int32 = 4092 B)
      ▼
   [UB Buffer: 逐行读入 -> 逐行计算 -> 逐行写回 GM]
      │
      │ 40,320 次单独的 MTE3 DataCopy 写回
      ▼
[GM: 40320 行 × 1023 uint8]

DMA 发射开销淹没有效带宽：每次搬运仅 4092 字节，40,320 次微小 DMA 使得 MTE2 指令发射和队列同步开销占据主体。
非 32B 对齐地址违例隐患：1023 个 int32 占 4092 字节，不是 32 字节整数倍（ $4092 = 127 \times 32 + 28$ ）。如果在 UB 中紧凑连续排布，后续行的首地址将无法满足 Ascend C 向量计算的 32B 对齐硬性约束。
极高的 MTE2 等待：单核分片虽然将 40,320 行分摊到 40 个 AIV 核（每核处理 1008~1024 行），但每个核内部均处于严重的访存停顿状态。

2. 优化演进全景：从 616µs 到 346µs

整个优化历程经历了从“结构性批量搬运”、“流水重叠”、“输出合并”到“底层缓存架构旁路”的五阶段迭代：

优化阶段	核心改动策略	C2 Task Duration (msprof)	相对前版降低	累计相对基线降低
Baseline	逐行搬运与逐行计算	616.53 µs	—	—
Stage 1	Padded 行打包 (`PACK_ELEMS=8192`) + 广播行跨块缓存	475.99 µs	-22.8%	-22.8%
Stage 2	行打包扩容 (`PACK_ELEMS=12288`)，单块 12 行	412.68 µs	-13.3%	-33.1%
Stage 3	输入双缓冲流水 (Guarded Input Pipeline)	398.78 µs	-3.4%	-35.3%
Stage 4	输出整块批量写出 + int32 原地比较融合 (`PACK_ELEMS=16384`)	392.76 µs	-1.5%	-36.3%
Stage 5	大张量流式 L2 Cache Hint 旁路 (`CACHE_MODE_DISABLE`)	346.17 µs	-11.9%	-43.8%

3. 核心优化一：Padded 行打包与广播行跨 Block 缓存

针对逐行搬运碎片化的问题，第一步是在 Universal/General 路径中引入多行打包（Row-Packing）。

32B 硬件对齐约束与 Padded 布局

根据昇腾官方架构规范，Vector 单元的所有操作数起始地址必须严格满足 32 字节对齐。

若直接将多行 1023 个 int32 密集拼装在 UB：

Row 0 起始偏移： $0 \times 4092 = 0\text{ B}$ （对齐）
Row 1 起始偏移： $1 \times 4092 = 4092\text{ B}$ （ $4092 \pmod{32} = 28 \ne 0$ ！触发硬件未对齐异常或静默错误）

为了在享受成块 DMA 搬运的同时保证每一行的 UB 起始地址合法，设计了 Padded Row 布局：

           ◄─────────── 4092 字节 (1023 int32) ───────────► ◄── 4B Pad ──►
Row 0:    [                       有效数据                  ] [ 0 0 0 0 ]  (4096B, 32B对齐)
Row 1:    [                       有效数据                  ] [ 0 0 0 0 ]  (4096B, 32B对齐)
Row 2:    [                       有效数据                  ] [ 0 0 0 0 ]  (4096B, 32B对齐)

在代码中通过 PackedRowElems 定义行间跨度：

template <typename T>
__aicore__ inline uint32_t PackedRowElems(uint32_t innerLen)
{
    // 将每行的字节长度向上对齐到 32 字节边界
    const uint32_t pitchBytes = AlignCount(innerLen * static_cast<uint32_t>(sizeof(T)), 32u);
    return pitchBytes / static_cast<uint32_t>(sizeof(T));
}

利用 DataCopyExtParams 的 2D 搬运语义：

DataCopyExtParams copyParams{
    static_cast<uint16_t>(rows),                     // blockCount: 搬运的行数
    static_cast<uint32_t>(innerLen * sizeof(T)),    // blockLen: 单行真实字节数 (4092)
    static_cast<uint32_t>(srcStride),               // GM 侧跨步
    static_cast<uint32_t>((pitchBytes - AlignCount(innerLen * sizeof(T), 32u)) / 32u), // dstStride
    0
};
DataCopyPad(dst, src, copyParams);

广播行跨 Block 驻留复用

对于广播输入（例如 $x_2 \in [1, 1023]$ ），其在倒数第二维的 stride 为 0。

旧逻辑：每个 Block 重复去 GM 搬运一次这 1023 个标量行。
新逻辑：将该行缓存在独立专属的 UB Buffer（pack0Buf_）中，在当前核负责的整个连续行 Run 期间常驻，仅在首个 Block 加载一次，跨 Block 100% 复用。

向量尾部安全边界 (`MaxPackedRows`)

Ascend C 的 Select 和 Cast 向量指令按 128 元素（256 字节）为执行粒度，在计算行尾时会自动向后读取到 128 对齐的边界。若最后一个打包行紧贴 UB 缓冲区上界，向量指令的尾部读取会造成越界访存。因此 MaxPackedRows 计算不仅要受限于 DMA Pitch 容量，还必须加入尾部余量校验：

const uint32_t vectorBytes = AlignCount(innerLen, 128) * elemBytes;
const uint32_t vectorRows = 1 + (capacity - vectorBytes) / pitch;
if (rows > vectorRows) rows = vectorRows;

4. 核心优化二：输入双缓冲流水编排 (Input Double Buffering)

单靠行打包，计算和搬运依然是“等数据搬完再计算”的串行模式。为此为移动输入（Moving Input）构建三段式软件流水：

Time ──►
MTE2 : [Load Block 0] [Load Block 1] [Load Block 2] [Load Block 3] ...
Vector:               [Compute B0  ] [Compute B1  ] [Compute B2  ] ...

软件流水防劣化守卫 (Guard Condition)

并非所有形状都适合无脑开双缓冲。实测发现，当单行长度较短（如 inner=511）时，由于单块数据量太小，双缓冲引入的 TQue 事件同步开销（MTE2_V、V_MTE2）反而超过了流水收益，导致耗时从 309 µs 劣化至 371 µs。

因此设计了严格的守卫判定函数 CanPipelineRows()：

__aicore__ inline bool CanPipelineRows() const
{
    return path_ == PATH_GENERAL && ndim_ >= 2 &&
           outer_ >= (GetBlockNum() == 0 ? 1 : GetBlockNum()) &&
           inner_ <= 2048 &&
           (PACK_ELEMS / inner_) <= 16 &&
           ((stride0_[ndim_ - 2] == 0 && stride1_[ndim_ - 2] >= inner_) ||
            (stride1_[ndim_ - 2] == 0 && stride0_[ndim_ - 2] >= inner_));
}

只有满足单侧完全广播、内维规则连续、行长合理的大块场景才切入流水，兼顾了 C2 的提速与小形状的稳定性。

5. 核心优化三：输出块批量写出与 int32 原地计算融合

经过输入流水优化后，算子耗时压到了 398.78 µs。此时观察执行流，发现了一个明显的流水不对称： 输入已经是以 12~16 行为单位成块流水，但输出写回 GM 依然是每一行触发一次 CopyOutQueued！

旧输出流水：
Loop rows (12次):
   Compute Row(r) ──► EnQue(out) ──► DeQue(out) ──► DataCopyPad GM (单行 1023B)
整个算子共发出 40,320 次 MTE3 DMA 写指令！

输出批处理 (`CopyOutPacked`)

为解决输出 MTE3 拥堵，重构了输出流水：

为整块（Block）分配统一的输出大 Buffer outQue_.AllocTensor<uint8_t>()。
逐行计算的结果按 outputPitch = AlignCount(n, 128) 偏移写入当前块的不同切片。
待整块所有行全部计算完成后，仅发射一次带行跨度的 2D DataCopyPad 写回 GM：

__aicore__ inline void CopyOutPacked(uint64_t yOff, uint32_t rows, uint32_t n, uint32_t pitch)
{
    LocalTensor<uint8_t> output = outQue_.DeQue<uint8_t>();
    GlobalTensor<uint8_t> dst;
    dst.SetGlobalBuffer((__gm__ uint8_t *)(yGm_.GetPhyAddr() + yOff));
    // 2D 搬运：将 UB 中带 128 对齐 pitch 的多行布尔值紧凑打回 GM
    DataCopyExtParams p{
        static_cast<uint16_t>(rows),
        n,
        (pitch - AlignCount(n, 32)) / 32,
        0,
        0
    };
    DataCopyPad(dst, output, p);
    outQue_.FreeTensor(output);
}

收益：整算子的 MTE3 DMA 发射次数从 40,320 次骤降至 2,688 次（降幅达 93.3%）！

int32 原地比较融合与 Pack 容量扩充

对于 int32 数据类型，移动输入行在被计算消费后即可废弃。因此直接利用移动输入缓冲作为临时工作区，避免分配额外的 workBuf_：

if constexpr (std::is_same_v<T, int32_t>) {
    if (broadcastLeft) {
        Min(moving, cached, moving, n); // 原地更新 moving
    } else {
        Max(moving, cached, moving, n); // 原地更新 moving
    }
    Compare(mask, moving, cached, CMPMODE::EQ, aligned);
    InvertInt32EqMask(mask, aligned);
}

注意关键细节：这里的 Min/Max 长度必须严格为真实元素数 n（1023），绝对不能取 aligned（1024 或 1152）。因为 moving 是打包紧凑排布的，如果向量尾部写入了未消费的下一行首部数据，会彻底破坏后续行的原始输入！

由于省去了 int32 的中间临时缓冲区，UB 内存空间得以大幅释放。将 PipelinePackElems 从 12,288 扩充至 16,384，使得 C2 的单次批处理行数从 12 行跃升至 16 行。

6. 核心优化四：大张量流式 L2 Cache Hint 旁路 (The L2 Pass)

在完成上述所有流水线优化后，算子进入了最难啃的“性能平台期”（392 µs）。为了找到真正的瓶颈根因，开启了 Ascend Profiler 的 PipeUtilization 硬件计数器进行全指标采样。

Profiler 揭示的惊人数据

下表为 910B4 评测机上的官方入口 PipeUtilization 对比：

指标项目	基线状态（已带输入输出流水）	占比说明
Task Duration	413.11 µs	算子物理总耗时
AIV Time	399.60 µs	AI Vector 核活跃时间
MTE2 Time	380.93 µs	95.3% 的 AIV 时间耗在 GM ➔ UB 读搬运！
Vector Time	122.17 µs	30.6%（已与 MTE2 深度重叠）
Scalar Time	104.29 µs	标量循环控制
MTE3 Time	113.54 µs	UB ➔ GM 写回
I-Cache Miss	0.0%	指令缓存命中完美

数据给出了残酷的诊断结果：无论怎么精简 Vector 指令，算子依然有 95.3% 的时间在干等 MTE2 从内存搬数据！

存储体系架构分析：为什么 L2 Cache 成了累赘？

深入 Ascend 910B 的片上存储层级：

  [ HBM / DDR (主存: 吞吐高、延迟大) ]
                 ▲
                 │ (NoC / Crossbar 互联总线)
                 ▼
  [ 片上共享 L2 Cache (数十 MiB 规模，全局共享) ]
        ▲                            ▲
        │ MTE2 读通道                │ MTE3 写通道
  ┌─────┴────────────────────────────┴─────┐
  │         AI Vector Core (40 个)         │
  │  [ UB: Unified Buffer (192 KiB / 核) ] │
  │  [ Vector Execution Unit (SIMD)      ] │
  └────────────────────────────────────────┘

工作集远超 L2 容量： C2 的移动输入达到 164.99 MiB，而 910B 的全局共享 L2 Cache 容量仅在数十 MiB 量级。
读一次即丢弃（Streaming Read-Once）：这 165 MiB 的数据在整个算子执行周期中，每个字节只会被 MTE2 从内存读取到 UB 中计算恰好一次，毫无时间局部性（Temporal Locality）。
剧烈的 Cache Thrashing（缓存颠簸）：在默认缓存模式（CACHE_MODE_NORMAL）下，硬件 MTE2 会为每一笔读请求在 L2 中分配 Cache Line、查询 Tag、执行伪 LRU 替换并驱逐原有数据。这不仅毫无命中收益，反而在 L2 控制器内部引发了海量的分配/驱逐握手开销。
踢出高频广播行，反噬局部性：更糟糕的是，原本常驻在 L2 中的那一行仅 4092 字节的高频广播行数据，被排山倒海般涌入的 165 MiB 垃圾流直接从 L2 强制驱逐回 HBM，导致其它核去读广播行时频繁遭遇 L2 Cache Miss！
内部总线严重争抢： MTE2 的庞大读请求流与 MTE3 的写回流同时在 L2 端口挤兑，造成总线仲裁延迟激增（MTE3 耗时高达 113 µs）。

解决方案：非对称 L2 缓存策略

Ascend C 提供了底层的全局张量缓存修饰 API：SetL2CacheHint。

通过对数据通路的访存特征进行正交解耦，实施非对称缓存控制：

template <typename T>
__aicore__ inline void LoadRows(const LocalTensor<T> &dst, GlobalTensor<uint8_t> &base, uint64_t elemOff,
                                uint32_t rCount, uint32_t innerLen, uint64_t rowStride,
                                uint64_t innerStride, bool bypassL2 = false)
{
    GlobalTensor<uint8_t> src;
    src.SetGlobalBuffer((__gm__ uint8_t *)(base.GetPhyAddr() + elemOff * sizeof(T)));

    // 关键优化点：对单次流式大张量，彻底禁用 L2 Cache 分配与填充
    if (bypassL2) {
        src.SetL2CacheHint(CacheMode::CACHE_MODE_DISABLE);
    }

    LocalTensor<uint8_t> raw = dst.template ReinterpretCast<uint8_t>();
    // 发起连续或 Strided DMA...
}

在行流水入口，设定严格的容量触发门限：

// 仅当为 int32 类型且逻辑总输入规模 >= 128 MiB 时触发 L2 旁路
const bool bypass = (dtype_ == DTYPE_INT32) &&
                    (outer_ * inner_ >= (128ULL << 20) / sizeof(int32_t));

LoadRows<T>(moving, gm, base, rows, static_cast<uint32_t>(inner_), rowStride, 1, bypass);

[广播行 (4 KB)] ──► CACHE_MODE_NORMAL  ──► 稳定常驻 L2 Cache (高命中率)
[移动流 (165 MB)] ──► CACHE_MODE_DISABLE ──► 直接旁路 L2 直通 HBM (零污染、零颠簸)

优化效果验证

上板实测结果极其震撼：

评测维度	L2 默认策略 (基线)	L2 Cache Disable (优化版)	改善幅度
Task Duration	413.11 µs	348.65 µs	-64.46 µs (-15.6%)
AIV Time	399.60 µs	330.76 µs	-68.84 µs (-17.2%)
MTE2 Time	380.93 µs	313.53 µs	纯省 67.4 µs 硬件搬运停顿！
Vector Time	122.17 µs	122.17 µs	绝对持平（计算未受影响）
MTE3 Time	113.54 µs	63.95 µs	大幅下降 49.59 µs（总线争抢解除）

MTE2 耗时缩减与总耗时下降严格吻合：MTE2 减少的 67.4 µs 几乎 1:1 地直接转化为了算子最终物理时延的下降。
总线拥堵消除红利：MTE3 耗时从 113.54 µs 锐减至 63.95 µs，证明大输入不再经过 L2 后，内部总线仲裁和跨核互联资源得到了极大释放。

7. 科学的泛化验证与工程克制：为什么其它 Dtype 不合入？

在 C2（int32）上取得巨大成功后，直觉反应是将 CACHE_MODE_DISABLE 推广至 FP32、FP16、BF16 和 INT8。然而，严谨的工程实践必须建立在同机 A/B 实测与瓶颈拆解之上。

全数据类型 A/B 测试矩阵

在物理卡 910B4 上，覆盖 4 种类型、原 C2 广播形状、1/4 外层规模、1025 列边界等 24 个场景进行对比：

数据类型	原形状左广播：基线耗时	原形状左广播：L2 旁路耗时	耗时变化	决策结果
FP32	268.41 µs	268.06 µs	仅降 0.13% ~ 0.73%	收益微弱，不合入
FP16	269.43 µs	267.83 µs	仅降 0.55% ~ 0.74%	收益微弱，不合入
BF16	275.19 µs	276.17 µs	回退 0.38%	产生负收益，坚决回退
INT8	275.86 µs	272.10 µs	降 1.28% ~ 1.90% (无条件)	加判断条件后收益归零，不合入

为什么在其它类型上无效？—— 再次探访 Profiler

通过采样各类型在基线状态下的 PipeUtilization，发现了惊人的真相：

数据类型	MTE2 Ratio	Vector Ratio	Scalar Ratio
FP32	46.95%	29.70%	98.75%
FP16	26.95%	25.70%	99.10%
BF16	26.85%	45.20%	99.00%
INT8	17.40%	37.00%	99.15%

关键认知反转：此前 int32 的 C2 表现为 MTE2 占比 95.3%，是彻头彻尾的 Memory-Bound；而在 FP32/FP16/BF16/INT8 下，由于数据位宽较小、类型转换（Cast to Float/Half）及通用循环展开策略不同，它们的瓶颈全部变成了 Scalar 流水线占用（占比达 98%~99%）！此时访存根本不是主要瓶颈，盲目增加 L2 缓存配置反而增加了标量指令判断开销。

最终工程取舍：严守奥卡姆剃刀原则，只保留已获绝对收益的 dtype == int32 && size >= 128MB 门限分支，其余分支代码完全维持原样，确保全局零性能回归。

8. 评测基准反思：官方前置 Mul 的“冷热缓存”效应

在排查 C5 场景（FP32 [2320, 4511] 连续对比，约 10.46 M 元素）时，还揭露了一个极其隐蔽的评测环境陷阱。

诊断脚本与官方入口的脱节

竞赛官方评测在调用 Greater 算子之前，会在同一个进程中先运行 30 轮 aclnnMul，每次 Mul 涉及 3 个 $4096 \times 4096$ 的 FP32 张量（单张量 64 MiB）。

非官方诊断脚本：常通过设置环境变量跳过 Mul，直接循环压测 Greater。此时连续运行的 Greater 会将输入反复留在 L2 热缓存中，测出 65.66 µs 的假象好成绩。
官方真实入口：前置的 64 MiB Mul 会彻底冲刷并清空 L2 缓存。真实运行环境下的 C5 基线耗时为 193.42 µs。

脱离真实的评测上下文，在“人工热缓存”上做出的微调优化，在平台真实评分时往往会原形毕露。
任何涉及 L2 / HBM 缓存行为的优化，必须在包含真实前置冲刷负载的环境下闭环验证。

9. 总结与 Ascend C 性能工程方法论

从 Greater 算子 C2 场景 616 µs 到 346 µs 的演进，沉淀出以下可直接迁移至其它昇腾算子的核心方法论：

先结构后微调：在单条指令优化之前，必须先消除碎片化调度。Row-Packing 将 40,320 次 DMA 压降几个数量级，奠定了后续所有流水重叠的基础。
谨守 32B 与 128-element 硬件边界： UB 内存中每一行的首地址必须 32 字节对齐（Padded Layout）；所有尾部操作必须考虑 128 元素向量加载防越界，否则在异步硬件执行时会产生致命的内存越界。
输出流水同样需要批处理：不要只盯输入双缓冲。当算子输出为低位宽类型（如布尔 uint8）时，逐行写回 GM 会产生极其高昂的 MTE3 拥挤，必须配合 2D Strided DMA 进行成块写回。
超大张量果断旁路 L2：单次流式读写、无复用局部性且数据量远超片上 L2 容量的超大张量，果断调用 SetL2CacheHint(CacheMode::CACHE_MODE_DISABLE)。它不仅能拯救 L2 免于颠簸，还能显著压降芯片内部互联总线的争抢延迟。
拒绝凭直觉泛化，相信硬件计数器：在某一类型上有效的优化，推广到其他类型前必须查验 Profiler。当 MTE2 占比从 95% 跌到 20%、Scalar 占比飙到 99% 时，必须立刻停止访存优化，转向标量指令去重与指令流精简。