Conversation
acl-cqc
changed the title
Contributor
|
Bencher Report| Project | guppylang |
| Branch | acl/adaptor_blocks |
| Testbed | Linux |
Click to view all benchmark results
| Benchmark | hugr_bytes | Benchmark Result bytes x 1e3 (Result Δ%) | Upper Boundary bytes x 1e3 (Limit %) | hugr_nodes | Benchmark Result nodes (Result Δ%) | Upper Boundary nodes (Limit %) |
|---|---|---|---|---|---|---|
| tests/benchmarks/test_big_array.py::test_big_array_compile | 📈 view plot 🚷 view threshold | 60.29 x 1e3(-2.92%)Baseline: 62.10 x 1e3 | 62.72 x 1e3 (96.12%) | 📈 view plot 🚷 view threshold | 4,514.00(-1.55%)Baseline: 4,585.00 | 4,630.85 (97.48%) |
| tests/benchmarks/test_ctrl_flow.py::test_many_ctrl_flow_compile | 📈 view plot 🚷 view threshold | 26.41 x 1e3(-4.85%)Baseline: 27.76 x 1e3 | 28.03 x 1e3 (94.20%) | 📈 view plot 🚷 view threshold | 1,182.00(-9.15%)Baseline: 1,301.00 | 1,314.01 (89.95%) |
| tests/benchmarks/test_queue_push_pop.py::test_queue_push_benchmark_compile | 📈 view plot 🚷 view threshold | 6.97 x 1e3(-3.81%)Baseline: 7.24 x 1e3 | 7.32 x 1e3 (95.24%) | 📈 view plot 🚷 view threshold | 286.00(-7.74%)Baseline: 310.00 | 313.10 (91.34%) |
| tests/benchmarks/test_queue_push_pop.py::test_queue_push_pop_benchmark_compile | 📈 view plot 🚷 view threshold | 9.29 x 1e3(-5.79%)Baseline: 9.86 x 1e3 | 9.96 x 1e3 (93.28%) | 📈 view plot 🚷 view threshold | 378.00(-8.03%)Baseline: 411.00 | 415.11 (91.06%) |
acl-cqc
commented
Sep 9, 2026
| p.id: p for row in bb.sig.output_rows for p in row | ||
| } | ||
| outputs = sort_vars(list(var_map.values())) | ||
| # Can we use 'Dom` edges for droppable outputs? I think no - each output is |
Contributor
Author
There was a problem hiding this comment.
I mean possibly we could but it would be kinda orthogonal to this
acl-cqc
commented
Sep 9, 2026
| # used by some BB as an actual input, so we must pass them as explicit outputs. | ||
| for i, r in enumerate(bb.sig.output_rows): | ||
| if len(r) == len(var_map): | ||
| assert {p.id for p in r} == {p.id for p in var_map.values()} |
Contributor
Author
There was a problem hiding this comment.
Maybe drop this? the len check seems like it should be both cheap and precise
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2311 +/- ##
==========================================
- Coverage 93.37% 93.34% -0.03%
==========================================
Files 165 165
Lines 16202 16202
==========================================
- Hits 15128 15124 -4
- Misses 1074 1078 +4 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
3 tasks
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
2 participants
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.
Not sure whether this is refactor (I mean it changes the Hugr), perf (effect on performance unclear) or feat (it changes the Hugr to reduce the amount of weird stuff??)....
But, presently, when a block in a CFG has successors that need different subsets of the outputs, we build a big SumType abstracting over the differences (actually just over all the nonlinear outputs, not just those ones that are different), to use as the branch predicate; and the predecessor block gains a Conditional which takes all of the nonlinear outputs and then builds one or other variant of that SumType with only the desired values.
Instead, insert "adaptor blocks" inbetween the predecessor and each successor which uses only some of the predecessor's outputs. Successors using all the outputs need no adaptor (when all successors use all the outputs, this was previously special-cased to avoid the Conditional, but this now falls out naturally / generally).
The nasty bit is we have to pass the adaptors up out of
compile_bbso we can route the edges correctly incompile_cfg, but even that is just an extra return value, did not need to add anything to e.g.class BB.