Async Rust до сих пор в MVP: четыре оптимизации компилятора

Async Rust продавали как «zero cost abstraction» — обещание, что асинхронный код по размеру и скорости должен быть равен ручному state machine на синхронном Rust. На бумаге это даёт executor-agnostic код (один и тот же исходник запускается под Tokio на сервере и под Embassy на микроконтроллере), на практике — на embedded особенно — видно: каждый байт прошивки на счету, а async добавляет десятки и сотни лишних строк сгенерированного кода. Команда из голландской Rust-консалтинговой компании Tweede golf разобрала, откуда берётся этот bloat и как его срезать на уровне компилятора — с конкретными цифрами и Rust Project Goal.

Это вторая часть серии. В первой — обходные приёмы для async-кода прямо в пользовательском коде. Во второй — автор копает в MIR (Mid-level Intermediate Representation — внутреннее представление rustc между исходником и LLVM IR) и формулирует, что должен научиться делать сам компилятор. Цель — не лечить симптомы, а добраться до корня и улучшить генерацию futures.

Что компилятор делает с async-блоком

Возьмём простой пример из статьи:

У bar два await-points — значит, в state machine минимум два состояния. Просим компилятор сдампить MIR на этапе coroutine_resume (последний async-специфичный pass) и видим:

			variant_fields: {
    Unresumed (0): [],          // стартовое состояние
    Returned  (1): [],          // future уже завершилась
    Panicked  (2): [],          // future упала с panic, ловили catch_unwind
    Suspend0  (3): [_s1],       // на 1-м await — храним foo-future
    Suspend1  (4): [_s0, _s2],  // на 2-м await — результат + новая foo-future
}
		

Returned и Panicked — служебные. Future::poll — безопасная функция, и опросить уже завершённую future нельзя так, чтобы получить undefined behaviour. Поэтому компилятор после первого Ready переключает future в Returned, и при повторном poll она паникует. Похожая логика для Panicked: после пойманного unwind future блокируется от повторного poll, иначе можно дёрнуть её в неконсистентном состоянии — автор сам отмечает, что точная документация по этому состоянию ему не нашлась, и сравнивает механизм с mutex poisoning.

Логично, но автор замечает: bar генерирует 360 строк MIR, а синхронный аналог — 23 строки. То есть в 15+ раз больше. Часть этого добавления LLVM оптимизирует позже, но не всё — и на embedded остаток ощутимо влияет на размер прошивки.

Оптимизация 1: вместо panic — снова Pending

Future в состоянии Returned обязана не вызывать UB. А не обязана паниковать. Можно вместо panic! просто возвращать Pending: контракт Future не нарушается, ничего опасного не происходит.

Panic — относительно дорого: добавляется ветка с побочным эффектом, которая плохо оптимизируется. Автор пропатчил компилятор и измерил: 2–5% сокращение размера бинарника для async-прошивок на embedded.

Идеальное место — флаг по аналогии с overflow-checks = false: в debug-сборке оставляем panic, чтобы быстро ловить ошибочный повторный poll, в release — экономим. Аналогично, при panic = abort состояние Panicked потенциально можно убрать целиком — автор хочет это отдельно исследовать.

Оптимизация 2: лишняя state machine у пустого async-блока

Возвращаемся к foo: там нет ни одного await-point, future просто возвращает число. Логично было бы реализовать вручную как:

Никакого состояния не нужно — просто вернуть 5. На деле компилятор генерирует CoroutineLayout с тремя вариантами (Unresumed, Returned, Panicked) и честный switch по дискриминанту перед каждым возвратом — даже там, где без него можно было обойтись. Когда await-точек ноль, state machine можно убирать целиком — это около 0,2% размера бинарника. Поведение чуть меняется только для неконформных executor-ов: future всегда возвращает Ready без переходов между состояниями.

Ещё две оптимизации в плане работ

• Inlining futures с одним await-point. В таких future внутреннее состояние сводится к Suspend0 + Returned + Panicked, а ветка управления при правильной работе компилятора схлопывается в обычный вызов с одним переключением.
• Схлопывание идентичных состояний из ветвей match. Если в функции несколько await-точек попадают в одинаковые по смыслу варианты (одни и те же сохранённые поля), их можно объединить в одно состояние state machine — без потери семантики.

Каждый из этих кейсов даёт меньше, чем замена panic на Pending, но вместе с ней образуют связный набор патчей в компилятор. Автор формулирует план так: вынести проблему из «каждая embedded-команда со своими обходными приёмами» в «исправление в rustc раз и навсегда».

Project Goal и финансирование

Изменения требуют времени на проектирование, обсуждение в Rust-проекте и собственно правки. Автор оформил это как Project Goal по async state machine optimisation и оценил необходимое финансирование примерно в €30 000 — в основном на работу embedded-инженера над патчами компилятора. Платит обычно либо сам Tweede golf, либо Rust Foundation через программу грантов, либо отдельный спонсор; Project Goal — публичный механизм, чтобы заявить цель и собрать поддержку, в том числе финансовую. По меркам компиляторных проектов это недорого: типичная цена «уберём 2–5% размера прошивки в любом async-проекте» — десятки тысяч евро.

Это вторая часть серии. В первой я показывал, что вы можете сделать в своём async-коде, чтобы избежать части bloat. Во второй мы лезем во внутренности и переводим методы из первой части в оптимизации для компилятора.

Tweede golfблог tweedegolf.nl, май 2026

Выводы

Async в Rust — давно главный болевой пункт у embedded-сообщества: обещания zero cost не подтверждаются, а обходные приёмы на уровне пользовательского кода сильно ограничены. Tweede golf формулирует разговор иначе: показывает, какие именно паттерны генерации виноваты, и предлагает их закрывать в компиляторе.

Для практика это значит две вещи. Первое — писать async-код можно не оглядываясь на «не сделать ли я ещё одно состояние»; bloat лежит в компиляторе, и просьба к нему — править генерацию, а не ваши async fn. Второе — следить за статусом Project Goal: если его подхватят, размер async-кода в release-сборках уменьшится у всех пользователей сразу, без правок в их репозиториях.

Оригинал — на tweedegolf.nl/en/blog/237/async-rust-never-left-the-mvp-state. Первая часть серии — «Debloat your async Rust». Project Goal лежит на rust-project-goals/2026/async-statemachine-optimisation.