T27.AI

Блог

Компилятор в 3 МБ, который превращает спеку в код AArch64 за 5 мс, и где он всё ещё проигрывает

2026-10-11 · 12 мин чтения

[замер на общей Railway-лаборатории; время выполнения — эмуляция qemu, счёт инструкций точный; код t27b уровня -O0] t27b 0.2.0 вышел с подписанной квитанцией на тот самый бинарник, что лежит в релизе. Как нативный кросс-компилятор на x86_64 он компилирует спеку t27 вместе с тестами примерно за 4,8 мс — в 8,8 раза быстрее, чем gen-c и gcc -O0, и примерно в 640 раз быстрее zig Debug на спеку, — занимая 5,3 МиБ памяти, одним бинарником примерно в 3 МБ, и сходится с эталоном на всех 8344 тестах, которые прогнали обе стороны. Прорывом в сгенерированном коде это не назовёшь: он выполняет в 3,4 раза больше инструкций, чем gcc -O2, и в 4,5 раза больше, чем zig ReleaseFast, его код до 2 раз больше, а на Linux это JIT для тестов, который пока не умеет писать ELF. За неделю его доля среди спек, которые проходит эталон, выросла с 8,6% до 98,9%.

Вот компилятор, который скачивается одним файлом примерно в 3 МБ. Дайте ему спеку .t27 — и примерно через 5 миллисекунд он её разобрал, проверил типы, понизил и записал машинный код AArch64 для каждой функции и каждого теста в ней. Ему не нужны ни LLVM, ни ассемблер, ни линкер, а за работой он занимает около 5 МиБ памяти. Это t27b, нативный бэкенд языка t27. 10 октября он вышел версией 0.2.0 вместе с подписанной квитанцией на тот самый бинарник, что лежит в релизе.

Мы сравнили его с zig, gcc, clang и rustc на одних и тех же спеках и одной машине, и честный результат состоит из двух половин. t27b очень быстрый, очень маленький и сходится с эталоном на каждом тесте. Код, который он пишет, медленный: примерно уровня gcc -O0 и в три–пять раз хуже любого оптимизирующего компилятора. В этом посте — обе половины, как их мерили и как проверить их самому.

t27b 0.2.0 · check the binary, compile a spec

Что такое t27b

t27 — язык, где сначала пишется спека: файл .t27 содержит типы, функции, тесты и инварианты, а t27c превращает его в Zig, C, Rust или Verilog. t27b — другая дорога. Он читает тот же файл через подключённый фронтенд t27c, понижает его в собственное IR и сразу выдаёт машинный код AArch64. t27b test прогоняет каждый тест во встроенном JIT и сверяет результат с собственным интерпретатором IR; t27b build пишет объектник Mach-O. Новые решения о понижении живут в плановых спеках .t27, которые t27c gen-rust превращает в Rust: по правилу проекта новая логика пишется на t27.

Результат одной таблицей

Время компиляции: миллисекунды против секунд

Лаборатория — машина x86_64, поэтому t27b собрали и под неё. На x86_64 t27b test проходит фронтенд и генератор кода вместе с тестами и останавливается, только когда пытается отобразить JIT; время работы этого процесса и есть время компиляции t27b. Все остальные конвейеры тоже шли нативно, со временем генератора t27c в своём счёте. Один процесс за раз, шесть кругов по спекам и конвейерам по очереди, в отчёте тёплые медианы.

Большая часть времени zig на спеку — постоянные затраты: сборка запускалки тестов, частей std для паники и форматирования и линковка, всё через LLVM. Маленькие и большие спеки одинаково заняли 2,7–3,4 с в Debug. Если собрать все 20 спек одним вызовом, zig тратит 0,31 с на спеку: разрыв падает примерно с 640x до 8,6x в Debug и примерно с 2900x до 46x в ReleaseFast. Многофайлового режима у t27b нет, поэтому его сумма — 20 отдельных процессов. На 567 файлах, которые проходят все конвейеры, t27b компилирует 183 файла в секунду; gen-c и gcc -O0 — 28.

Одна поправка, которую мы должны: в прежних отчётах время компиляции t27b называлось 33–86 мс. Его мерили под qemu. Сверка с нативной сборкой на тех же спеках показала, что эмуляция замедляла фазы компиляции t27b примерно в 20 раз (среднее геометрическое), так что нативная цифра на порядок меньше.

Память и размер

Медиана t27b — 5,3 МиБ, самой прожорливой спеке понадобилось 48 МиБ. zig нужны 354 МиБ в Debug и 500 МиБ в ReleaseFast, примерно в 67 и 95 раз больше. Установка говорит то же самое: один исполняемый файл со статически вшитой std Rust, которому во время работы нужна glibc, против сотен мегабайт компилятора, исходников libc и LLVM. У этой малости есть настоящая цена: слинковать исполняемый файл t27b не может.

