The 2026-08-17 four-engine sweep leaves four rows where Perry is meaningfully behind Node and no issue owns them. interp/iso_miss are #8202 and fib40 is #8175; these are the remainder.
| benchmark |
Perry |
Node |
P/Node |
Perry instr |
Node instr |
pipeline |
0.2043 |
0.0950 |
2.15× |
3.893 B |
1.220 B |
churn |
0.3300 |
0.1666 |
1.98× |
5.006 B |
2.681 B |
tree_wide |
1.2965 |
0.9015 |
1.44× |
26.808 B |
20.262 B |
cycles |
0.1035 |
0.0736 |
1.41× |
2.132 B |
0.669 B |
All four are instruction-bound rather than scheduling-bound — Perry executes 1.3–3.2× the instructions Node does — so the work is to emit less, not to schedule better.
Notes per row, from the sweep:
Not a regression report — all four improved or held since 08-15 (tree_wide −24.8%, cycles +1.4%, pipeline +2.0%, churn +8.2% from #8288). Filed so the remaining engine gap is tracked rather than implicit, now that the campaign has cleared the catastrophic rows.
Suggested order: #8288 first (it contaminates churn), then cycles as the cheapest probe into where the extra instructions come from, then pipeline.
Sweep evidence: gc-handoff/current-sweep-2026-08-17/ (RESULTS.md, results-clean.json, report.html).
The 2026-08-17 four-engine sweep leaves four rows where Perry is meaningfully behind Node and no issue owns them.
interp/iso_missare #8202 andfib40is #8175; these are the remainder.pipelinechurntree_widecyclesAll four are instruction-bound rather than scheduling-bound — Perry executes 1.3–3.2× the instructions Node does — so the work is to emit less, not to schedule better.
Notes per row, from the sweep:
pipelineis the worst uncovered gap. It was 3.3585 s at 08-14 and 0.2002 s at 08-15, so the catastrophic phase is long fixed (perf: pipeline's +3.95% at #8084 is unattributed — it is NOT the callee rooting (IR is byte-identical) #8243 closed); this is the steady-state residue. Perry beats scriptc here 0.2043 vs 0.4461, and Porffor cannot run it at all, so the gap is specifically against V8.churnalso carries the perf(gc): #8277's object-start bitmap costs 8-10% wall on allocation-heavy workloads #8288 allocation-bitmap regression (+8.2% since 08-15). Fixing perf(gc): #8277's object-start bitmap costs 8-10% wall on allocation-heavy workloads #8288 should be sequenced first, then this re-measured — the two are additive and it would be easy to double-count.cycleshas the largest instruction ratio of the four at 3.19× Node for 1.41× wall, which suggests the emitted work is cheap per instruction. Possibly the most tractable.tree_wideis the mildest ratio but the largest absolute time in the corpus at 1.30 s.Not a regression report — all four improved or held since 08-15 (
tree_wide−24.8%,cycles+1.4%,pipeline+2.0%,churn+8.2% from #8288). Filed so the remaining engine gap is tracked rather than implicit, now that the campaign has cleared the catastrophic rows.Suggested order: #8288 first (it contaminates
churn), thencyclesas the cheapest probe into where the extra instructions come from, thenpipeline.Sweep evidence:
gc-handoff/current-sweep-2026-08-17/(RESULTS.md,results-clean.json,report.html).