Skip to content

Docs: disambiguate "overlap" in the dual-domain L3 examples - #1605

Merged
ChaoWao merged 1 commit into
hw-native-sys:mainfrom
ChaoWao:docs/clarify-dual-domain-overlap
Jul 31, 2026
Merged

ChaoWao merged 1 commit into
hw-native-sys:mainfrom
ChaoWao:docs/clarify-dual-domain-overlap

Conversation

@ChaoWao

@ChaoWao ChaoWao commented Jul 31, 2026

Copy link
Copy Markdown
Collaborator

Summary

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. 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 to
    TensorMap's implicit same-buffer.addr edge. Those stages sit in separate
    synchronous worker.run calls, so the run boundary orders them and that
    edge carries no weight here. The per-domain isolation actually 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 simultaneously only in
    domain_rank_map's own inspection pass, which runs no collective.

Changes:

  • Rewrite the dual_domain_overlap module docstring: state that the overlap
    is structural rather than temporal, and name the actual sharp edge (chip 1
    writing a distinct result per domain).
  • Add an Execution shape section to the README covering the three
    synchronous runs, the domain lifetime rule (release() on with exit is a
    non-blocking mark; the backend release lands after the run's completion
    wait), and why the allreduce must be submitted as a group.
  • Correct the two claims above.

Doc-only; no behavior change.

Testing

  • ast.parse on main.py; docstring content verified (it is user-visible
    via argparse(description=__doc__) with RawDescriptionHelpFormatter)
  • README heading structure and the #execution-shape anchor checked
  • Simulation tests pass — not run; no code changed
  • Hardware tests pass — not applicable

Follow-up from the review of #1565.

@coderabbitai

coderabbitai Bot commented Jul 31, 2026 •

Copy link
Copy Markdown

Review Change Stack

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 6ad6a631-28e9-4983-8a32-f46d2da833e0

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review
📝 Walkthrough

Walkthrough

Documentation updates clarify inspection passes, overlapping domain membership, synchronous execution, domain lifetimes, per-domain outputs, and collective peer grouping in the L3 examples.

Changes

L3 domain overlap documentation

Layer / File(s) Summary
Domain overlap execution documentation
examples/workers/l3/domain_rank_map/README.md, examples/workers/l3/dual_domain_overlap/README.md, examples/workers/l3/dual_domain_overlap/main.py
Documents non-collective inspection, overlapping membership with separate contexts and outputs, three synchronous runs, domain release timing, and allreduce and affine-stage grouping.

Estimated code review effort: 1 (Trivial) | ~5 minutes

Poem

A rabbit hops through domains two,
With notes on what the workers do.
No concurrent race, just steps in line,
Separate results neatly align.
Peer groups gather, then bunnies cheer!

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and concisely describes the documentation change clarifying that “overlap” refers to domain membership.
Description check ✅ Passed The description directly explains the documentation clarifications, factual corrections, and testing performed for the changeset.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

📥 Commits

Reviewing files that changed from the base of the PR and between 14f44a7 and 737c9f1.

📒 Files selected for processing (3)
  • examples/workers/l3/domain_rank_map/README.md
  • examples/workers/l3/dual_domain_overlap/README.md
  • examples/workers/l3/dual_domain_overlap/main.py

Comment thread examples/workers/l3/dual_domain_overlap/main.py Outdated
@ChaoWao
ChaoWao force-pushed the docs/clarify-dual-domain-overlap branch from 737c9f1 to 938d21c Compare July 31, 2026 01:26
`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>
@ChaoWao
ChaoWao merged commit 0f0fb8b into hw-native-sys:main Jul 31, 2026
17 checks passed
@ChaoWao
ChaoWao deleted the docs/clarify-dual-domain-overlap branch July 31, 2026 01:46
ChaoWao added a commit that referenced this pull request Jul 31, 2026
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant