Repository navigation
Docs: disambiguate "overlap" in the dual-domain L3 examples - #1605
Conversation
|
Important Review skippedAuto incremental reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
📝 WalkthroughWalkthroughDocumentation updates clarify inspection passes, overlapping domain membership, synchronous execution, domain lifetimes, per-domain outputs, and collective peer grouping in the L3 examples. ChangesL3 domain overlap documentation
Estimated code review effort: 1 (Trivial) | ~5 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@examples/workers/l3/dual_domain_overlap/main.py`:
- Around line 10-20: Update the module docstring to describe chip 1 as belonging
to both communication domains and receiving an independent ChipDomainContext in
each separate synchronous run. Remove wording such as “at once” and “holds two
independent” that implies simultaneous context liveness, while preserving the
membership and rank details.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 2ff9c9e1-cc96-4936-abba-02ae02a2f66b
📒 Files selected for processing (3)
examples/workers/l3/domain_rank_map/README.mdexamples/workers/l3/dual_domain_overlap/README.mdexamples/workers/l3/dual_domain_overlap/main.py
737c9f1 to
938d21c
Compare
`dual_domain_overlap` overlaps in domain *membership* — chip 1 belongs to both domains — but its module docstring said only "with overlapping domains", which reads equally as temporal overlap. Nothing stated the three-run execution shape, so a reader had to derive the concurrency from `Worker.run()` being `submit().wait()`. Two claims were also wrong: - `dual_domain_overlap`'s README credited the reduce-to-affine ordering to TensorMap's implicit same-`buffer.addr` edge. Those stages are in separate synchronous runs, so the run boundary orders them and that edge carries no weight here; the per-domain isolation comes from `reduce_out` / `affine_out` being keyed by (domain, chip). `ffn_tp_parallel` is the example where the implicit edge is load-bearing, and is now linked as such. - `domain_rank_map`'s README pointed at `dual_domain_overlap` as "the case where both domains are live across the same DAG". It is not — it gives each domain its own run too. Both domains are live at once only in `domain_rank_map`'s own inspection pass, which runs no collective. Adds an "Execution shape" section covering the three runs, the domain lifetime rule (`release()` is a non-blocking mark; the backend release lands after the run's completion wait), and why the allreduce must be grouped. Wording throughout avoids implying the two `ChipDomainContext` objects are simultaneously live: chip 1 belongs to both domains and receives a context in each domain's own reduction run, so the contexts are never concurrent. Doc-only; no behavior change. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…nges (#1607) PR #1605 changed three files, all under `examples/workers/l3/` — two READMEs and one `main.py`. The category axis correctly skipped `ut`, `ut-a2a3` and `ut-a5`, but `packaging-matrix` (both legs, ~9 min each) and `profiling-flags-smoke` (~11 min) still ran. Neither could have been affected. Those two jobs are the only ones that build and install the product and then exercise it with a fixed, tiny payload rather than reading a test suite as a corpus: `packaging-matrix` runs `tools/verify_packaging.sh`, which checks the import surface and one entry-point script, and `profiling-flags-smoke` rebuilds the runtimes under six `CXX` define permutations and runs one `vector_example`. Nothing under `examples/` reaches either — it is absent from `wheel.packages` and from the sdist `include`, and neither job opens it. So they take a fourth flag, `examples_only`, written in the same shape as the arch and category axes with `NON_CODE` subtracted first. `profiling-flags-smoke` moves off `st_affected`, which was never the right question for it: its inputs are `src/` and the build system, not the scene-test corpus. `tests/` deliberately stays in. `verify_packaging.sh` runs `tests/st/a2a3/.../paged_attention_unroll/test_paged_attention_unroll.py --help` as its entry-point smoke, and `tests/` is in the sdist `include` (`pyproject.toml:64`, with `tests/st` excluded from the wheel only). Only `examples/` is provably absent from both jobs, so only `examples/` is subtracted. One consequence worth naming: a change confined to `examples/{arch}/.../vector_example/` now skips the profiling smoke. That is acceptable because `st-sim-*` and `st-onboard-*` run `vector_example` on both sim and hardware anyway; the smoke's unique coverage is the six build-flag permutations, which no example can affect. Simulated against nine file lists. Newly skipping: #1605's diff, an `examples/a2a3` kernel, docs-only. Still running: `tests/st/`, `tests/ut/`, `src/common/`, `simpler_setup/build_runtimes.py`, `pyproject.toml`, and any diff mixing `examples/` with `src/`. `docs/ci.md` and `.claude/rules/ci-change-detection.md` move with it, including the paragraph that argued `packaging-matrix` was "not worth a fourth condition" — #1605 is the counterexample.
Summary
dual_domain_overlapoverlaps in domain membership — chip 1 belongs toboth domains — but its module docstring said only "with overlapping domains",
which reads equally as temporal overlap. Combined with the directory name,
that is a real trap: it led a reviewer to conclude the example demonstrates
concurrent/pipelined execution and to propose changes on that basis.
Two claims were also factually wrong:
dual_domain_overlap's README credited the reduce→affine ordering toTensorMap's implicit same-
buffer.addredge. Those stages sit in separatesynchronous
worker.runcalls, so the run boundary orders them and thatedge carries no weight here. The per-domain isolation actually comes from
reduce_out/affine_outbeing keyed by(domain, chip).ffn_tp_parallelis the example where the implicit edge is load-bearing,and is now linked as such.
domain_rank_map's README pointed atdual_domain_overlapas "the casewhere both domains are live across the same DAG". It is not — it gives each
domain its own run too. Both domains are live simultaneously only in
domain_rank_map's own inspection pass, which runs no collective.Changes:
dual_domain_overlapmodule docstring: state that the overlapis structural rather than temporal, and name the actual sharp edge (chip 1
writing a distinct result per domain).
synchronous runs, the domain lifetime rule (
release()onwithexit is anon-blocking mark; the backend release lands after the run's completion
wait), and why the allreduce must be submitted as a group.
Doc-only; no behavior change.
Testing
ast.parseonmain.py; docstring content verified (it is user-visiblevia
argparse(description=__doc__)withRawDescriptionHelpFormatter)#execution-shapeanchor checkedFollow-up from the review of #1565.