Точно по эталону

Эталон — t27c gen, затем zig test в Debug, нативно. t27b прогнал весь корпус, 1819 файлов, через свой JIT и свой интерпретатор, и везде, где обе стороны запускали тесты файла, они сравнивались тест за тестом: расходятся 0 из 8344 тестов. zig Debug, собранный под aarch64 и запущенный под тем же qemu, тоже сходится с t27b на всех 8344.

Оптимизаторы менее точны. zig ReleaseFast меняет вердикт 7 файлов по сравнению с zig Debug; в одном из них тест читает ячейку стека после того, как её кадр уже вернулся. На дороге через C хуже. В выводе gen-c есть неопределённое поведение, поэтому вердикт зависит от уровня оптимизации: clang -O0 и -O2 расходятся на 39 файлах и 107 тестах. Самый маленький пример — функция, которую gen-c печатает как bool dummy(void) { true; }, без return. Она проходит под gcc -O0 и clang -O2 и падает под gcc -O2 и clang -O0.

Каждый конвейер детерминирован на месте. t27b, генераторы t27c, gcc без -g и rustc выдают бит в бит то же самое и при сборке из другого каталога; zig и zig cc записывают каталог сборки в отладочную информацию. На этом свойстве держатся подписанные квитанции лаборатории t27b: два прогона одного коммита должны дать один корень Меркла.

Где t27b проигрывает

Это та половина результата, из которой не выйдет заголовка. Код t27b выполняет примерно столько же инструкций, сколько gcc -O0, и примерно вдвое меньше, чем zig Debug. Но любой оптимизирующей сборке он уступает в 3–5 раз: в 3,2 раза zig ReleaseSafe, сборке с теми же проверками во время выполнения; в 3,4 раза gcc -O2; в 4,5 раза zig ReleaseFast. Под qemu это в 3,4–4,1 раза больше времени, а на криптографических спеках разрыв с zig ReleaseFast доходит до 10 раз по инструкциям.

Две цены поменьше. Проверки переполнения, включённые по умолчанию, стоят около 12% инструкций и 24% эмулированного времени. А одна спека, compiler/core/t27core, идёт в 8,3 раза медленнее, чем под zig Debug, хотя t27b выполняет меньше инструкций: перед каждым тестом jit.call копирует всё состояние модуля, чтобы каждый тест начинался с чистого листа, и каждый из 95 тестов t27core платит за эту копию не меньше 2,8 мс.

Как мерили и чему не доверять

• Одна общая машина. Railway-лаборатория t27c: Intel Xeon 6975P-C, 48 потоков, квота 24 CPU, вместе с задачами других агентов. Нагрузка записывалась с каждым замером (от 27 до 103). В отчёте медианы, потому что разброс настоящий: на компиляциях в несколько миллисекунд он доходил до 34% у t27b и 36% у gcc -O0.
• Время выполнения — эмуляция. Всё шло под qemu-aarch64 7.2 на x86_64. Это ранжирует конвейеры на этой машине, но это не скорость arm64, и цена эмуляции зависит от набора инструкций (на kernel_sieve zig ReleaseFast выполняет на 43% меньше инструкций, чем t27b, и всё равно идёт на 25% дольше). Счёт инструкций — мера надёжнее.
• Спеки выбирались, не глядя на t27b: 20 файлов с наибольшим числом инструкций под gcc -O0 среди 567, которые проходят все конвейеры. Это правило отсекает всё, что gen-c не может скомпилировать, поэтому криптографические спеки мерили только против zig.
• Разные правила выполнения. t27b сбрасывает переменные модуля перед каждым тестом и проверяет инварианты во время выполнения; запускалки zig и C сохраняют состояние, а инварианты сворачивают или отбрасывают. В суммах времени только тесты, которые прогнали все конвейеры.
• Холодный — значит первый прогон круга, а не пустой страничный кэш. По-настоящему холодную первую сборку zig с пустым глобальным кэшем мерили отдельно: 6,2 с в Debug и 17,2 с в ReleaseFast.
• Четыре ошибки инструмента поймали по ходу и исправили до этих чисел: фильтр символов zig, читавший 0 байт, отдельные секции на каждую функцию у rustc, имена тестов с пробелами и пол в 11,5 МиБ у замеров памяти из Python. Каждую заметили, потому что число выглядело неправдоподобно.
• Обвязка замера не закоммичена. Это около 1650 строк Python, Zig и C во временном каталоге лаборатории, по правилу проекта «только t27»; каждая команда, которую она запускала, выписана в отчёте, так что числа можно воспроизвести.

Неделя покрытия

