Repository navigation
fix(latency): a processor-boundary crossing is decided by the processor each binding resolves to, not by its text (#498) - #505
Merged
Conversation
Rivet verification gate✅ 20/20 passed
Filter: Failed artifacts(none) Updated automatically by |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
…or each binding resolves to, not by its text (#498) Latency compared the Actual_Processor_Binding TEXT of consecutive flow steps, both in the latency walk (where a crossing adds Inter_Processor_Overhead) and in the "crosses processor boundaries" note. On the published v0.46.0 binary, a flow whose `t1` is bound by Node.impl to `cpu` and whose `t2` is bound by Top.impl to `left.cpu` (one processor) is a "crossing": - the note fires: "end-to-end flow 'e' crosses processor boundaries but no ... communication delay"; - with 5 ms of Inter_Processor_Overhead on the owner, the latency is [2 .. 9] ms instead of [2 .. 4] ms. Both sites now key on ProcessorGroups (from #500): the processor the binding resolves to from its declarer, or the text when it does not resolve. Oracles: - CLI tests: the note (red on v0.46.0), the overhead figure (red on v0.46.0), and a negative control where t2 really is on another processor and the crossing is still reported; - full-output corpus diff, v0.46.0 vs this build: 217 binding files, 462 runs, 451 instantiating, identical on every run; - mutants: cargo-mutants 1 caught, 1 unviable. The walk's key reverted to the raw text SURVIVED until the overhead test was written, and is now caught. rivet: REQ-AADL-BINDING-CONSUMERS-001's progress text is not edited here, because #503 edits the same text; it is updated after both land. Refs #498 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BnBWxgVEUPdsBTLNKtrA6Z
avrabe
force-pushed
the
fix/binding-consumers-latency
branch
from
October 21, 2026 00:50
0dd9d50 to
6a16116
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Latency compared the Actual_Processor_Binding TEXT of consecutive flow
steps, both in the latency walk (where a crossing adds
Inter_Processor_Overhead) and in the "crosses processor boundaries"
note. On the published v0.46.0 binary, a flow whose
t1is bound byNode.impl to
cpuand whoset2is bound by Top.impl toleft.cpu(one processor) is a "crossing":
no ... communication delay";
[2 .. 9] ms instead of [2 .. 4] ms.
Both sites now key on ProcessorGroups (from #500): the processor the
binding resolves to from its declarer, or the text when it does not
resolve.
Oracles:
v0.46.0), and a negative control where t2 really is on another
processor and the crossing is still reported;
462 runs, 451 instantiating, identical on every run;
the raw text SURVIVED until the overhead test was written, and is now
caught.
rivet: REQ-AADL-BINDING-CONSUMERS-001's progress text is not edited
here, because #503 edits the same text; it is updated after both land.
Refs #498
🤖 Generated with Claude Code
https://claude.ai/code/session_01BnBWxgVEUPdsBTLNKtrA6Z