Блог
[измерено на arm64 Mac, тёплый кэш, медиана трёх запусков] Одна спека — specs/t27os/heartbeat_monitor.t27, три теста, шесть чистых функций — пятью путями наружу: t27b build в arm64-объект 608 B за ~1.0 мс (компиляция в 70-100 раз быстрее clang, артефакт в 28 раз меньше), вердикт t27b test за ~5.3 мс и t27b verilog в ~311 строк RTL. Время выполнения в пределах 2.4% от clang -O2; ручное разворачивание исходника измерено и сделало компиляцию медленнее.

specs/t27os/heartbeat_monitor.t27 — монитор автономного цикла AEL v2.0: вердикт о живости, законность обхода фаз и бюджет зависших тиков в 3. Три теста, шесть чистых функций, без строк (подмножество t27b не несёт методов str).
Одна спецификация на входе, пять путей на выходе. Вопрос: во что обходится каждый бэкенд и что он даёт взамен?
Прогретый кэш, arm64 Mac, каждый тайминг — медиана трёх запусков:
| # | Бэкенд | Команда | Время (тёплый) | Выход | Вердикт | Превосходство |
|---|---|---|---|---|---|---|
| 1 | Нативный объект | t27b build <spec> -o out.o | ~1.0 мс | arm64-объект: 172 B __text, 608 B всего | быстрейший путь от спеки к машинному коду | компиляция в 70-100 раз быстрее clang |
| 2 | JIT-тест | t27b test <spec> | ~5.3 мс | 3/3 PASS, JIT-образ 968 B | самый быстрый вердикт | выполнение теста <0.005 мс |
| 3 | Ассемблерный листинг | t27b asm <spec> | ~10 мс | ~170 строк arm64 | быстрейший способ прочитать, что сделает кремний | осмотр без накладных расходов |
| 4 | Референс (t27c) | t27c test <spec> | ~10 мс | вердикт полного фронтенда | тот, кому доверяет CI | verification с доказательством |
| 5 | Verilog | t27b verilog <spec> | ~20-120 мс | ~311 строк RTL | от спеки к кремнию | аппаратный путь открыт |
| Тулчейн | Ко��пиляция (тёплая) | Артефакт | Время выполнения (200M вызовов) | Вызовов/с | Превосходство |
|---|---|---|---|---|---|
| t27b build | ~1.0 мс | объект 608 B | 439 мс | 456M | компиляция в 70-100 раз быстрее, артефакт в 28 раз меньше |
| clang -O2 | 70-110 мс | бинарник 17,016 B | 428 мс | 467M | отраслевой эталон времени выполнения |
| gcc -O2 | 1.49 с | 17 KB | ~450 мс | ~444M | кроссплатформенная зрелость |
| zig 0.16 | 6.7-13.9 с | 377 KB | 150 мс | 1,333M | абсолютный чемпион по времени выполнения, компиляция в 10,000 раз медленнее |
| go 1.25 | 0.07-0.16 с | 2.4 MB | 830 мс | 241M | скорость разработки, артефакт в 3,942 раза больше |
| rustc 1.99 | 0.11-0.14 с | 470 KB | 0.14-0.15 с | ~1,333M | безопасность плюс производительность, артефакт в 27 раз больше |
| c++ -O2 | 300-400 мс | ~18 KB | ~430 мс | ~465M | t27b компилирует в 300-400 раз быстрее |
| python 3.12 | Н/Д (интерпретатор) | ~50 KB исходника | 90.5 с* | ~2.2M | t27b выполняет в 200 раз быстрее |
| javascript (V8) | Н/Д (JIT) | 0 B (исходник) | ~120 мс | 1,667M | артефакт t27b в 28 раз меньше |
*Python нормализован: 10M вызовов = 4.5 с → 200M вызовов = 90.5 с
t27b пока не поддерживает флаг компилятора --unroll. Ниже измерены развёрнутые вручную исходники .t27, а не компиляторная метапрограммация.
| Спецификация | Вызовов в спеке | Компиляция всего | Компиляций/с | Вызовов/с (runtime) |
|---|---|---|---|---|
| t27b build, базовый | 200M | 1.0 мс | Н/Д | 456M |
| bench_fn_unroll_100.t27 | 100 | 4.7 мс | ~21,276 | не измерено |
| bench_fn_unroll_1000.t27 | 1,000 | 334 мс | ~2,994 | не измерено |
Ручное разворачивание исходника не улучшает пропускную способность во время выполнения. Оно увеличивает работу фронтенда: разбор, типизация и codegen растут с размером исходника. Следующий эксперимент должен реализовать настоящую компиляторную метапрограммацию: путь --unroll N, который разворачивает чистую функцию на этапе компиляции, сохраняет семантику и сообщает и логические, и исполненные вызовы.
t27b build отвергает --unroll. Ручное разворачивание исходника измерено и сделало компиляцию медленнее; это не оптимизация во время выполнения.Автономный цикл AEL v2.0 теперь работает с настоящим монитором, а не заглушкой:
spec (.t27) --t27b test--> 5 ms verdict (every tick)
|
+--t27b build--> 1 ms native .o (deploy the watchdog)
|
+--t27c test--> reference verdict (CI gate)
|
+--t27b watch--> rebuild + act on every spec change (live monitor)
t27b watch <spec> -o out.o --then '<cmd>' пересобирает по изменению файла и запускает <cmd> после каждой успешной сборки — измерено вживую: спека тронута, REBUILT напечатан в пределах секунды. Это примитив сердцебиения.
Примечание: панель разворачивания показывает пропускную способность только на этапе компиляции. Вызовов/с для развёрнутых спецификаций не измерено, потому что t27b пока не поддерживает компиляторный --unroll.
Цикл улучшения с фокусом на Парето (тик 15 минут через specs/crons/t27-backend-shootout-improvement-loop.t27):
tri shootout improve — ранжирует пробелы shootout по Парето, применяет измеримые исправления, заново измеряет вызовы/с во время выполнения, перегенерирует инфографику, проверяет золотую цепь и сливает только при зелёном CI.specs/tri/shootout/bench.t27 — бенчмарк-харнесс и квитанции разворачивания. Компиляторный --unroll не реализован; ручное разворачивание исходника измерено и не улучшило время выполнения.specs/tri/shootout/improve.t27 — контракт команды tri shootout improve.--unroll как будущий этап, закрыть RED_ON_MASTER. Ожидание: 1-2 итерации (15-30 минут).Готово к публикации blog-share v5:
Issue на GitHub: #12907 (измерения), #12908 (колонка превосходства), #12909 (метапрограммация), #12910 (инфографика)
φ² + 1/φ² = 3 | TRINITY
--unroll не реализован, поэтому вызовов/с во время выполнения для развёрнутых спек не измерено.tri shootout improve и specs/tri/shootout/*.t27 — предложенные контракты, а не собранные команды.Поработаем вместе
Работаю по контракту и part-time с hardware-AI, FPGA/RTL и ML-системами — от спецификации и открытого тулчейна до воспроизводимых измерений.