ascendc-perf-optimize

Diagnose Ascend C operator bottlenecks and generate tiling optimization strategies via four-step pipeline analysis.

Updated Sep 15, 2026
One-click install
npx skills add https://github.com/WangWindow/CANN-BatchMatMulMaxsum --skill ascendc-perf-optimize-wangwindow
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ascendc-perf-optimize
Source: https://github.com/WangWindow/CANN-BatchMatMulMaxsum/tree/main/.agents/skills/ascendc-perf-optimize
Command: npx skills add https://github.com/WangWindow/CANN-BatchMatMulMaxsum --skill ascendc-perf-optimize-wangwindow

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Ascend C operators on Ascend NPU hardware often underperform due to poor tiling parameters, unbalanced communication-compute overlap, or unidentified hardware unit bottlenecks. This Skill provides a structured four-step methodology to diagnose performance bounds and produce concrete tiling corrections. ## Core Features & Use Cases - Four-Step Layered Pipeline Analysis: Step 1 Tiling theoretical modeling, Step 2 inter-card pipeline optimization for communication operators (AllReduce, MC² fusion), Step 3 inter-core pipeline analysis for multi-core synchronized operators, and Step 4 single-core bound diagnosis (Scalar/Memory/Vec/No-Bound). - MC² Fusion Operator Support: Enforces mandatory TilingData collection (baseM/baseN/baseK/usedCoreNum) and isolation testing to measure T_comm/T_compute, compute the R ratio, and run a pruned search over long/short block partitioning candidates. - Use Case: When profiling shows aic_scalar_ratio above 0.3 on a MatMul operator, the Skill routes to Scalar Bound strategies such as Matmul API constant folding and outputs tiling parameter corrections. ## Quick Start Ask the assistant to analyze your Ascend C operator's profiling data and simulation timeline using the ascendc-perf-optimize four-step flow, providing the operator type, shape, dtype, and kernel code.

Frequently Asked Questions about ascendc-perf-optimize

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I optimize Ascend C operator performance on Ascend NPU?

Follow the four-step layered pipeline flow: Step 1 Tiling theoretical modeling, Step 2 inter-card pipeline optimization for communication operators, Step 3 inter-core pipeline analysis for multi-core synchronized operators, and Step 4 single-core bound diagnosis. Steps 2 and 3 are conditional and skipped for ordinary compute operators.

What inputs are needed for Ascend C operator performance analysis?

You need the operator type and compute flow (kernel code or pseudocode), shape and dtype, tiling parameters, pipeline simulation diagrams, and msprof profiling data. MC² fusion operators additionally require printed TilingData (baseM/baseN/baseK/usedCoreNum) and isolation test results.

How is bound type diagnosed for a single-core Ascend C operator?

Bound type is determined from profiling metrics: high scalar ratio indicates Scalar Bound, high MTE2 utilization with bandwidth limits indicates Memory Bound, and high Vector unit utilization indicates Vec Bound. Each bound type routes to a dedicated optimization strategy document.

What data must be collected before pipeline balancing for MC² fusion operators?

Two items are mandatory: TilingData (baseM/baseN/baseK/usedCoreNum, printed from host code via PrintTilingData) and isolation tests at tileCnt=1 that separately measure pure communication time T_comm and pure compute time T_compute to compute the R ratio. Missing data requires returning to the collection phase.

Does this flow apply to ordinary MatMul operators without communication?

Yes, but only Steps 1 and 4 execute. Ordinary compute operators like MatMul skip Step 2 (inter-card, communication-only) and Step 3 (inter-core synchronization only), going directly from Tiling modeling to single-core bound diagnosis.

Why is aic_mte2_ratio misleading for MC² fusion operators?

In MC² operators, CrossCoreWaitFlag hangs on the AIC MTE2 pipeline, so aic_mte2_ratio includes communication wait idle time rather than real memory pressure. Compare full-operator versus pure-compute isolation test ratios; if polluted, route to communication masking strategies instead of memory optimization.