4 октября t27b проходил 56 из 648 спек, которые проходил эталон. v0.1.0 8 октября проходила 899 из 1099 с проверками и ещё 150 пусто. v0.2.0 проходит 1349 из 1364, пустых 5, и ни один из 8629 сравнённых тестов не расходится с эталоном. Между коммитом замера и релизом пали ещё четыре блокера, и проходы t27b выросли с 1312 до 1349 при росте проходов эталона с 1331 до 1364: мономорфизация anytype (t27#8738), i128 во время выполнения, этапы 1 и 2 (t27#8750, t27#8795), и кадры до 16 МиБ локальных агрегатов (t27#8764).

Что осталось в журнале: i128 во время выполнения, этап 3, для tri/t27b/eval_arith.t27, @cos (t27#8677), два пустых типизированных литерала массива, пять заглушек, которые проходят, ничего не проверяя (t27#8766), и пять строк, где эталон проходит по неверной причине, а t27b прав, что отказывается.

Почему это можно проверить

Бинарник в релизе — не пересборка. Это тот самый файл, которым лаборатория t27b прогнала весь корпус, и его sha256, 0202a2ae..., — это поле t27b_sha256 в квитанции лаборатории на этот прогон. Квитанция подписана Ed25519 под строкой домена t27-corpus-receipt-v1 и несёт корни Меркла над каждым входным файлом, каждым вердиктом и каждым сгенерированным листингом. Из клона t27 команда t27c corpus-receipt compare R R проверяет подпись и заново хеширует каждый лист:

base "59e2c87c4bd74c1137f4071b5e63095a285ce5e4" AUTH_MISSING_NONE AUTHOR leaves-bound true
head "59e2c87c4bd74c1137f4071b5e63095a285ce5e4" AUTH_MISSING_NONE AUTHOR leaves-bound true
totals true inputs true verdicts true outputs true: EQUIVALENT

Каждый прогон корпуса ещё и выполняет каждый тест дважды, в JIT и в собственном интерпретаторе IR, и расхождений 0. А подписанная квитанция DDC собирает самокомпиляцию t27core тремя путями — через gen-c и cc, через t27b и через zig, — и все три дайджеста второй ступени совпадают.

Теперь пределы, потому что в них весь смысл упражнения. Вердикт DDC — DDC_BACKEND_AGREEMENT, а не DDC_INDEPENDENT: у всех трёх путей общий фронтенд t27c. JIT и интерпретатор читают одно и то же IR. Эталон, с которым t27b сходится на 8344 тестах, выходит из того же фронтенда, который подключает t27b. Фаззер случайных программ — единственная проверка, которая выходит за пределы корпуса, и он всё ещё находит расхождения: 7 на 1000 программ в прогоне, который цитирует отчёт, и 3 в прогоне релиза. Ни одна проверка здесь не сравнивает t27b с независимо написанным фронтендом t27. Проверка необычно наглядна, но по большей части это всё ещё согласованность с самим собой.

Что дальше

• Оптимизатор — или нет? Данные говорят, что t27b — базовый компилятор, в той роли, которую играют copy-and-patch JIT и Cranelift как быстрый первый уровень. Распределитель регистров и несколько проходов peephole закрыли бы часть разрыва в 3–5 раз и потратили бы часть этих 5 мс; стоит ли размен того — вопрос открытый. Ни copy-and-patch JIT, ни Cranelift здесь не мерили.
• Вывод ELF и шаг линковки, чтобы t27b мог выпускать бинарник для Linux, а не только гонять тесты в своём JIT.
• i128 во время выполнения, этап 3, и @cos — последние нереализованные блокеры в журнале.
• Перенос. Сегодня из .t27 сгенерированы 36% бэкенда t27b и 12% кода, который он исполняет; правило владельца — ни одно изменение не может увеличить написанный руками Rust в cli/t27b.
• Расхождения фаззера и более дешёвый сброс перед тестом для спек с большим состоянием модуля.

Вердикт

Не прорыв в сгенерированном коде. Быстрый, лёгкий базовый компилятор, точный по своему эталону: компилятор в 3 МБ без LLVM, которому нужно около 5 МиБ памяти, который превращает спеку в код AArch64 примерно за 5 мс и сходится с эталоном на каждом из 8344 тестов. Это та ось, с которой стоит начинать, а разрыв в 3–5 раз в качестве кода — та, над которой стоит работать. Релиз, отчёт о замере со всеми оговорками (t27#8855), цикл улучшений (эпик t27#8326) и квитанция прогона релиза — в ссылках ниже.

Поработаем вместе

Хотите так же проверить собственный дизайн?

Я аудирую RTL и строю независимые побитово точные модели, затем провожу результат через синтез и, когда это полезно, проверяю на плате Artix-7. Первый модуль проверки — бесплатно.

Обсудить задачуУслуга верификации