Architecture & Representation-Design Analysis
Toward a Standardized Representation for Deep Learning Collective Algorithms (Chakra ET extension)
Source: Yoo, J.; Won, W.; Cowan, M.; Jiang, N.;
Klenk, B.; Sridharan, S.; Krishna, T. Toward a Standardized
Representation for Deep Learning Collective Algorithms. In
IEEE Micro — Hot Interconnects 31 special issue, vol.
45, no. 2, pp. 46-55, Mar/Apr 2025. Theme article. DOI:
10.1109/MM.2025.3547363 Date of publication: 5 March
2025; date of current version 29 April 2025. Code
references: ASTRA-sim collective API at https://github.com/astra-sim/collectiveapi
; Chakra schema under https://github.com/mlcommons/chakra
(MLCommons working group). Authors: Jinsun Yoo, William
Won (Georgia Tech, co-first authors); Meghan Cowan, Nan Jiang, Benjamin
Klenk, Srinivas Sridharan (NVIDIA); Tushar Krishna (Georgia Tech).
Reader: Direct PDF read (gemini-reader free-tier
RESOURCE_EXHAUSTED on gemini-2.0-flash; codex-reader
rejected gpt-5.1-codex-mini for ChatGPT free-tier accounts;
pages 1-10 read directly via the Read tool with pages
parameter). Analyst: Vishwakarma Date:
2026-05-04
Table of Contents
- Lineage Note — Where Chakra-ET-for-Algorithms Sits in the Synthesis/Representation Family
- The Representation Problem — A Two-Producer / Two-Consumer Bipartite Mismatch
- The Common-Format Architecture (the proposed standardized workflow)
- The Chakra ET Schema as the Unification Substrate
- Target Producers: MSCCLang DSL and TACOS Synthesizer
- Target Consumers: ASTRA-sim Simulator and MSCCL-Runtime
- Algorithmic Encoding — How a Ring Reduce-Scatter Becomes a Chakra-ET DAG
- The Compute-Communicate Overlap Lift (Section "Fine-Grained Compute-Communicate Overlap")
- Algorithm / Control Flow — End-to-End Workflow from MSCCLang Source to ASTRA-sim Result
- Quantitative Results — Empirical Findings by Regime (Tables 2 + Fig. 8)
- Configuration-Regime Trade-off Tables
- Bottlenecks & Insights Surfaced by the Measurements
- Limitations of the Methodology
- What to Borrow for DynamICCL — Composability vs Tension with Run-Time Knob Selection
- Analogy
1. Lineage Note — Where Chakra-ET-for-Algorithms Sits
The six immediately preceding papers in this corpus all attack the "how do I produce or run a custom collective algorithm" question. Chakra-ET-for-algorithms is fundamentally different: it does not produce schedules and it does not run schedules. It proposes a common format so that the producers and consumers can talk to each other.
+------------------------------------------------------------------+
| SCCL (PPoPP 2021, paper 0031) |
| SMT-based offline synthesizer. Output: MSCCL-IR XML. |
| | |
| v |
| TACCL (NSDI 2023, paper 0032) |
| MILP synthesizer with "communication sketch". Output: same |
| MSCCL-IR XML. |
| | |
| v |
| MSCCLang / GC3 (ASPLOS 2023 / arXiv 2022, papers 0033, 0034) |
| DSL programmability + 3-IR compiler. Output: MSCCL-IR XML. |
| | |
| v |
| TE-CCL (SIGCOMM 2024, paper 0035) |
| Multi-commodity-flow synthesizer. Output: scheduling table |
| that must be lowered to MSCCL-IR or its own format. |
| | |
| v |
| SyCCL (SIGCOMM 2025, paper 0036) |
| Symmetry-decomposed MILP. Output: MSCCL XML (run by |
| MSCCL-Runtime). |
| | |
| v |
| Chakra-ET-for-algorithms (Hot Interconnects 31 / IEEE Micro |
| 2025, this paper, 0037) |
| Not a synthesizer. Not a runtime. A *representation paper* |
| that says: every producer above (MSCCLang, TACCL, TACOS, ...) |
| and every consumer (ASTRA-sim, MSCCL-Runtime, ...) should |
| speak Chakra ET — the same DAG format already used for ML |
| *workload* traces. Promote collective-algorithm IR from a |
| bespoke per-tool format (MSCCL-IR XML, TACOS TEN, ...) into a |
| shared graph schema. |
+------------------------------------------------------------------+
^ Fig 0: Lineage of CCL artifacts. Papers 0031-0036 each invented or
consumed a distinct representation (XML, TEN, custom DAGs). Paper
0037 proposes that all of them converge on Chakra ET, the format
already used by MLCommons for distributed-ML workload traces.The intellectual move is uniform interface across producers and consumers, the same pattern UNIX promoted with byte streams and that LLVM IR promoted for compilers. The paper does not invent a new algorithm or a new optimization; it argues the field has accumulated enough custom IRs that interoperability has become the bottleneck, and the cheapest fix is to reuse Chakra ET — a graph schema that already exists, already has tooling, and was originally designed for distributed-ML workloads, not collective algorithms.
For DynamICCL the lineage observation is critical. Every paper above 0036 defines a static schedule (or family of schedules) that has to be selected at run time. DynamICCL is the selector, not a producer. If the producer outputs Chakra ET, DynamICCL gains a uniform input format for its action space, regardless of which synthesizer (TACCL, TACOS, SCCL, MSCCLang) created the candidate schedule. The paper's representation move directly enables a clean separation: "synthesizer produces Chakra ET candidate schedules; DynamICCL learns which one to pick per (topology, msg_size, model intensity) bucket."
2. The Representation Problem — A Two-Producer / Two-Consumer Bipartite Mismatch
The problem statement, paraphrased from Section "Motivation: Needs for Standardization":
BEFORE Chakra-ET-for-algorithms:
+-------------------------------------------------------------+
| |
| Producers (each with its own format) |
| MSCCLang --> MSCCL-IR (XML) |
| TACCL --> MSCCL-IR (XML, after lowering) |
| TACOS --> Time-Expanded Network (TEN, custom) |
| |
| Workload format (separate, even-more-different) |
| PyTorch profiles |
| Megatron-LM hand-written manifests |
| FSDP manifests |
| --> Chakra ET (already standardized via MLCommons) |
| |
| Consumers |
| ASTRA-sim <-- needs workload + algorithm, |
| but reads workload as Chakra ET and |
| hard-codes algorithms in its System |
| layer (only "ring", "halving-doubling"|
| built-in) |
| MSCCL-Runtime <-- needs algorithm only, reads MSCCL-IR |
| XML and runs it on real GPUs |
| Profilers <-- want workload AND algorithm to attribute|
| latency to the right operator |
| |
| Engineering cost = O(#producers x #consumers x #formats) |
+-------------------------------------------------------------+The complaint is that workload representation has converged on Chakra ET (thanks to MLCommons), but collective-algorithm representation has not. So we have an asymmetry: a tool can ingest a workload uniformly, but cannot ingest the collective algorithm that implements the AllReduce node inside that workload — it has to choose between (a) building a parser for every producer's format, or (b) re-implementing the algorithm in its own internal IR. The paper quotes that this duplication is "highly prohibitive" and "must be repeated for every pair of upstream and downstream tools" — an explicit O(P * C) blow-up where P = producers, C = consumers.
The proposed shift:
AFTER Chakra-ET-for-algorithms:
+-------------------------------------------------------------+
| |
| MSCCLang ---+ |
| TACCL ---+--> Chakra ET (algorithm) ---+ |
| TACOS ---+ | |
| +--> ASTRA-sim
| PyTorch ---+ | |
| Megatron ---+--> Chakra ET (workload) ----+--> MSCCL-Runtime
| FSDP ---+ | |
| +--> Profiler
| |
| Engineering cost = O(#producers + #consumers) |
| (one converter per producer, one parser per consumer) |
+-------------------------------------------------------------+
^ Fig 1: Bipartite collapse. The standardized format reduces the
cross-product engineering cost to a sum. This is the same Big-Idea
as UNIX's "byte stream as universal interface" or LLVM IR's "front
ends and back ends share one IR".The economic argument is the entire paper: standardize representation -> tooling becomes plug-and-play -> research focuses on algorithms, not glue code.
3. The Common-Format Architecture (the proposed standardized workflow)
Figure 1 of the paper depicts the full proposed workflow. Translated to the conventions of this analysis directory:
+------------------------------------------------------------------+
| Chakra ET Standardized Workflow |
| |
| +----------------------------+ +----------------------------+|
| | Workload Producers | | Algorithm Producers ||
| | - PyTorch profiler | | - MSCCLang DSL ||
| | - Megatron-LM manifests | | - TACCL synthesizer ||
| | - FSDP manifests | | - TACOS synthesizer ||
| +-------------+--------------+ +--------------+-------------+|
| | | |
| v v |
| +---------------------------------------------------------+ |
| | CHAKRA ET (common DAG schema) | |
| | | |
| | Workload graph Algorithm graph | |
| | +-------------+ +-----------+ | |
| | | COMP | | COMM_SEND | | |
| | | | | | | | | |
| | | ALL_GATHER | <--EXPAND-- | COMM_RECV | | |
| | | | | | | | | |
| | | ALL_REDUCE | | COMM_SEND | | |
| | | | | | | | | |
| | | MEMORY | | COMM_RECV | | |
| | | | | +-----------+ | |
| | | COMP | | |
| | +-------------+ | |
| | | |
| | Both graphs use the same node schema (Table 1): | |
| | COMM_SEND, COMM_RECV, COMP | |
| | plus collective placeholder nodes (ALL_REDUCE etc.) | |
| | that the consumer expands at simulate/run time. | |
| +-----+-----------------------------------+-----------------+ |
| | | |
| v v |
| +-----+----------------+ +------+---------------+ |
| | Distributed ML | | GPU Clusters | |
| | Simulators | | | |
| | - ASTRA-sim | | - MSCCL-Runtime | |
| | - proprietary | | (NCCL backend) | |
| | simulators | | | |
| +----------------------+ +----------------------+ |
+------------------------------------------------------------------+
^ Fig 2: The proposed workflow. The novelty is the dotted "EXPAND"
arrow inside Chakra ET: a workload's ALL_REDUCE placeholder node
is replaced (expanded) by an algorithm sub-graph at simulate-time
or run-time. This is the *same* placeholder substitution UNIX does
with shell command substitution and LLVM does with intrinsic
lowering — composition by substitution.The architectural commitments:
- One schema, two roles. The same Chakra ET schema is reused for both workload and algorithm graphs. No new IR is invented.
- Placeholder-and-expand composition. A workload's
collective node (e.g.,
ALL_REDUCE) is a placeholder that downstream tools substitute with an algorithm DAG. The substitution boundary is the collective name + size, and the substitution discipline is "match the input/output dependencies, replace the interior." - Producer and consumer decoupling. A producer never has to know which consumer will use its output; a consumer never has to know which producer made its input. The only contract is the schema.
- Single-NPU DAG, multiple-NPU graph collection. Each
Chakra ET trace is a collection of per-NPU DAGs (one DAG per
NPU). The inter-NPU dependencies are encoded by matching
COMM_SEND/COMM_RECVpairs whose source/destination IDs identify partner NPUs — see Section 7.
The architectural style is recognizably the same uniform-interface philosophy as the UNIX paper's everything-is-a-file, applied at the distributed-ML graph layer. The paper does not say so, but the move is identical: pick a representation that already exists, force the ecosystem to converge on it, and let composition emerge from the shared substrate.
4. The Chakra ET Schema as the Unification Substrate
Section "Background: Chakra ET" defines the substrate. Each Chakra ET trace is a directed acyclic graph (DAG) whose nodes are operations and whose edges are interoperation dependencies. A distributed workload is a collection of DAGs, one per NPU.
Per-NPU Chakra ET DAG (workload example, Fig. 2 of paper):
+-------------------------------------------------------+
| |
| COMM_ALLGATHER ----------------------+ |
| Node_id: 0 | |
| Dependent_nodes: [] | |
| Type: COMM_COLL_NODE | |
| ProcessGroup_name: "0" v |
| Comm_type: ALL_GATHER +-------------+ |
| Comm_size: 1,048,576 | COMP_ | |
| | MatrixMul | |
| +-------------+ |
| |
+-------------------------------------------------------+
^ Fig 3: A workload-side per-NPU DAG: one collective placeholder
ALL_GATHER feeds a matrix multiply. The collective node is opaque
here — it carries name + ProcessGroup + size, but says nothing
about whether the algorithm is ring, tree, recursive halving-
doubling, or topology-aware. The "consumer must decide algorithm"
problem is exactly this opacity.The extension proposed by the paper is to lift the algorithm into the same DAG by introducing point-to-point primitives:
| Chakra ET Node Type | Description (verbatim, Table 1) |
|---|---|
| COMM_SEND | Send a point-to-point message to a destination |
| COMM_RECV | Wait for a point-to-point message that a source will send |
| COMP | Run a compute task (e.g., reduction) |
These three node types are sufficient to express any collective
algorithm because every collective is, at the wire level, a sequence of
point-to-point sends and receives plus reductions. The schema trick is
that the same COMM_SEND and COMM_RECV
node types appear in both workload graphs and algorithm graphs,
so a single parser can read both.
The destination and source IDs in send/recv nodes carry partner-NPU information, and this is what stitches the per-NPU DAGs into a global schedule:
Two-NPU send/recv pairing (from Sec. "Description: Representing
Arbitrary Collective Algorithms"):
NPU 0's DAG NPU 1's DAG
+---------------+ +---------------+
| COMM_SEND | | COMM_RECV |
| dst = 1 | - - - - > | src = 0 |
| comm_size = X | | comm_size = X |
+-------+-------+ +-------+-------+
| |
v v
+---------------+ +---------------+
| COMM_RECV | < - - - - | COMM_SEND |
| src = 1 | | dst = 0 |
| comm_size = X | | comm_size = X |
+---------------+ +---------------+
^ Fig 4: Cross-NPU dependency expressed by matching send/recv IDs.
The "- - ->" arrows are not edges in any single DAG; they are the
global dependencies recovered by matching dst on one DAG with src
on the other. Each per-NPU DAG remains a clean local DAG; the
inter-NPU coupling is a join key (dst_id == this_npu_id).This is a deliberate design: each per-NPU DAG is locally acyclic and can be replayed independently up to the synchronization points, while the global topology of cross-NPU dependencies is implicit in the send/recv ID join. It mirrors the approach taken in distributed event-trace formats (SST, OTF2) and is friendly to both discrete-event simulators (ASTRA-sim) and real runtimes (MSCCL-Runtime).
5. Target Producers: MSCCLang DSL and TACOS Synthesizer
The proof of concept extends two upstream producers:
+---------------+ write algorithm in DSL +-----------------+
| User / Algo | ---------------------------> | MSCCLang Python |
| Designer | | DSL |
+---------------+ +--------+--------+
|
compile to MSCCL-IR XML
|
v
+-----------------------------+ +--------------------+
| TACOS Synthesizer (TEN- | | MSCCL-IR XML |
| based topology-aware | | (per-NPU operations|
| collective synthesis) | | encoded as XML) |
+--------------+--------------+ +---------+----------+
| |
emit per-NPU Chakra-ET converter
TEN trajectories (one per producer)
| |
+-----------------+ +-------------------+
| |
v v
+----------------------------------+
| CHAKRA ET (algorithm graph) |
| - per-NPU DAGs |
| - COMM_SEND / COMM_RECV / COMP |
| - dst_id / src_id stitching |
+----------------------------------+
^ Fig 5: Two producers, one converter each, one common output. The
paper authors implemented both converters as a one-time engineering
task; future tools will write to Chakra ET directly.Concretely, for MSCCLang the converter creates a Chakra ET vertex per MSCCL-IR XML operation and re-derives interoperation edges from the XML's dependency annotations. For TACOS, which emits a time-expanded network (TEN), each chunk crossing a TEN link becomes a COMM_SEND on the sender's DAG and a COMM_RECV on the receiver's DAG, with TEN's predecessor relation supplying the local edges.
Crucially, the converter is a one-time engineering task per producer. Once written, every downstream consumer sees a uniform Chakra ET stream — the O(P+C) bound from Section 2.
| Producer | Native format | Converter responsibility |
|---|---|---|
| MSCCLang | MSCCL-IR XML | Vertex per XML op; edges from XML's Dependent_nodes
field |
| TACOS | Time-Expanded Network | One COMM_SEND/COMM_RECV pair per TEN link; chunk = comm_size |
| (future) | TACCL / SCCL output | Same translation as MSCCLang (both already lower to MSCCL-IR) |
6. Target Consumers: ASTRA-sim Simulator and MSCCL-Runtime
The proof of concept extends two consumers; the paper carries out quantitative experiments only with ASTRA-sim, but argues the same extension applies to MSCCL-Runtime.
+----------------------------------------------------------------+
| ASTRA-sim Internal Architecture (Fig. 7 of paper) |
| |
| +---------------------------------------+ |
| | Workload Layer | |
| | Reads workload Chakra ET | |
| | Walks DAG, dispatches operators | |
| +-----------------+---------------------+ |
| | |
| Issue Collective Communication |
| | |
| v |
| +------------------------------------------------+ |
| | System Layer | |
| | +-------------------------+ | |
| | | Algorithm Selector | | |
| | | (built-in vs custom) | | |
| | +-----+-------+-----------+ | |
| | | | | |
| | v v | |
| | +--------+ +-----------------------------+ | |
| | | Native | | Custom Algorithm | | |
| | | (Ring, | | <-- NEW: read Chakra ET | | |
| | | HD, | | algorithm DAG, parse | | |
| | | ...) | | send/recv/comp nodes | | |
| | +--------+ +-----------------------------+ | |
| +-----------+------------+----------------------+ |
| | | |
| | Simulate Network Send/Receive Traffic |
| v v |
| +------------------------------------------------+ |
| | Network Layer / Network Simulator | |
| | Topology, link BW, link latency, congestion | |
| +------------------------------------------------+ |
+----------------------------------------------------------------+
^ Fig 6: ASTRA-sim with the Chakra-ET-algorithm extension. The
dashed-square module is the new "Custom Algorithm" path: it
ingests the algorithm DAG as a Chakra ET file (instead of
re-implementing the algorithm in C++ inside ASTRA-sim's System
Layer). The Workload Layer was already Chakra-ET-aware; the
contribution is making the System Layer Chakra-ET-aware too.The MSCCL-Runtime path is symmetric: instead of parsing MSCCL-IR XML,
it would parse Chakra ET, translate each COMM_SEND to an
NCCL-internal point-to-point send, each COMM_RECV to a
recv, and each COMP to a reduction kernel launch. The paper
does not implement this end-to-end; it argues the extension is
mechanical because MSCCL-IR XML and Chakra ET carry the same semantic
content.
7. Algorithmic Encoding — How a Ring Reduce-Scatter Becomes a Chakra-ET DAG
Figure 3 of the paper uses a four-NPU ring Reduce-Scatter as the worked example. Its encoding is the canonical demonstration of the schema's expressiveness:
Setup: 4 NPUs in a ring (NPU0 -> NPU1 -> NPU2 -> NPU3 -> NPU0).
Each NPU starts with 4 chunks; goal = each NPU ends with one
fully-reduced chunk.
At each step:
- NPU sends chunk to next NPU in ring
- NPU receives a chunk from previous NPU
- NPU reduces the received chunk into its local copy at the
same position
Repeat 3 times (N-1 = 3 steps for N=4).
Per-NPU Chakra ET DAG (NPU 0):
+---------------------+
| COMM_SEND (chunk0) | --> NPU1 step 0
+----------+----------+
|
v
+---------------------+
| COMM_RECV (chunk3) | <-- NPU3 step 0
+----------+----------+
|
v
+---------------------+
| COMP (reduce | reduce received chunk into local step 0
| chunk3) | copy at position 3
+----------+----------+
|
v
+---------------------+
| COMM_SEND (chunk3) | --> NPU1 step 1
+----------+----------+
|
v
+---------------------+
| COMM_RECV (chunk2) | <-- NPU3 step 1
+----------+----------+
|
v
+---------------------+
| COMP (reduce | step 1
| chunk2) |
+----------+----------+
|
v
... step 2
|
v
DONE: NPU0 owns the fully-reduced chunk0+chunk1+
chunk2+chunk3 at position whichever-is-NPU0's
^ Fig 7: Per-NPU DAG for ring Reduce-Scatter. The graph is "a single
line with sequential operators" because the ring algorithm has
one critical-path send/recv/reduce per step. More-advanced
algorithms (recursive halving-doubling, multi-dim mesh) produce
graphs with parallel branches — see Sec. 8 below.The cross-NPU stitching: NPU0's COMM_SEND at step 0 has
dst = 1 and NPU1's COMM_RECV at step 0 has
src = 0; matching ID pair = one inter-NPU dependency.
Repeating this pattern across all four NPUs and all three steps fully
reconstructs the ring schedule.
The paper points out (Sec. "Description") that this encoding scheme extends to arbitrary collectives:
"Advanced algorithms or communications that span multiple dimensions can result in graphs with complex dependencies. We provide examples of capturing advanced, arbitrary algorithms in the evaluation."
For instance, the four-NPU recursive halving-doubling AllReduce encoded in Fig. 5(b) of the paper has parallel branches (concurrent sends to multiple partners per step) which manifest as a per-NPU DAG with branch-and-merge structure rather than a single line.
8. The Compute-Communicate Overlap Lift (Section "Fine-Grained Compute-Communicate Overlap")
The strongest expressive-power argument in the paper is in the
"Example: Fine-Grained Compute-Communicate Overlap" section. Wang et al.
[18] (cited) showed an optimization that splits an AllGather into chunks
and overlaps each chunk's compute with the next chunk's
communication. With the previous Chakra ET schema (workload only, opaque
collective node), this optimization could not be expressed because the
AllGather was an indivisible black box — the consumer saw
ALL_GATHER -> MATMUL and had to wait for the entire
AllGather to finish before scheduling the matmul.
BEFORE (workload Chakra ET only, AllGather opaque):
+-------------+
| ALL_GATHER | blocking; full barrier before next op
+------+------+
|
v
+-------------+
| COMP | cannot start until ALL_GATHER fully complete
| MatrixMul |
+-------------+
AFTER (workload + algorithm Chakra ET, AllGather expanded):
+------------+ +------------+ +------------+
| COMM_SEND | ->| COMM_RECV |-->| COMP | chunk 0
+-----+------+ +------------+ | MatMul[c0] |
| +------------+
v
+------------+ +------------+ +------------+
| COMM_SEND | ->| COMM_RECV |-->| COMP | chunk 1
+-----+------+ +------------+ | MatMul[c1] |
| +------------+
v
+------------+ +------------+ +------------+
| COMM_SEND | ->| COMM_RECV |-->| COMP | chunk 2
+------------+ +------------+ | MatMul[c2] |
+------------+
|
v
+------------+
| COMP | final reduce
| MatMul[r] |
+------------+
Each MatMul[ci] depends only on its own chunk's COMM_RECV, not on
COMM_RECVs of later chunks. So MatMul[c0] runs in parallel with
COMM_SEND/RECV of chunks 1 and 2 — fine-grained overlap.
^ Fig 8: The compute-communicate overlap lift. Lifting the algorithm
into the workload graph exposes per-chunk dependency granularity,
which any Chakra-ET-aware scheduler can use to overlap compute
with communication. This is the same fine-grained-dependency
payoff that exposed loop-level parallelism in the move from
basic-block IR to SSA.This example is the paper's strongest capability claim — not just "we can express the same algorithms in a uniform format" but "we can express more algorithms (specifically: workload-collective overlap) than the previous workload-only Chakra ET could express."
For DynamICCL, the implication is profound: if the algorithm is visible at chunk granularity, then the run-time tuner can adapt chunk-by-chunk rather than once per collective call. Today DynamICCL's action is per-collective; tomorrow, with Chakra-ET- expanded graphs, it could be per-chunk.
9. Algorithm / Control Flow — End-to-End Workflow from MSCCLang Source to ASTRA-sim Result
+-------------------------------------------------------------+
| END-TO-END WORKFLOW |
+-------------------------------------------------------------+
(1) USER WRITES ALGORITHM IN MSCCLang DSL
+-------------------------------------------+
| def allreduce_ring(buf): |
| for step in range(N-1): |
| chunk = buf.split(...) |
| send(chunk, peer=next) |
| recv(chunk, peer=prev) |
| chunk.reduce() |
+-------------------------------------------+
|
v
(2) MSCCLang COMPILER LOWERS TO MSCCL-IR XML
+-------------------------------------------+
| <gpu rank="0"> |
| <send peer="1" chunk="..." /> |
| <recv peer="3" chunk="..." /> |
| <reduce ... /> |
| ... |
| </gpu> |
+-------------------------------------------+
|
v
(3) CHAKRA ET CONVERTER (one-time-written tool, Sec. "Representing
MSCCL-IR in Chakra ET")
- Vertex per <send>, <recv>, <reduce>
- Edges from XML's interoperation dependency info
- dst/src IDs from peer attributes
|
v
(4) CHAKRA ET ALGORITHM TRACE (per-NPU DAG collection)
Stored as Protocol Buffers (Chakra schema) on disk.
|
v
(5) ASTRA-sim INPUT
--workload <workload_chakra_et>
--collective_algorithm <algorithm_chakra_et> <- NEW FLAG
|
v
(6) ASTRA-sim Workload Layer issues collective at workload step
|
v
(7) ASTRA-sim System Layer (extended):
if --collective_algorithm passed:
parse algorithm Chakra ET
for each event in algorithm DAG:
issue point-to-point traffic to network simulator
else:
fall back to native ring/HD implementation
|
v
(8) NETWORK SIMULATOR REPORTS LATENCY / BANDWIDTH
|
v
(9) END-TO-END BANDWIDTH (samples in Fig. 8 of paper)
^ Fig 9: End-to-end workflow. The dashed extensions are at steps (5)
and (7) — both are inside ASTRA-sim and both are local
modifications. No workload-format change required; no MSCCLang or
TACOS modification required (their converters are external).The paper explicitly highlights one important property of step (3):
"We highlight that implementing this conversion is a one-time task such that, once developed, can be reused across multiple downstream frameworks."
This is the linchpin of the O(P+C) cost claim. A converter is amortized over every consumer that ever ingests Chakra ET.
The synthesis-then-conversion duration (Table 2 of paper) for MSCCLang AllReduce:
| Number of NPUs | 16 | 32 | 64 | 128 |
|---|---|---|---|---|
| Duration (ms) | 259 | 398 | 1485 | 7662 |
The cost grows superlinearly in NPUs (~2.5x per doubling at small scale, ~5x per doubling at 128 NPUs). For TACOS, the paper notes 1080 ms to synthesize an AllReduce for 128 NPUs (faster than MSCCLang's 7662 ms because the synthesizer is doing different work).
10. Quantitative Results — Empirical Findings by Regime (Tables 2 + Fig. 8)
The paper's quantitative content is intentionally lightweight because the contribution is a representation, not an optimization. Two result categories appear:
10.1 Synthesis-to-Chakra-ET Conversion Time (MSCCLang AllReduce)
+------------------------------------------------------+
| NPUs | 16 | 32 | 64 | 128 | |
| ms | 259 | 398 | 1485 | 7662 | |
+------------------------------------------------------+
Linear regression in log-log space ~= O(NPUs ^ 1.6).
^ Fig 10: Synthesis + conversion time scales as a polynomial in NPUs.
The 128-NPU case (~8 s) is small enough that an offline catalog of
pre-synthesized algorithms remains feasible.10.2 All-Gather Bandwidth on Two Topologies (Fig. 8 of paper)
The headline experiment compares three algorithms (TACOS-synthesized, MSCCLang Ring, MSCCLang Direct) on two topologies (2D Mesh 8x8 = 64 NPUs, 3D Hypercube 4x4x4 = 64 NPUs). Link bandwidth = 50 GB/s, link latency = 500 ns. ASTRA-sim's analytical network simulator drives the measurements.
The reported all-gather effective bandwidth (GB/s) versus chunk size (KB to GB), read off the line plots:
2D Mesh (8x8, 64 NPUs)
Chunk size: 1 KB 16 KB 256 KB 1 MB 1 GB
TACOS: ~5 ~30 ~85 ~98 ~100
MSCCLang Ring: ~3 ~20 ~25 ~25 ~25
MSCCLang Direct: ~1 ~3 ~3 ~3 ~3
3D Hypercube (4x4x4, 64 NPUs)
Chunk size: 1 KB 16 KB 256 KB 1 MB 1 GB
TACOS: ~10 ~50 ~140 ~155 ~160
MSCCLang Ring: ~10 ~30 ~40 ~40 ~40
MSCCLang Direct: ~1 ~3 ~3 ~3 ~3
^ Fig 11: All-Gather collective bandwidth across producers and
topologies. TACOS' topology-aware schedules dominate at large chunk
sizes on both topologies; MSCCLang Ring is competitive at small
chunks but plateaus quickly because it does not exploit higher-
dimensional connectivity. MSCCLang Direct is uniformly weak — it
was likely intended as a baseline.10.3 Three Findings the Quantitative Section Surfaces
- Topology-aware (TACOS) wins big at large messages. TACOS reaches ~160 GB/s on the 3D Hypercube while MSCCLang Ring tops out at ~40 GB/s — a 4x gap. This is the expected finding: ring underuses higher-radix topologies.
- Topology-aware win is also present on the 2D Mesh. Even the "ring-friendly" 2D Mesh shows a 4x TACOS advantage at 1 MB+ chunks (~100 GB/s vs ~25 GB/s). The cause: TACOS exploits the mesh's multiple disjoint paths, which a single ring cannot.
- The representation is the enabler. The paper's framing is that because both producers' outputs were homogenized to Chakra ET, the experiment took minimal engineering — no per-producer simulator code, no per-topology re-implementation. Without standardization, the same comparison would have required hand- porting both producers into ASTRA-sim's System Layer.
11. Configuration-Regime Trade-off Tables
11.1 Workload + Algorithm representation: separate vs unified
| Dimension | Separate (status quo) | Unified (Chakra ET) | Winner (DynamICCL) |
|---|---|---|---|
| Producer-consumer integration | O(P*C) converters | O(P+C) converters | Unified |
| Cross-producer comparability | Re-implement per simulator | Plug-and-play | Unified |
| Express compute-comm overlap | No (collective is opaque) | Yes (chunk-level dependencies) | Unified |
| Profiling / attribution | Workload-only granularity | Per-send/recv/reduce granularity | Unified |
| Workload format change required | None (Chakra ET unchanged) | None (only algorithm side) | Tie |
| Tooling maturity (today) | High (MSCCL-IR widespread) | Low (Chakra ET algo extension) | Separate (today) |
| Engineering cost over 5 years | Linear in P*C | Linear in P+C | Unified |
For DynamICCL, prefer Unified. The state vector benefits from chunk-level message-size visibility (Sec. 8), and the action space benefits from a uniform "candidate algorithm" type that need not be parsed differently per producer. DynamICCL today consumes only NCCL's internal knob settings; if it later consumes pre-synthesized algorithms, those should arrive in Chakra ET.
11.2 Algorithm-DAG granularity: coarse (collective node) vs fine (send/recv/comp)
| Dimension | Coarse (ALL_REDUCE node) | Fine (sends + recvs + comps) | Winner (DynamICCL) |
|---|---|---|---|
| Workload-graph size (DAG nodes) | Small | Larger by O(N x steps) | Coarse |
| Expressivity (overlap, custom algos) | Limited | Full | Fine |
| Simulator dispatch cost | Cheap (one event) | Expensive (many events) | Coarse |
| Profiler / attribution granularity | Whole-collective only | Per-chunk timeline | Fine |
| RL state-feature richness | Algorithm name + size | + chunk_size, + step_index, + | Fine |
| per-chunk receive timestamps | |||
| Engineering complexity for runtime | Low | Higher (must execute event-by- | Coarse |
| event) |
For DynamICCL, prefer Fine for state-feature derivation,
Coarse for dispatch. The state vector should be built from
fine-grained profiling traces (where chunk-level latency is visible),
but the action space should remain coarse — DynamICCL does not need to
pick sends individually, just
(algorithm, protocol, nChannels, numThreads, chunkSize)
tuples that determine the coarse algorithm.
11.3 Producer-consumer composition: build vs adopt
| Dimension | Build new IR (TACOS' TEN) | Adopt Chakra ET | Winner (DynamICCL) |
|---|---|---|---|
| Schema design effort | High (years) | Zero (reuse MLCommons) | Adopt |
| Tooling ecosystem (Protobuf libs) | None initially | Mature (Python/C++ already) | Adopt |
| Producer lock-in risk | High (each tool diverges) | Low (community-controlled) | Adopt |
| Custom-feature flexibility | High (any schema) | Bounded (must extend Chakra) | Build |
| Consumer adoption velocity | Slow (one consumer/year) | Fast (Chakra-ready consumers) | Adopt |
| Expressivity for algorithm IR | Tailored | Generic (3 node types only) | Build |
For DynamICCL, prefer Adopt. The DynamICCL benchmark harness should consume Chakra ET workload traces and Chakra ET algorithm catalogs — there is no value in inventing yet another IR for an RL selector that only needs to recognize candidate algorithms, not describe them.
11.4 Standard-format adoption strategy: top-down vs bottom-up
| Dimension | Top-down (committee writes new spec) | Bottom-up (adopt MLCommons Chakra ET) | Winner (DynamICCL) |
|---|---|---|---|
| Time to first working consumer | Years | Months | Bottom-up |
| Buy-in from existing producers | Low (must abandon their IR) | Medium (must add converter) | Bottom-up |
| Coherent design | High (designed end-to-end) | Risk of misfit (ET was workload-only) | Top-down |
| Long-term flexibility | High | Bounded by Chakra ET evolution | Top-down |
| Visible incremental wins | Few (until full adoption) | Many (each new converter helps) | Bottom-up |
For DynamICCL, prefer Bottom-up. The paper itself adopts this strategy and demonstrates the win in a few-month proof of concept. DynamICCL should plug into whatever the dominant CCL representation becomes — chasing a top-down "DynamICCL IR" would isolate the project.
12. Bottlenecks & Insights Surfaced by the Measurements
12.1 The synthesizer-to-conversion path is a one-time cost
The 7.6 s conversion time at 128 NPUs (Table 2) is amortized: every downstream consumer reads the same Chakra ET file, so the cost disappears in the steady state. This is a textbook build-once, run-many economy and matches the LLVM/Bitcode pattern (one frontend emits IR, many backends read it).
12.2 Topology-aware schedules need topology-aware language
The 4x advantage of TACOS over MSCCLang Ring on the 2D Mesh (Fig. 8) shows that even when both speak Chakra ET, the content of the algorithm DAG matters more than the schema. The schema does not synthesize good algorithms — it only carries them. This is the representational humility the paper repeatedly enforces:
"Note that our proposition is focused on standardizing representations. Tasks such as design space exploration for efficient collective algorithms or parallelization strategy are left to other works."
12.3 The compute-communicate overlap is the killer feature
The strongest capability result, not the strongest performance result, is the fine-grained overlap example (Fig. 4 in paper, Fig. 8 here). Workload-only Chakra ET cannot express this; workload+algorithm Chakra ET can. This single example justifies the entire representation extension because it crosses a expressivity boundary no amount of benchmarking would have discovered.
12.4 The schema reuses three primitives only
Table 1 of the paper lists exactly three new node types —
COMM_SEND, COMM_RECV, COMP. No
more. This is the paper's biggest design choice: refuse to grow the
schema. Any collective is reducible to the three. This is the same
minimalism as MPI's two-sided primitives or the UNIX paper's
read/write/open/close — small primitive set, large expressive power.
12.5 The implicit cross-NPU dependency join is the crux
Each per-NPU DAG is locally acyclic. The global topology is recovered
only by matching dst_id on send to src_id on
recv. This implicit join is invisible in any single DAG, which means
tools that read only one NPU's DAG (e.g., a single-rank profiler) cannot
see the global schedule — they see a local time series. The paper does
not call this out as a limitation, but it is a real one for distributed
debugging.
12.6 Workload Layer reuse is what makes the extension cheap
Section "Updating ASTRA-sim to Run Collective Algorithms in Chakra ET" makes the cost minimization explicit:
"ASTRA-sim readily supports the execution of ML workloads in Chakra ET, reusing the components in the workload layer has made it easy to extend for the common collective algorithm representations."
The same parser, the same DAG walker, the same dependency resolver — just pointed at the new algorithm-graph file. This is the reuse-as-cost-reducer pattern that justifies the schema choice.
13. Limitations of the Methodology
| Limitation | Implication for downstream consumers / DynamICCL |
|---|---|
| Only two producers extended (MSCCLang, TACOS) | TACCL, SCCL, GC3, TE-CCL, SyCCL converters not yet written |
| Only one consumer extended end-to-end (ASTRA-sim) | MSCCL-Runtime extension is argued, not implemented |
| Evaluation uses 64-NPU regimes only (2D Mesh, 3D HC) | No data on 256+ NPU scales where most current production sits |
| Synthetic workload (single AllGather) | No multi-collective workload, no mixed compute-communication scenario |
| Analytical network simulator | Real-network effects (congestion, RDMA, NVLink contention) not modeled |
| Schema introduces only 3 node types | Some advanced features (collective overlap with reduce trees) may need |
| schema extensions later | |
| No comparison vs MSCCL-IR XML directly | Cannot quantify the cost of switching schemas (parser performance) |
| Cross-NPU dependency join is implicit | Tools that read partial graphs (one rank only) cannot reconstruct |
| global schedule | |
| No streaming / online generation discussed | All graphs are offline files; runtime-generated graphs not addressed |
| Chakra ET schema versioning not addressed | Schema evolution (new fields, deprecations) is left to MLCommons |
| Real-runtime support only argued, not benchmarked | The MSCCL-Runtime path is a paper-promise, not a measured artifact |
| No security/sandbox concerns for arbitrary algorithms | A malicious Chakra ET could request 10^9 sends; no validator described |
The most consequential limitation for DynamICCL is that the
paper does not address per-call telemetry. Chakra ET is a
description of what should happen, not a record of what did
happen. DynamICCL's reward signal
(-collective_wall_clock_us) is a record-of-what- happened
quantity, which today comes from NCCL profiling APIs. The representation
contribution is upstream of the reward; it does not deliver the timing
data DynamICCL needs.
A second limitation: the paper assumes algorithm DAGs are static — fixed at synthesis or compile time. DynamICCL's selection is dynamic — per-call. So Chakra ET as a candidate-catalog format is a clean fit, but Chakra ET as an online DAG that gets rewritten by an RL agent is not part of the paper's vision.
14. What to Borrow for DynamICCL — Composability vs Tension
This paper is not a synthesizer, not a runtime, and not a benchmark. It is a representation contribution. So "what to borrow" splits into two parts: what DynamICCL should consume, and where the representation creates tension with DynamICCL's online tuning role.
14.1 What DynamICCL should consume from Chakra ET
+----------------------------------------------------------------+
| DynamICCL's input formats SHOULD be: |
| |
| Workload Chakra ET ---> derive state features: |
| - msg_size_bin (per collective node's Comm_size) |
| - is_pipelined_layer (does the workload DAG show |
| compute and communication overlapped?) |
| - is_fused_call (was the collective preceded by a tensor |
| merge?) |
| - model_intensity_I (compute_node_count / comm_total_size)|
| |
| Algorithm Chakra ET ---> candidate action priors: |
| - algorithm_kind (ring vs HD vs topology-aware) |
| - max_concurrent_sends (graph branch factor) |
| - chunk_count (number of COMM_SEND per collective) |
| - cross-rank dependency depth (longest send/recv chain) |
| |
| DynamICCL's output should NOT modify Chakra ET — it just |
| picks which algorithm DAG to dispatch and which NCCL knobs to |
| set when dispatching it. |
+----------------------------------------------------------------+
^ Fig 12: DynamICCL's I/O contract with Chakra ET. Read both
workload and algorithm graphs as state; emit a tuple (algorithm
selection, NCCL knobs); never write back to the graph. This
preserves Chakra ET's role as the static catalog and DynamICCL's
role as the dynamic dispatcher.14.2 State-vector features the paper validates as derivable
The paper does not say "these are state features for an RL agent", but the schema makes them mechanically extractable:
| Feature | Source in Chakra ET | Why it matters for DynamICCL |
|---|---|---|
msg_size_bin |
Comm_size field on COMM_COLL_NODE |
Already in DynamICCL state |
algorithm_id |
Hash of algorithm Chakra ET DAG | Action-space discretization |
chunk_count |
Count of COMM_SEND nodes in algorithm DAG |
Maps to nChannels x chunkSize jointly |
dag_branch_factor |
Max out-degree of any algorithm-DAG node | Predicts congestion potential |
compute_to_comm_ratio |
Sum of COMP weights / sum of COMM_SEND sizes | Direct C2C ratio, c.f. paper 0030 |
is_overlap_capable |
Chunk-level dependency present in workload DAG? | Routing decision: pick LL vs Simple proto |
14.3 Where Chakra ET composes with DynamICCL
Composition view:
Workload Chakra ET ---+
|
v
+------------------------------------------+
| DynamICCL state encoder |
| - LSTM over recent collectives |
| - feature extractor over ET nodes |
+------------------+-----------------------+
|
v
+------------------------------------------+ reads catalog of
| DynamICCL policy network | algorithm Chakra ETs
| pi(action | state) |<--+ (pre-synthesized
+------------------+-----------------------+ | by SCCL/TACCL/TACOS)
| |
v |
action = (algorithm_id, protocol, nChannels, |
numThreads, chunkSize) |
| |
v |
NCCL/MSCCL-Runtime executes action: looks up |
algorithm Chakra ET by algorithm_id, runs it |
with the chosen protocol/channel/thread/chunk |
| |
v |
-collective_wall_clock_us ---> reward |
^ Fig 13: Chakra ET sits cleanly *below* DynamICCL — it is the
catalog format, not the policy. DynamICCL's RL machinery is
unchanged; it just sees richer state and a more uniform action
space because the catalog is uniformly typed.The composition is clean because:
- Chakra ET is static; DynamICCL is dynamic. They operate on disjoint timescales (synthesis once, selection per-call).
- Chakra ET is an offline IR; DynamICCL outputs runtime knobs. They share no state machinery.
- Chakra ET expresses what the algorithm does; DynamICCL chooses among algorithms. Information flows one way.
14.4 Where Chakra ET tensions with DynamICCL
There are three real frictions worth naming.
Tension A — DynamICCL's actions are not in the schema. NCCL knobs (algo, proto, nChannels, numThreads, chunkSize) do not appear anywhere in Chakra ET. The schema captures the algorithm but not the implementation parameters of the algorithm. So DynamICCL's action space remains opaque to any Chakra-ET-only tool. This is fine in practice (tools that care about NCCL knobs read NCCL config), but it means a Chakra-ET-aware profiler cannot attribute latency to chunkSize choice without external metadata.
What's IN Chakra ET: What's NOT in Chakra ET:
+---------------------+ +-----------------------+
| algorithm name | | NCCL algo (ring/tree) |
| per-NPU DAG | | NCCL proto (LL/Simple)|
| send/recv/comp | | nChannels |
| chunk size | | numThreads |
| comm size | | chunkSize (NCCL knob) |
| dst/src IDs | | RDMA / NVLink choice |
+---------------------+ +-----------------------+
^ Fig 14: The schema gap. DynamICCL's action space lives in the
right column. A Chakra-ET-only tool sees the left column. The
fields are complementary — neither subsumes the other.Tension B — Per-call adaptation is invisible to a static catalog. DynamICCL changes its choice each collective call based on recent state. A static catalog of pre-synthesized Chakra ETs cannot reflect this — the catalog is fixed. So DynamICCL's contribution lies between the catalog and the runtime, in a layer Chakra ET does not describe. This is fine architecturally — it is exactly the layering the paper endorses ("downstream tools must decide the algorithm"; DynamICCL is the decider) — but it means the paper's standardization does not extend to DynamICCL's interface.
Tension C — The schema's compute-comm overlap visibility creates opportunity, not obligation. Section 8 above shows that fine-grained overlap is now expressible. DynamICCL today does not exploit chunk-level state because NCCL does not expose chunk-level telemetry. If a future DynamICCL+Chakra-ET stack exposes per-chunk timestamps, the action space could grow from per-collective to per-chunk, but this is a research project on its own. Today, the overlap visibility is unused capability.
14.5 Empirical findings that constrain DynamICCL's policy prior
The paper provides one concrete prior worth encoding:
PRIOR: Topology-aware algorithms dominate ring at large messages
on multi-dimensional topologies (Fig. 8).
If state.topology in {2D-mesh, 3D-hypercube, fat-tree-multi-rail}
and state.msg_size > 256 KB:
initial_action_distribution favors topology-aware
algorithm IDs (e.g., TACOS-synthesized) over ring.
If state.topology in {single-node-NVLink, simple-PCIe-tree}
and state.msg_size <= 16 KB:
initial_action_distribution favors ring or HD with
LL protocol — startup latency dominates, topology
awareness is wasted.
^ Fig 15: Initial Q-value prior derived from Fig. 8 of the paper.
DynamICCL should not have to discover the 4x topology-aware win
from scratch — the offline characterization done in Chakra-ET-
speaking tools can be precomputed and used to seed the policy.14.6 Reward shaping the paper does not address but enables
The paper's reward target is unchanged
(-collective_wall_clock_us), but the attribution
of reward becomes more granular under Chakra ET. Today DynamICCL gets
one reward per collective. Under Chakra ET, the runtime could emit one
reward per COMM_SEND / COMM_RECV pair,
producing per-chunk reward signals that accelerate
learning by factor of chunk_count. This is a non-trivial
sample-efficiency gain.
14.7 The standardization principle as a long-term architecture lesson
The deepest lesson is not technical but methodological. The CCL ecosystem has accumulated three or four custom IRs (MSCCL-IR XML, TACOS TEN, SyCCL Sketch IR, TE-CCL flow tables) in five years; each is a slight variation on "DAG of point-to-point operations." The paper's argument is that the variation is not earning its keep: the producers all express the same content, the consumers all want the same content, but pairwise integration costs O(P*C). DynamICCL should take the same lesson seriously: when designing its state encoder, action representation, and reward channel, pick existing schemas where possible (NCCL config struct, Chakra ET, profiling timeline formats) rather than inventing new ones. Custom representations are a research liability that compounds over time.
14.8 The "research focuses on layer of interest" closing
The paper closes its argument with this sentence:
"The standardized format enables an abstraction of both the workload and collective algorithms, allowing the research to focus on only their layer of interest."
For DynamICCL, the layer of interest is per-call NCCL knob selection conditioned on (workload state, topology, recent timing). Chakra ET handles the layer below (algorithm catalog) and the layer above (workload DAG). DynamICCL operates squarely between, and gets to ignore both layers' implementation details — which is exactly what the standardization promises.
15. Analogy
The paper is the MIDI standard for collective communication. In the early 1980s every music synthesizer brand spoke its own protocol, so a sequencer that wanted to drive a Yamaha keyboard, a Roland drum machine, and a Korg sampler had to implement three interfaces; and the synthesizer makers, in turn, had to implement an interface for every sequencer. The combinatorial cost was real and well-documented. MIDI did not invent better synthesis algorithms or better sequencers — it standardized the note-on / note-off / control-change message schema that every brand could speak. Almost overnight, sequencers became plug-and-play across hardware.
The mapping to this paper is precise. MSCCLang, TACCL, TACOS, SyCCL, TE-CCL are the synthesizers — different brands, different internal implementations. ASTRA-sim, MSCCL-Runtime, profilers, debuggers are the sequencers — different brands, different internal implementations. The pre-Chakra-ET state of CCL is the pre-MIDI state of synthesizers: O(P*C) integration cost, no plug-and-play, research energy spent on glue code. Chakra ET's three primitives — COMM_SEND, COMM_RECV, COMP — are MIDI's note-on / note-off / control- change. Small, sufficient, and standardized.
DynamICCL extends the analogy one step further. If Chakra ET is MIDI, then DynamICCL is the live performer — choosing in real time which patch (algorithm) to play, with which articulation (protocol, nChannels, numThreads, chunkSize), based on the current musical context (workload state, topology, recent timing). The performer can only operate well if the patch library is uniformly indexed (one schema per patch) and the controllers are uniformly exposed (NCCL knob struct). The paper standardizes the patch library; DynamICCL is the artist who exploits the resulting plug-and-play to play the right patch at the right moment. The patch library does not constrain the artistry; it enables it.
The paper's silence on per-call adaptation is exactly the design space DynamICCL fills. A standardized representation of what algorithms exist is necessary but not sufficient for a system that must decide which algorithm to dispatch right now. DynamICCL is that decider, and the better the catalog of algorithms it draws from, the better its decisions can be.
Summary of Borrowed Patterns
| Pattern from Yoo et al. (Hot Interconnects 31, 2025) | DynamICCL application |
|---|---|
| O(P+C) integration via shared schema | DynamICCL benchmark harness consumes Chakra ET only — no per-producer parser |
| Workload + algorithm represented in one DAG schema | DynamICCL state encoder reads both graphs through a single feature extractor |
COMM_SEND / COMM_RECV / COMP
as the only primitives |
Action-prior table keyed by algorithm DAG hash; canonicalize via 3 node types |
| Cross-NPU dep via dst_id/src_id implicit join | Profiler must recover global timeline before assigning reward |
| Chunk-level dependency exposes compute-comm overlap (Fig. 4) | Future DynamICCL: per-chunk reward instead of per-collective reward |
| TACOS 4x advantage on multi-dim topologies (Fig. 8) | Topology fingerprint feature must distinguish flat vs multi-dim |
| One-time converter cost amortized over consumers | One Chakra ET parser in DynamICCL covers MSCCLang + TACCL + TACOS + future tools |
| Workload Layer reuse in ASTRA-sim | DynamICCL state extractor reuses ML-Commons Chakra ET protobuf libraries |
| Chakra ET does NOT carry NCCL knobs | DynamICCL must keep NCCL-config metadata as a sidecar, not as Chakra fields |
| Static catalog vs dynamic selection layering | DynamICCL sits between the Chakra ET catalog and the runtime — clean layering |
| Schema evolution governed by MLCommons | DynamICCL adopts Chakra schema as-is; never forks |
| "Research focuses on layer of interest" closing principle | DynamICCL focuses on per-call selection; ignores synthesis and execution |
| Three node types as minimal sufficient set | DynamICCL action vocabulary kept similarly small: 5 knobs, no schema growth |
| Composition by placeholder substitution (workload calls algo) | DynamICCL is a placeholder substituter at run time, just one layer below ASTRA |
| MIDI-style standardization analogy | DynamICCL is the live performer; Chakra ET is the patch library schema |