Repository navigation
spec(t27b): split compile_time_optimizations.t27 into docs + executable rules - #12996
Merged
Merged
Conversation
…2835) Add the continuous improvement loop as .t27 specs: - specs/crons/t27-pareto-improvement-loop.t27: 15-minute tick card, seven steps (audit, pareto, fix, verify, land, beat, self-heal), Pareto floors, rollback window, verdict codes. - specs/acceleration/pareto_weak_points.t27: anomaly kinds, impacts, scores, outranking, top-anomaly pick. - specs/acceleration/competitor_research.t27: competitor records, pass@k/cost comparison, LEAD/PARITY/BEHIND verdict. - specs/acceleration/decomposition_plan.t27: atomic units with Closes #N, per-mille coverage, next-unit pick. - specs/acceleration/auto_fix_self_heal.t27: deterministic fix per failing check kind, rollback decision, keep/watch/rollback verdict. - specs/acceleration/coverage_hundred.t27: effective coverage, per-mille, L1 traceability. - specs/tri/commands/pareto_commands.t27: tri pareto audit|fix|verify| land|beat|self-heal, tri experience save. - specs/skills/t27-pareto-improvement-loop.t27: skill card spec. - .claude/skills/pareto-improvement-loop/SKILL.md: skill body. All logic in .t27; no foreign edits. Every spec carries test/invariant blocks and passes t27c test. L1: Refs #12835.
…rebuild, golden system specs - specs/golden/: THE GOLDEN SERIES two-layer architecture - series.t27: manifest with 8 members (TRIAD + OPERATING SYSTEM) - article3_golden_chain.t27: Article 3 Execution layer - golden_invariant.t27: phi^2 + 1/phi^2 = 3 SHA-256 fingerprint - golden_oracle.t27: bit-for-bit referee - golden_head.t27: canonical local head refs/golden/head - golden_foundry.t27: measured publication practice - golden_spiral.t27: 27-petal visual identity - README.md: rebuilt around GOLDEN CHAIN, Golden Series table, honest status - AGENTS.md: added The Golden Series section - specs/tri/shootout/: tri shootout improve command, bench harness with Zig-style compile-time unrolling, 3 Pareto collaboration options - specs/crons/t27-backend-shootout-improvement-loop.t27: 15m Pareto loop - docs/blog/2026-10-27-t27b-backend-shootout.md: Superiority column, Python/C++/JS measurements, release metadata - docs/blog/*.svg: 4 infographics regenerated - docs/golden-series/, docs/history/, stub docs moved from README - GitHub Epic #12913 created Closes #12913
- specs/tri/shootout/bench.t27: UnrollConfig (200M base, 1000x factor, 200B target), UNROLLED_RESULTS with separate 100x/1000x rows (not measured), effective_calls_per_second(), tests for config values and results - docs/blog/2026-10-27-t27b-backend-shootout.md: separate unrolled t27b rows, metaprogramming section in Major Achievements Baseline t27b row kept unchanged (200M calls, 439 ms, 456M Calls/s). Unrolled rows use 'not measured' per no-claim-without-a-receipt rule. φ² + 1/φ² = 3 | TRINITY
- specs/tri/shootout/bench.t27: UNROLLED_RESULTS with measured 100x/1000x manual unroll, unroll_factor_from_env() and t27b_build_with_unroll() note --unroll unsupported - specs/tri/shootout/bench_fn*.t27: pure functions for baseline/100x/1000x measurement - docs/blog/2026-10-27-t27b-backend-shootout.md: measured unroll rows added Key finding: t27b does NOT support --unroll flag. Manual unroll spec files show 100x = 4.7 ms compile, 1000x = 334 ms compile — manually unrolling calls in one file increases compile time without improving Calls/s. φ² + 1/φ² = 3 | TRINITY
- docs/blog/2026-10-27-t27b-backend-shootout.md: split Calls/s into Runtime Calls/s and Compile Calls/s; remove false claim about --unroll support; add measured unroll receipt table - specs/tri/shootout/improve.t27: update Pareto weaknesses and entry point to reflect measured negative result for manual unroll All numbers now measured; 'not measured' where unmeasured. φ² + 1/φ² = 3 | TRINITY
- bench.t27: UNROLLED_RESULTS now has correct logical_calls (200M for both) and calls_per_sec reflects measured runtime (456M baseline), not bogus compile throughput - improve.t27: Pareto weakness updated to 'Manual unroll does not improve runtime (compiler-level unroll not implemented)'; entry point no longer claims compile-time unrolling - docs/blog: table now uses Runtime Calls/s column; unroll table is separate Compile Calls/s table; removed false claim about --unroll support All numbers are measured; 'not measured' where unmeasured. φ² + 1/φ² = 3 | TRINITY
- bench.t27: UNROLLED_RESULTS now uses calls_in_source (100 and 1000), compile_calls_per_sec (21,276 and 2,994), runtime_calls_per_sec = not measured - No longer inherits baseline 200M / 456M into unrolled rows - Added test: unrolled_results_have_two_rows checks calls_in_source - Added test: unrolled_results_are_not_measured checks runtime not measured φ² + 1/φ² = 3 | TRINITY
- docs/blog/2026-10-27-t27b-backend-shootout.md: replace 're-measures with compile-time unrolling' with 're-measures runtime Calls/s only'; infographics now report compile-time throughput only; Option 1 updated to record manual-unroll negative result and specify compiler-level --unroll as future milestone - specs/tri/shootout/improve.t27: Pareto weakness updated to 'Manual unroll does not improve runtime'; entry point no longer claims unrolling measurement - specs/tri/shootout/option1_gap_remediation.t27: GAP 'metaprogramming unroll measurement missing' → 'manual unroll measurement missing'; step 3 records measured negative result instead of calling unroll_factor_from_env(); removed unused bench import φ² + 1/φ² = 3 | TRINITY
- bench_audit.t27: pure verdict_fn called 200M times in loop - Bench: 656ms runtime for 200M calls = 304M Calls/s baseline - Assembly shows: call per iteration, load/store per iteration, counter management - This is the RED zone - target is <=150ms (2.93x improvement needed) φ² + 1/φ² = 3 | TRINITY
Census of the hot loop of the 200M-call benchmark, read off `t27b asm specs/tri/shootout/bench_audit.t27`: 21 instructions per iteration (0x54..0xa4), 25 per logical call including the 4 executed callee instructions. 1 call, 7 branches, 2 compares, 7 moves, 4 alu, 0 loads, 0 stores, 0 spills; 4 overflow-check branches; 2 loop-invariant moves. The register hypothesis is REFUTED on this workload: the loop already lives entirely in x19..x22, so register allocation is not the largest win. The largest single loss is the 7-instruction clamp chain for the saturating wrap, then the 8-instruction call crossing. Measured: 656 ms, 304.9M Calls/s, 3.28 ns/call, IPC 2.38 at 3.2 GHz. Projection at constant IPC: 21 -> 6 instructions is 187 ms, and 150 ms needs 4.8 instructions of the old cost -- so the Zig rung sits at the edge of the scalar path, not beyond it. NEON stays last and becomes margin, not a precondition. Both files carry the raw disassembly and the arithmetic; a diff against the live binary checks that the receipt still matches. phi^2 + 1/phi^2 = 3 | TRINITY
- ir_importer.t27: import/import_door/refusal_code, safe-subset contract, LLVM IR as first (only) input format covering Rust/Zig/C, 7 tests, 2 invariants, 0 vacuous; seal saved - export_abi.t27: scalar doorway _ea_door/_ea_format_bit at object edge, C caller verified 124 / 9 / 0; object 536 bytes; build 0.01/0.00/0.00 s - cli/t27b/src/codegen.rs staged 103-line inlining diff left out (Epic 2) phi^2 + 1/phi^2 = 3 | TRINITY
… lands) - ir_importer.t27: +milestone1_add_ret_is_refused_until_parser_lands test, 8 tests / 2 invariants green - specs/tri/t27b/conformance/add_ret.ll: one LLVM IR add+ret function, the milestone-1 fixture (LLVM IR first input format) phi^2 + 1/phi^2 = 3 | TRINITY
…M calls) - specs/tri/shootout/bench.t27: valid spec again (was LanguageResult[](8) parse error), 6 tests green, 0 vacuous, L3 ASCII clean - Baseline now measured via t27b build AOT object + C runner: 344.08 ms median, 581M calls/sec, 600 B object, warm cache - 5 run receipts + summary under .trinity/receipts/bench_200m_aot_run*.json - Baseline row NOT replaced by unrolled rows; unrolled rows remain separate phi^2 + 1/phi^2 = 3 | TRINITY
- Replace invalid multiline struct/array syntax with scalar constants and single-line string arrays - All functions return scalar types (u64/str) compatible with gen-zig - 9 tests pass, 0 FAIL, 5 CT-VERIFIED, 0 vacuous - L3 ASCII clean, seal saved to .trinity/seals/t27b_BackendAPI.json phi^2 + 1/phi^2 = 3 | TRINITY
…le rules - Split compile_time_optimizations.t27 into: - docs/tri/t27b/compile_time_optimizations.md (narrative/research) - specs/tri/t27b/compile_time_rules.t27 (executable contract with tests) - compile_time_rules.t27: 9 tests pass, 0 FAIL, 0 vacuous, L3 ASCII clean - Seal saved to .trinity/seals/t27b_CompileTimeRules.json phi^2 + 1/phi^2 = 3 | TRINITY
This was referenced Oct 31, 2026
Merged
Merged
This was referenced Nov 7, 2026
Merged
Merged
gHashTag
added a commit
that referenced
this pull request
Nov 8, 2026
(Closes #13303) (#13305) * specs: restore golden and shootout syntax undone by #12996/#12997 (Closes #13303) The #12997 and #12996 merges took the old side of an add/add conflict and brought back text of 11 specs that no longer parses (`};` after test blocks, `[...];` after const arrays, `str = [` for string arrays). This restores the text each spec held at 28fd63d, which equals 4cfd2f2 for specs/golden and 53cb6e6 for specs/tri/shootout. The set of test, invariant and assert lines is identical to master's. improve.t27 no longer uses tri::t27b::zig_like_optimization_plan, which 6b8b6ca moved to docs. The restored golden specs hash to the spec_hash already recorded in golden_GoldenSeries.json and golden_GoldenSpiral.json. Closes #13303 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * specs: restore codegen_audit.t27 typed LOSSES undone by #12997 (Closes #13303) The merge turned `LOSSES : [5]Loss` back into an untyped array and dropped the bench `use` and the branch-bound model section. The t27b native ratchet reports the file as "ledger pass, now blocked: ExprArrayLiteral" (run 42406646026). Restore the 73f626b text the ledger records as a pass; every test and name of master's version is kept, 5 tests come back. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * specs/golden: take master's #13314 text whole after the merge (Refs #13303) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * specs/golden: type golden_oracle MECHANISM_DESCRIPTION as [3]str so t27b compiles it (Refs #13303) #13314 left `pub const MECHANISM_DESCRIPTION : str = [` (three strings typed as one str). t27b refuses it: the native ratchet reports `golden_oracle.t27: ledger pass, now blocked: ExprArrayLiteral` on master 4dfdd26 and on #13305 head 37c0665. The 4cfd2f2 text, which the ledger records as a pass, had `[3]str`. Only that token changes; every test of master's text stays. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * seals: re-save golden_GoldenOracle for the [3]str fix (Refs #13303) Re-saved from a T27 OS shell-cell pane with ~/t27/target/release/t27c (built from cb1c1d6, an ancestor of master), on the owner's word for this one seal on #13305. spec_hash ca92a02a5e matches the fixed specs/golden/golden_oracle.t27; tests 5/5, vacuous 0. Not blessed, not added to tools/seal_baseline.txt. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
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
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.
Split compile_time_optimizations.t27 into:
compile_time_rules.t27: 9 tests pass, 0 FAIL, 0 vacuous, L3 ASCII clean
Seal saved to .trinity/seals/t27b_CompileTimeRules.json
phi^2 + 1/phi^2 = 3 | TRINITY
Closes #12877