Практический интерес здесь не в самом Plush, минималистичном динамическом языке на Rust, а в измеренном ответе на старый вопрос: сколько стоит стековая модель байткода. Вывод автора сформулирован жёстко: «вам, вероятно, не стоит писать стековые байткод-интерпретаторы в 2026 году» (перевод редакции). Для тех, кто пишет свои DSL, скриптовые движки или встраиваемые интерпретаторы, это готовый аргумент с цифрами и с честным списком того, что не ускорилось.

• Медианное ускорение 2,07 раза, максимальное 3,37; геометрическое среднее 1,94 раза, из них 1,55 дала сама регистровая модель без оптимизаций, ещё 25% добавили специализированные инструкции.
• Инструкция теперь 64-битное слово вместо enum на 24 байта; трёхадресная форма reg(a) = reg(b) + reg(c), до 64 000 локальных переменных, 76 опкодов.
• Замеры: MacBook Air M5 (10 ядер, arm64), rustc 1.96.0, 11 чередующихся запусков на тест, медиана; повторный прогон дал те же результаты.
• Против Lua 5.5.1: быстрее на 24% в fib и на 55% в binary_tree; сравнение с CPython 3.14.6 и CRuby 4.0.6 автор ограничивает оговорками о разной семантике и составе тестов.
• Тесты сборщика мусора почти не изменились: регистровая модель ускоряет диспетчеризацию, а не аллокацию.

Почему стековая машина медленнее

В стековой VM выражение a + b превращается в три инструкции: положить a, положить b, сложить. Каждая инструкция проходит через диспетчер: прочитать опкод, перейти на обработчик, сдвинуть указатель. В регистровой VM то же выражение записывается одной инструкцией с тремя операндами: куда положить и что сложить. Главный тезис статьи: в интерпретаторе самый большой рычаг производительности это число инструкций, которые нужно продиспетчеризовать, и регистровая модель сокращает его в разы. Автор цитирует это как основной вывод: «снова, в интерпретаторе главный рычаг это уменьшение числа инструкций» (перевод редакции).

Второй эффект: значения не гоняются между локальными переменными и временным стеком. Локальные переменные и есть регистры фрейма, поэтому x = y + z не требует ни загрузки, ни сохранения.

Как устроен новый байткод

Старая инструкция была Rust-перечислением Insn размером 24 байта. Новая упакована в 64-битное слово: опкод и операнды-регистры. Для сравнения автор приводит Lua: там 32-битное слово с 8-битными полями, отсюда лимит в 255 регистров на фрейм и 200 именованных локальных переменных. У Plush поля шире, до 64 000 локальных переменных, ценой вдвое большего размера инструкции. Всего опкодов 76. Сверху добавлены оптимизации, каждая из которых убирает инструкции: слитые сравнение-и-переход, сдвиги и маски с непосредственными операндами, свёртка констант, устранение лишних пересылок. Инлайн-кэши вынесены в отдельные таблицы, чтобы не раздувать слово инструкции.

Замену enum на 64-битное слово автор описывала неделей раньше, тогда это дало 17% на старой стековой модели; нынешняя статья седьмая в серии о Plush.

Что показали замеры и где их границы

Методика описана подробно: MacBook Air M5, rustc 1.96.0, для каждого сравнения 11 чередующихся запусков старой и новой версии, берётся медиана, весь набор прогнан дважды. Сравнивались конкретные коммиты репозитория. Неоптимизированная регистровая VM дала 1,55 раза по геометрическому среднему, оптимизации добавили ещё 25%, итого 1,94; медиана по отдельным тестам 2,07, максимум 3,37. Тесты, упирающиеся в сборщик мусора, остались на месте: диспетчеризация там не узкое место.

Сравнение с другими языками автор сопровождает оговорками: CPython 3.14.6, CRuby 4.0.6 и Lua 5.5.1 имеют другую семантику, а набор тестов синтетический. Заявлены только два прямых результата против Lua: fib на 24% быстрее, binary_tree на 55%. Отдельная демонстрация: программный рендеринг уровня Quake в 800 на 600 в один поток, около 47 кадров в секунду, с живой кучей до 1 ГБ без заметных пауз GC по оценке автора.

Что из этого забрать в свой интерпретатор

• Если вы проектируете байткод с нуля, начинайте с регистровой модели: выигрыш от неё больше, чем от любой микрооптимизации диспетчера.
• Считайте инструкции, а не такты: слитые инструкции (сравнение плюс переход) и непосредственные операнды окупаются именно сокращением диспетчеризации.
• Не ждите ускорения там, где узкое место в аллокации: GC-тесты Plush не изменились.
• Готовые бинарники Plush есть для Linux и macOS (x86-64 и arm64) и через PowerShell-установщик для Windows x86-64; код под Apache-2.0, примеры под CC0, всё в репозитории.

Кому это не пригодится: тем, кто использует готовые рантаймы и не пишет свои. CPython, к слову, остаётся стековой машиной, и разница подходов хорошо видна на его фоне; о цене операций в самом Python мы недавно писали в связи с новой 3.15.0rc2. Другой свежий пример переписанного интерпретатора с подробным разбором каждой оптимизации: Wasmi 2.0, где тоже сменили промежуточное представление и получили 2,2 раза.

Источники: Pointers Gone Wild: Plush's New Register-Based Interpreter, Репозиторий Plush, Предыдущая статья серии: Replacing a Rust enum with a 64-bit word

Ошибка проявляется только там, где FMA эмулируется программно: на x86 это дешёвые или старые Intel без AVX2 и процессоры Hygon без аппаратного FMA, а также 32-битный ARM и старые встраиваемые тулчейны. 64-битный ARM, по словам автора, не затронут. На практике это касается детерминированных симуляций и численных библиотек, где одинаковый код обязан давать одинаковые биты на разных машинах: сетевые игры с lockstep, физические движки, воспроизводимые вычисления. Автор честно пишет, что не знает, насколько ошибка важна в реальных программах.

• Ошибка: неправильное округление fmaf на субнормальных входах, отличие на один младший бит.
• Затронуты f32::mul_add и std::simd в Rust, fmaf() в musl; проверка одна и та же: a = 0x97000800, b = 0x1cfff001, c = 0x00010002, верный ответ 0x00010001, ошибочный 0x00010002.
• Исправлены fearless_simd и ABI f128 в компиляторе Rust на 32-битном ARM; патч в стандартную библиотеку Rust на момент публикации ждал ревью, исправления musl не влиты.
• Аппаратный FMA (x86 с AVX2/FMA3, 64-битный ARM) не затронут: ошибка живёт в программной эмуляции.
• Контрпример к первой версии исправления в Rust нашла языковая модель, которую автор попросил искать ошибки.

Что такое FMA и откуда берётся лишний бит

Fused multiply-add вычисляет a*b+c с одним округлением в конце вместо двух: после умножения и после сложения. Так требует IEEE 754, и именно на это рассчитывают численные алгоритмы: одно округление даёт предсказуемую ошибку. Когда у процессора нет аппаратной инструкции, библиотека эмулирует FMA через операции с расширенной точностью и ручную коррекцию округления. Ошибка, которую нашёл автор, живёт в этой коррекции на субнормальных числах, то есть очень маленьких значениях, у которых часть мантиссы уже ушла в ноль. В таких случаях программная реализация округляла не в ту сторону.

Автор переносил формально верифицированный алгоритм и гонял его в CI на эмуляторах SIMD, добавив тесты на миллион субнормальных значений и ещё миллион случаев, требующих коррекции округления. Отдельно он попросил языковую модель искать контрпримеры, и она нашла случай, ломающий первую версию исправления для стандартной библиотеки Rust: там ошибка приводила ещё и к неправильной установке флагов исключений плавающей точки.

Как проверить свою платформу

Достаточно трёх чисел. Ниже проверка на C для fmaf из системной libc; в Rust то же самое делается через f32::from_bits и mul_add:

Если вывод 00010002, ваша libc или тулчейн эмулируют FMA с ошибкой. На машине с аппаратным FMA (любой современный x86 с AVX2, 64-битный ARM) результат будет верным независимо от библиотеки, поэтому проверять имеет смысл именно сборки под старое или встраиваемое железо и контейнеры на musl (Alpine) на таких хостах.

Состояние исправлений

• fearless_simd: исправлено, можно использовать как реализацию FMA без этой ошибки.
• Rust, тип f128 на 32-битном ARM: ошибка ABI исправлена в компиляторе (тип доступен только в nightly).
• Стандартная библиотека Rust (f32::mul_add, std::simd): патч на момент публикации ожидал ревью; номер версии с исправлением не назван.
• musl: предложены минимальное исправление и полная переработка fmaf(), ни то ни другое не влито. Автор отмечает, что код FreeBSD, откуда растёт реализация, мог копироваться и в другие тулчейны.

Кому это ничего не меняет: сервисам на современных x86 и ARM64, где FMA аппаратный, и коду, не зависящему от битовой точности. Кому стоит проверить: авторам физических движков и симуляций с детерминизмом между машинами, разработчикам под 32-битный ARM и тем, кто собирает статические бинарники под musl для старых серверов. Про то, как выбор libc влияет на скорость тех же бинарников, мы писали на примере Rust Coreutils; смежная тема из этой же недели: переписывание линкера mold на Rust. Что мы проверим дальше: когда патч попадёт в стабильный Rust и появится ли исправление в релизе musl.

Источники: Shnatsel: Implementing FMA and finding bugs in C and Rust standard libraries, Обсуждение на Lobsters

Между rc1 и rc2 вошло около 144 исправлений от 76 участников: ошибки, сборка, документация. До финала принимаются только проверенные исправления багов, новых функций не будет. Релиз-менеджер Хьюго ван Кеменаде называет rc2 финальным кандидатом и просит мейнтейнеров тестировать пакеты именно сейчас; ставить rc2 в прод команда не рекомендует.

• 3.15.0rc2 — последний запланированный кандидат; ABI заморожен, финальный релиз назначен на 1 октября 2026 года.
• JIT: в среднем на 8–9% быстрее обычного интерпретатора на x86-64 Linux и на 12–13% быстрее tail-calling interpreter на macOS с Apple Silicon; разброс по тестам от замедления на 15% до ускорения больше чем вдвое; цифры предварительные.
• Официальные сборки для Windows x64 используют tail-calling interpreter, сборки для macOS по умолчанию поддерживают free-threading.
• Новое в языке: ленивые импорты через ключевое слово lazy (PEP 810), встроенные типы frozendict (PEP 814) и sentinel (PEP 661).
• Мейнтейнерам: собирайте wheels под 3.15 и гоняйте тесты на rc2; после 1 октября исправление попадёт только в 3.15.1.

Что означает «ABI заморожен»

ABI — набор правил, по которым скомпилированный код (numpy, pydantic-core, любой пакет с C или Rust внутри) обращается к интерпретатору: размеры структур, порядок полей, сигнатуры функций. Пока ABI меняется, wheel, собранный под бету, может упасть на финальной версии. Теперь команда CPython обещает: «There will be no ABI changes from this point forward in the 3.15 series» (перевод редакции: «С этого момента в серии 3.15 изменений ABI не будет»). Значит, wheel, собранный сегодня под rc2, останется валидным для 3.15.0 и всех 3.15.x.

На практике это точка, после которой авторы популярных библиотек выкладывают на PyPI сборки для новой версии. Если ваш проект зависит от пакета, который до сих пор не собран под 3.15, самое время открыть issue или прислать PR: у мейнтейнеров есть месяц.

Сколько на самом деле даёт JIT

Документация «What's New» приводит две цифры, и их важно не смешивать. На x86-64 Linux JIT даёт 8–9% ускорения в среднем геометрическом относительно обычного интерпретатора. На macOS с процессорами Apple JIT сравнивают с более быстрым tail-calling interpreter, и там выигрыш 12–13%. Разброс по отдельным тестам огромный: от замедления примерно на 15% до ускорения больше чем вдвое. Документация подчёркивает, что цифры предварительные и до финала могут измениться. Так что «Python стал на 10% быстрее» — неверное обобщение: на вашем коде может быть и минус.

Tail-calling interpreter — другой способ реализовать цикл исполнения байткода, где каждая инструкция вызывает следующую хвостовым вызовом вместо большого switch. В 3.15 именно он идёт в официальных 64-битных сборках для Windows. Официальные сборки для macOS по умолчанию получают поддержку free-threading, то есть режим без GIL остаётся экспериментальным, но доступным без пересборки.

Три новинки языка, которые вы заметите

Ленивые импорты (PEP 810): ключевое слово lazy перед import откладывает загрузку модуля до первого обращения. Это ответ на старую проблему медленного старта CLI-утилит, которые тянут тяжёлые зависимости «на всякий случай».

frozendict (PEP 814) — неизменяемый словарь, встроенный в язык: если все его ключи и значения хешируемы, его можно использовать как ключ другого словаря, и его безопасно отдавать наружу как константу. sentinel (PEP 661) закрывает старый обходной приём с _MISSING = object() для «значение не передано»: у таких маркеров появляется нормальный repr и корректное поведение при pickle.

Что сделать до 1 октября

• Поставьте rc2 рядом с рабочей версией: официальные установщики и исходники на python.org; в uv или pyenv сначала проверьте, что версия появилась в их списках (uv python list), и прогоните тесты проекта.
• Если у вас пакет с расширениями: соберите wheels под 3.15 и выложите на PyPI; ABI больше не изменится.
• Замерьте свой код с JIT и без: флаги сборки и переменные окружения описаны в документации; средним цифрам не верьте.
• Проверьте зависимости на совместимость с ленивыми импортами: код, который полагается на побочные эффекты при импорте, с lazy сломается.
• Нашли регрессию — сообщайте в трекер CPython сейчас: после релиза исправление уйдёт только в 3.15.1.
• Если пользуетесь корпоративным зеркалом PyPI, убедитесь, что оно синхронизирует wheels с тегом cp315: первые сборки под 3.15 появятся в ближайшие недели.

Контекст

Разработка 3.15 началась 7 мая 2025 года, первая бета вышла 7 мая 2026-го, rc1 — 4 августа. После финального релиза ветка получит около двух лет исправлений ошибок и затем ещё примерно три года обновлений безопасности, по обычному графику CPython.

Источники: Python 3.15.0rc2 (python.org), What's New in Python 3.15

Изображение на обложке: Python Software Foundation

Линкер склеивает скомпилированные объектные файлы в исполняемый файл, и на больших проектах это минуты ожидания при каждой пересборке. mold появился в 2021 году именно как ответ на это: по свежему бенчмарку автора он в 4,9 раза быстрее lld по медиане. Но проекты, которые собираются через сложные линкер-скрипты GNU ld, вроде ядра Linux, до сих пор были для него закрыты; 3.0 должна это изменить.

• mold переписывают на Rust; новая версия выйдет как mold 3.0, дата не названа.
• Цель: поддержка линкер-скриптов, чтобы mold собирал всё, что умеет GNU ld, включая ядра и прошивки.
• Текущий mold написан на C++20; по бенчмарку августа 2026 года он быстрее lld в 4,9 раза, а wild в 1,9 раза по медиане.
• Debug-сборка Chromium 145 на Threadripper 7980X: lld 16,64 с, wild 3,98 с, mold 1,65 с; TensorFlow 2.21: lld 50,73 с, mold 3,15 с.
• Текущий mold продолжает работать как замена ld и lld; включается флагом -fuse-ld=mold или через .cargo/config.toml.

Зачем линкеру скрипты

Линкер-скрипт описывает, как раскладывать секции кода и данных по адресам памяти. Обычному приложению это не нужно: там всё решает стандартная раскладка. Ядру, загрузчику или прошивке микроконтроллера критично, чтобы таблица прерываний лежала по конкретному адресу, а код инициализации попал в нужную область флеш-памяти. Всё это описывается на языке скриптов GNU ld, и до сих пор mold понимал лишь их малую часть: в собственной документации проект называет этот язык переусложнённым и ещё недавно прямо писал, что расширять поддержку не планирует.

Уэяма пишет, что цель новой версии — совместимость со всем, что умеет собирать GNU ld. Именно это открывает дорогу к тому, чтобы дистрибутивы Linux сделали mold линкером по умолчанию: пока хоть один важный пакет не собирается, менять умолчание никто не будет. Конкретных дистрибутивов с такими планами в README пока не названо.

We are rewriting the mold linker in Rust. This will be mold 3.0.

Насколько mold быстрее сегодня

Автор обновил бенчмарки в README репозитория в августе: девять крупных программ, медиана трёх запусков после прогрева, два стенда — Threadripper 7980X с 64 ядрами и Apple M1 Ultra, у которого использовались 16 производительных ядер. Сравнивались lld, wild (ещё один линкер на Rust) и mold. Результаты на Threadripper выглядят так.

На Chromium 145 lld тратит 16,64 секунды, wild 3,98, mold 1,65. На TensorFlow 2.21 разрыв ещё больше: 50,73 секунды у lld против 3,15 у mold. На Apple M1 Ultra картина ровнее: debug-сборка Clang 21 линкуется за 2,96 секунды у mold, 4,40 у lld и 2,78 у wild, то есть в этом тесте конкурент на Rust слегка впереди, хотя на большинстве остальных задач M1-стенда mold быстрее. Артефакты бенчмарка опубликованы на Zenodo, их можно повторить.

Почему Rust, если и так быстро

В сообщении Уэямы причин не названо. Из README видно другое: текущий mold требует GCC 10.2 или Clang 16 и написан на C++20, а конкурент wild с самого начала на Rust и на части задач уже догоняет. Переписывание с добавлением линкер-скриптов означает во многом новую кодовую базу, и выбор языка для неё делается один раз. Всё остальное — предположения, и мы их не делаем.

Как включить mold сегодня

Для C и C++ с GCC или Clang достаточно флага компоновки -fuse-ld=mold. Для Rust README предлагает настройку в .cargo/config.toml:

• Проекты с собственными линкер-скриптами (ядра, прошивки, загрузчики) пока остаются на GNU ld; ждите mold 3.0.
• Если пользуетесь wild, сравните на своём проекте: на M1 Ultra он выигрывает лишь в части тестов, по общей медиане бенчмарка mold быстрее в 1,9 раза.
• mold распространяется под лицензией MIT через GitHub и пакеты дистрибутивов; наличие пакета в репозиториях Astra Linux и РЕД ОС проверяйте отдельно, в README они не перечислены.

Что дальше

mold используется в проде с 2021 года, и текущая C++-версия никуда не денется до выхода 3.0. Следить стоит за двумя сигналами: появится ли в репозитории ветка на Rust с первыми тестами линкер-скриптов и объявит ли какой-нибудь дистрибутив о планах сделать mold линкером по умолчанию. Второе и будет настоящей новостью.

Источники: Сообщение Руи Уэямы в X, Репозиторий mold с бенчмарками

Изображение на обложке: Tproger по данным README mold

Тема получила новый импульс после серии публикаций Диона Доктера (Dion Dokter) из голландской компании Tweede golf. Во второй части он заглядывает внутрь rustc и утверждает: async Rust так и не вышел из состояния MVP. Я не буду дословно переводить его рассуждения, а переосмыслю их с упором на практику: как понять, платите ли вы за async-удобство лишними байтами, и как снизить налог, пока компилятор не научился делать это сам.

• Асинхронный Rust компилируется в state machine: на каждую await-точку приходится отдельное состояние плюс служебные Unresumed, Returned и Panicked.
• Простая функция с двумя await-точками даёт 360 строк MIR против 23 у синхронного кода. Часть излишков LLVM убирает, но не все, особенно при оптимизации по размеру.
• Компилятор не схлопывает идентичные состояния, не инлайнит futures через await, генерирует state machine даже для async-блоков без await и оставляет panic-путь в состоянии Returned.
• В release-сборках замена panic в Returned на возврат Pending может сократить прошивку на 2–5%. Убирание state machine у пустых async-блоков — ещё около 0,2%.
• Пока rustc не исправлен, можно вручную: возвращать impl Future из «прозрачных» функций, использовать std::future::ready, схлопывать await-точки через match и передавать большие данные по ссылке.

Почему async-функция — это всегда state machine

Когда вы пишете async fn, компилятор не просто оборачивает тело в callback. Он строит конечный автомат: enum, где каждый вариант — состояние между await-точками. Это называется coroutine desugaring и происходит на уровне MIR (Mid-level IR) — до того, как код попадает в LLVM.

Рассмотрим минимальный пример. Есть две функции, каждая из которых просто возвращает число, и третья складывает результаты:

У bar две await-точки, поэтому минимум два пользовательских состояния. Но если сдампить MIR после прохода coroutine_resume, картина шире:

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

Логика корректная, но цена высокая: bar порождает 360 строк MIR, а эквивалентный синхронный код — 23. В 15 с лишним раз больше. LLVM часть этого выбросит, но на opt-level = "z" или в толстых async-графах вызовов он быстро сдаётся.

Четыре места, где компилятор работает вхолостую

1. Panic в состоянии Returned

Контракт future требует только отсутствия UB. Паниковать при повторном poll — не обязательно. Можно просто вернуть Pending снова: ничего опасного не произойдёт, а ветка panic — это лишний побочный эффект, который плохо оптимизируется.

Дион сделал экспериментальный патч rustc: в release-режиме Returned больше не паникует. На embedded-прошивках это дало 2–5% экономии бинарного размера. В debug-сборках панику можно оставить, чтобы быстро ловить ошибочный повторный poll, — по аналогии с overflow-checks.

2. State machine без await

Взгляните на функцию без единой await-точки:

Идеальная реализация — всегда возвращать Poll::Ready(5) безо всякого enum. А rustc генерирует полноценный CoroutineLayout с тремя служебными состояниями и switch по дискриминанту. Такие функции часто появляются в трейтах, где один интерфейс должен быть async, но конкретная реализация ничего не ждёт. Патч, убирающий state machine у async-блоков без await, даёт ещё 0,2% размера — мало, но правка тривиальная.

3. Futures не инлайнятся через await

Классический шаблон: адаптер просто пересылает вызов вниз.

Сейчас bar получает собственный state machine, который вызывает state machine foo. Вручную мы бы написали fn bar(blah) -> impl Future { foo(blah) } и избавились бы от лишнего enum. Аналогично с преамбулой и постамбулой: их можно перенести на FutureExt::map из крейта futures.

4. Одинаковые состояния не схлопываются

Если в async-функции несколько веток match ведут к одинаковому await, компилятор создаёт отдельное состояние на каждую ветку:

Здесь send_response вызывается с разными аргументами, но структура состояний дублируется. Если вынести выбор аргумента за await, получится одно состояние вместо двух:

В одном примере из статьи MIR сокращается с 456 до 302 строк, а ассемблер — примерно на 11%. Оптимизации stack, поэтому выигрыш в реальном коде может быть заметнее.

Что делать сегодня, не дожидаясь rustc

Всё перечисленное выше — это работа для команды компилятора. Но релиз с этими патчами может занять месяцы, а то и годы. Пока он не вышел, можно снизить async-bloat в своём коде.

Главный принцип: каждый лишний async fn — это лишний state machine. Если функция не содержит await, не делайте её async.

Заменяйте async-пустышки на impl Future

Типичный случай — трейт, где одна реализация реально ждёт ввода-вывода, а другая просто возвращает значение.

Вместо полноценного state machine получается готовая future, которая сразу возвращает Ready. Это особенно полезно в embedded-HAL, где трейты часто async, но конкретный драйвер может делать только прямой доступ к регистрам.

Прозрачные обёртки без await

Если функция только пересылает await вниз, уберите await:

Схлопывайте await-точки

Если несколько веток match заканчиваются одним и тем же await, вынесите выбор аргументов наружу. Это уменьшает число состояний state machine и облегчает жизнь LLVM.

Передавайте большие данные по ссылке

Async-функция захватывает в state machine всё, что живёт через await. Если передать массив по значению, он окажется внутри future целиком:

Разница в 52 раза по размеру future — и это без учёта memcpy, который компилятор вынужден вставлять при перемещении больших значений.

Перспективы: Project Goal и финансирование

Дион оформил эти идеи как Rust Project Goal — формальный механизм, через который команды заявляют цели на полугодие. По его оценке, работа требует порядка €30 000 финансирования. Для компиляторного проекта это скромная сумма: речь идёт о 2–5% размера прошивки практически в любом async-проекте.

Есть и другой подход к той же проблеме: не убирать state machine на входе, а научить LLVM лучше их оптимизировать на выходе. Дион считает, что оба направления дополняют друг друга. Чем проще state machine попадает в LLVM, тем эффективнее её можно проинлайнить и упростить на поздних проходах.

Выводы

Async Rust never left the MVP state. The compiler generates state machines with a lot of unnecessary baggage. With a few targeted optimizations in rustc we can get smaller binaries and better performance for everyone.

Утверждение «async Rust так и не вышел из MVP» звучит резко, но поясняет, почему наши «zero-cost» абстракции иногда всё-таки стоят дорого. Компилятор делает корректный, но не оптимальный код: лишние panic-ветки, неинлайненные futures, дублирующиеся состояния и state machine там, где они не нужны.

Для embedded и WASM это не абстрактная проблема, а конкретные килобайты прошивки. Пока rustc учится, разработчик может снизить налог вручную: убирать async у функций без await, возвращать impl Future из прозрачных обёрток, схлопывать await-точки и не передавать большие структуры по значению.

Если ваш проект на Rust бьётся о лимит flash, имеет смысл посмотреть на async-граф вызовов свежим взглядом. Часто проще убрать одну лишнюю async-обёртку, чем месяцами ждать патч в компиляторе.

Источники:
— Dion Dokter, «Async Rust never left the MVP state»;
— Dion Dokter, «Debloat your async Rust»;
— Rust Project Goal: Async state machine optimisation.

Это не дословный перевод, а авторский разбор на основе исследования Nicolas Laurent (norswap), дополненный практическими примерами для enterprise-разработки на TypeScript.

Что такое вывод типовых переменных

В TypeScript, когда вы вызываете функцию с дженериком function foo<T>(x: T), компилятор должен понять, чему равен T. Этот процесс называется type variable inference — выводом типовой переменной. Он происходит в две фазы: сначала TypeScript собирает «кандидатов» из типов аргументов и контекста возврата, а затем «сворачивает» список кандидатов в единственный тип.

Звучит просто, но на практике алгоритм полон тонкостей: covariant и contravariant позиции, приоритеты кандидатов, странное поведение пересечений и неочевидные ограничения. Разберём всё по порядку.

TypeScript выводит типовые переменные в две фазы: сбор кандидатов из аргументов и контекста, затем свёртка списка в единственный тип.

Кандидаты делятся на ковариантные (выходные позиции) и контравариантные (входные позиции); контравариантный результат обычно побеждает.

При свёртке TypeScript ищет общий супертип в списке кандидатов, но никогда не выбирает тип, которого нет в списке.

Пересечения типов ведут себя непредсказуемо: иногда TypeScript «снимает» литеральный тип, иногда захватывает весь объект.

В generic-контексте условные типы (extends ? :) не вычисляются, что ломает инференс через Exclude и подобные утилиты.

NoInfer<T> (с TypeScript 5.4+) позволяет блокировать вывод типа из конкретной позиции — полезно для API со значениями по умолчанию.

Фаза 1: сбор кандидатов

Когда TypeScript видит вызов функции с дженериком, он сопоставляет типы аргументов (source types) с типами параметров функции (target types). Каждый раз, когда «прогулка» по типам доходит до «голого» type parameter в target, соответствующий source type записывается как кандидат.

Ковариантные и контравариантные кандидаты

Кандидаты собираются в два списка. Если type parameter находится в позиции аргумента функции или возвращаемого значения — это ковариантный (output position) кандидат. Если type parameter находится в позиции параметра callback-функции — это контравариантный (input position) кандидат.

Условные типы и infer

Когда TypeScript встречает условный тип, кандидаты собираются только из той ветки, которая теоретически может сработать. Но важно: само условие не добавляет кандидатов. Запись T extends Foo НЕ добавляет Foo как кандидат для T.

Это классическая ловушка: кандидаты собираются из одной ветки, а типовая проверка — из другой. TypeScript не вычисляет условные типы на этапе инференса.

Распределение по union

Если source type — union, а target — не «голый» type parameter, TypeScript проходит по каждой ветке union отдельно и собирает кандидатов из всех веток в один список.

Что НЕ учитывается при сборе

• Условие условного типа (только ветки).
• Constraints (<T extends Foo>) — они проверяются позже, на этапе разрешения.
• Дефолтные значения type parameter (<T = unknown>) — используются только если список кандидатов пуст.
• Супертипы source type.

Фаза 2: разрешение кандидатов

После сбора TypeScript сворачивает каждый список в единственный тип. Алгоритм зависит от вариантности и содержимого списка.

Ковариантные кандидаты

1. Если все кандидаты — литералы одного базового типа, они объединяются в union.
2. Иначе ищется кандидат, который является строгим супертипом всех остальных. Если найден — он выбирается.
3. Если нет — выполняется left-reduce: начинаем с первого кандидата, идём по списку, заменяя текущий на супертип, если встречаем его.

Важно:
Если в списке кандидатов нет общего супертипа, TypeScript выбирает первый элемент. Это частая причина неожиданных ошибок при передаче разнородных аргументов одного дженерика.

Контравариантные кандидаты

Для контравариантных кандидатов логика зеркальная: ищется общий подтип, иначе — left-reduce с подтипами. Если оба списка (ковариантный и контравариантный) непусты, контравариантный результат обычно побеждает — за исключением случаев, когда ковариантный результат является подтипом контравариантного.

Приоритеты кандидатов

Каждый кандидат помечается приоритетом. Кандидат с более высоким приоритетом стирает все кандидаты с более низким приоритетом. Основные приоритеты: None (0), NakedTypeVariable (1), MappedTypeConstraint (32), ReturnType (128), LiteralKeyof (256).

Приоритеты MappedTypeConstraint, ReturnType и LiteralKeyof — «комбинационные»: при них результатом становится union или intersection всех кандидатов, а не единственный тип.

Пересечения: загадочное поведение

Одно из самых неинтуитивных мест — вывод через пересечения. Рассмотрим несколько примеров.

Почему так? Это эвристики компилятора, направленные на максимизацию полезности захваченного типа. В первом случае полезнее получить весь объект, во втором — сохранить литеральную точность строки. Порядок операндов пересечения не влияет на результат.

Вывод в generic-контексте

Когда инференс происходит внутри другой generic-функции, условные типы не могут быть вычислены, потому что type variables ещё не связаны. Это ломает паттерны вроде Exclude, если вызывать их через generic-обёртку.

В типовых enterprise-проектах, где активно используются типовые утилиты для валидации API (например, в проектах на NestJS или с Zod), это ограничение часто приводит к необходимости явно прописывать generic-аргументы или реструктурировать типы.

NoInfer: как управлять выводом

Начиная с TypeScript 5.4, в языке есть встроенный вспомогательный тип NoInfer<T>. Он блокирует сбор кандидатов для T из той позиции, где используется NoInfer<T>.

Это особенно полезно в библиотечном коде, где нужно разделить «источник истины» для вывода типа и позиции, которые должны ему подчиняться.

FAQ

Выводы

Теперь вы знаете, как TypeScript выводит типы переменных: через сбор кандидатов из аргументов, свёртку списка с учётом вариантности и приоритетов, а затем проверку результата на соответствие constraints. Алгоритм вывода типовых переменных — это тщательно продуманная, но не лишённая сюрпризов система. Две фазы (сбор и разрешение), вариантность, приоритеты и эвристики для пересечений создают поверхность, которую сложно угадать интуитивно, но которую можно понять, зная правила.

Ключевые практические выводы для разработчиков:

1. Если функция принимает несколько аргументов одного дженерика — убедитесь, что они совместимы, иначе TypeScript выберет первый кандидат и отвергнет остальные.
2. Не полагайтесь на супертипы для инференса: они не попадают в список кандидатов.
3. В generic-контексте условные типы «замораживаются» — проектируйте API с этим ограничением.
4. Используйте NoInfer<T> в библиотечном коде для точного контроля над источниками вывода типов.
5. При странном поведении с пересечениями — перепишите типы явно или добавьте constraint.

Понимание алгоритма вывода типовых переменных позволяет писать более надёжные типовые абстракции и тратить меньше времени на отладку сложных generic-конструкций.

Источники:

• How TypeScript infers type variables — Nicolas Laurent (norswap)
• How TypeScript distributes unions — Nicolas Laurent (norswap)
• TypeScript Handbook: Generics

Если у вас есть примеры неожиданного поведения TypeScript с дженериками — делитесь в комментариях. Соберём коллекцию «типовых загадок» вместе.

Вы знаете, что a + b * c + d вычисляется как a + (b * c) + d. Но как объяснить это машине? Как закодировать правила приоритета операторов так точно, чтобы парсер сам правильно строил дерево разбора?

Pratt parsing — элегантный алгоритм, придуманный Воном Праттом в 1973 году. Он лежит в основе парсеров многих современных языков, но его описания часто сводятся к магическим таблицам приоритетов без объяснения, почему это работает. Эта статья строит интуицию с нуля.

— AST — основная структура данных: оператор над операндами, вычисление снизу вверх.

— Приоритет операторов определяет наклон дерева: выше приоритет — глубже в дерево.

— При падении приоритета алгоритм поднимается по «хребту» дерева — это и есть суть Pratt parsing.

— Левая и правая ассоциативность задаются через LBP и RBP (left/right binding power).

— Полный парсер с поддержкой всех операторов — около 10 строк на Python.

Абстрактное синтаксическое дерево

Наиболее распространённое решение для разбора выражений — абстрактное синтаксическое дерево (AST, Abstract Syntax Tree). В AST каждый оператор стоит над своими операндами. Вычисление идёт снизу вверх: сначала обрабатываются дочерние узлы, затем операция над ними.

Для выражения a + b * c + d правильное AST выглядит так:

Узел * находится глубже, чем +, — это и отражает более высокий приоритет умножения. При вычислении сначала перемножаются b * c, результат складывается с a, затем прибавляется d.

Как приоритет влияет на форму дерева

Здесь кроется главная интуиция Pratt parsing. Приоритет операторов напрямую определяет, в какую сторону «наклоняется» дерево:

• Убывающий приоритет (например, * + ==) — дерево наклонено влево: операторы с большим приоритетом оказываются глубже.
• Возрастающий приоритет (например, == + *) — дерево наклонено вправо.
• Равный приоритет — по соглашению левая ассоциативность, дерево наклоняется влево.

Рассмотрим промежуточное состояние разбора. Пусть мы уже построили дерево I для выражения (a > b + c * d) — это правонаклонное дерево: > наверху, * в самом низу.

Теперь встречаем следующий оператор. Куда вставить новый узел? Зависит от приоритета:

• [I] * e — приоритет * не меньше приоритета * в дереве, вставляем в самый глубокий узел.
• [I] + e — приоритет + ниже *, но выше >, поднимаемся по хребту выше узла *.
• [I] == e — приоритет == ниже всего дерева, всё дерево I становится левым потомком.

Ключевое наблюдение: когда встречается оператор с меньшим приоритетом, мы поднимаемся по правому хребту дерева, собирая узлы с более высоким приоритетом. Это и есть Pratt parsing — алгоритм, который реализует именно этот подъём по хребту.

От интуиции к коду

Начнём с простого случая — правонаклонного дерева. Каждый оператор правоассоциативен, приоритет не учитывается:

Здесь leaf() читает следующий терминал (число или переменную), peek() смотрит на текущий токен без продвижения, advance() читает и сдвигает позицию.

Добавляем приоритет. Рекурсивный вызов передаёт приоритет текущего оператора как порог — это ограничивает, какие операторы следующий уровень может «захватить»:

Это уже работает для правоассоциативных операторов. Но у нас if — разобрали один оператор и вышли. Для левоассоциативных нужен цикл:

Полный Pratt parser

Замена if на while — это и есть процедура подъёма по хребту дерева. Цикл продолжается, пока следующий оператор имеет достаточно высокий приоритет, чтобы «захватить» левую часть. Как только приоритет падает — выходим, и текущее поддерево передаётся вверх по стеку вызовов.

Правая ассоциативность через binding power

До сих пор у нас одно число приоритета на оператор. Но для управления ассоциативностью нужно различать, насколько «сильно» оператор притягивает операнды слева и справа. Вводятся два понятия:

• LBP (left binding power) — сила притяжения левого операнда.
• RBP (right binding power) — сила притяжения правого операнда.

Правила ассоциативности через binding power:

• Левоассоциативные операторы (+, *): LBP == RBP. Правый рекурсивный вызов получает тот же приоритет — следующий оператор с таким же приоритетом не захватывается, строится левое дерево.
• Правоассоциативные операторы (**, =): RBP = LBP − 1. Правый рекурсивный вызов получает чуть меньший приоритет — следующий оператор с таким же приоритетом захватывается, строится правое дерево.

Это финальная версия Pratt parser. Всего 8 строк кода — и корректный разбор всех операторов с любым приоритетом и ассоциативностью.

Итог

Pratt parsing — не хитрый трюк, а следствие простой геометрической интуиции. Деревья разбора наклоняются влево или вправо в зависимости от приоритета операторов. Когда встречается оператор с меньшим приоритетом, алгоритм поднимается по правому хребту текущего дерева — ровно настолько, насколько нужно.

Ключевые детали реализации:

• while вместо if — реализует подъём по хребту для левоассоциативных операторов.
• Передача приоритета в рекурсию — ограничивает, какие операторы «захватываются» на следующем уровне.
• LBP / RBP — контролируют ассоциативность через разницу в единицу.

Понимание этой геометрии делает Pratt parsing прозрачным: каждая строка кода отражает конкретное геометрическое действие с деревом, а не магию таблиц приоритетов.

По его словам, нейросеть сможет делать это даже эффективнее традиционных компиляторов.

Звучит громко. Но если разобрать тезис технически, все не так однозначно.

Что именно предлагает Маск

По словам миллиардера, вместо привычной цепочки «исходный код → компилятор → бинарник», ИИ будет получать задачу и сразу выдавать исполняемый файл. Без промежуточного слоя в виде читаемого кода.

Фактически это означает отказ от исходников как основного артефакта разработки. Промпт на входе, а .exe или ELF на выходе.

Почему это спорно с технической точки зрения

Компиляторы — это детерминированные системы. Они проверяют синтаксис и типы, строят промежуточное представление программы, применяют оптимизации и гарантируют воспроизводимый результат.

Один и тот же код при одинаковых условиях дает один и тот же бинарник.

LLM работают иначе: они генерируют вероятностный результат. Малейшая ошибка в бинарнике приведет к падению программы или трудноуловимому багу.

В отличие от исходного кода, бинарный файл невозможно нормально ревьюить, сравнивать в Git или проверять на уровне логики.

Кроме того, компиляция стоит дешево — это миллисекунды CPU. Генерация крупных бинарников через LLM потребовала бы миллионов токенов и значительно больших вычислительных затрат.

Где ИИ действительно меняет разработку

На фоне громких заявлений Маска, многие как будто забыли, что ИИ уже активно используется в программировании. Но в другом формате. Технология помогает писать исходный код, объяснять сложные участки, генерировать тесты, предлагать рефакторинг.

А дальше в дело все равно вступает компилятор — как проверяемый и предсказуемый этап.

Более реалистичный сценарий — улучшение компиляторов с помощью ИИ, а не их замена. Например, автоматический подбор оптимизаций или более агрессивная векторизация.

Об этом он рассказал в интервью на Open Source Summit в Сеуле.

«Я уже 20 лет не программист»

Торвальдс признался, что своей основной задачей давно не считает написание кода:

«Около 20 последних лет я не программист. Я смотрю на Git со стороны, а в ядре моя роль — соглашаться или отказывать».

Он отметил, что все чаще приходится «говорить да» новым идеям, несмотря на сопротивление старых мейнтейнеров. Это можно заметить, например, в вопросе интеграции Rust в ядро Linux.

Что он думает об ИИ и разработке

Несмотря на то, что сам Линус не пользуется ИИ-ассистентами, он не исключает, что такие инструменты могут пригодиться в ядре. Основная проблема ИИ сейчас, по его словам — не код, а инфраструктура:

«ИИ-краулеры сильно захламляют наши ресурсы, притаскивают баги и репорты, которых не существует».

При этом Торвальдс позитивно оценивает влияние ИИ-бума на индустрию: из-за него NVIDIA стала «значительно более хорошим игроком» в Linux-сообществе.

А что с вайб-кодингом?

Именно здесь Линус удивил больше всего. Он сказал, что относится к вайб-кодингу «довольно позитивно», потому что он:

• облегчает вход в программирование для новичков;
• позволяет увидеть быстрый результат;
• снижает технический порог для тех, кто раньше не мог «заставить компьютер что-то делать».

Но использовать это в реальных проектах — гиблая идея:

«Это может быть ужасным решением с точки зрения поддержки».

По мнению Торвальдса, вайб-кодинг — отличная «точка входа», но плохой фундамент для сложных систем вроде ядра Linux.

Вердикт Линуса

Он видит ИИ как обычный инструмент — как когда-то компиляторы, которые избавили разработчиков от необходимости писать код ассемблера вручную:

«ИИ не убьет профессию. Как и компиляторы, он просто повысит продуктивность».

Cloudflare связала учащение «фатальных паник» на arm64 с кодом, где выполнялась работа с Netlink, но корневая причина оказалась глубже — в связанке компилятор ↔ ассемблер Go для arm64 и в том, как разбивалось большое смещение стека на две инструкции ADD со «сдвигом на 12 бит». Если прерывание попадало между этими двумя ADD, стековый указатель оказывался «наполовину скорректирован», и трассировщик стека считывал нерелевантные данные как адрес возврата, что заканчивалось segfault/фатальной паникой. Схожие аварии ранее отмечали и другие команды, в частности Datadog: именно в runtime.(*unwinder).next на Linux/arm64 (Go 1.23.x/1.24.x).

Что именно ломалось

• Сценарий сбоя: асинхронная предвыборка (preemption) попадает между двумя инструкциями корректировки SP (split ADD), после чего GC/трассировка начинают разворачивать некорректный фрейм, обращаясь по невалидному SP. Итог — падение в (*unwinder).next.
• Подтверждение на практике: сходные трассы стеков и «рандомные» крэши на arm64 фиксировались у сторонних команд; проблема оформлена в ишью #73259 в репозитории Go и была признана кандидатом на бэкпорт.

Как починили (и какие версии содержат фикс)

Исправление прошло через бэкпорт и доступно в поддерживаемых ветках Go:

• Go 1.24.6 — явное упоминание бэкпорта по ишью #73259.
• Go 1.23.12 — минор с правками рантайма (включая бэкпорт по связанным arm64-сбоям).
• Go 1.25.0 и новее — фиксация на мажорной ветке.

Суть изменения: вместо двух поочерёдных ADD для большого смещения теперь собирают оффсет в временный регистр и выполняют одну атомарную корректировку SP.

Это исключает «окно» между ADD-инструкциями и делает разворачивание стека предсказуемым даже при async preemption. (Подробные обсуждения и сопутствующие arm64-проблемы рантайма см. также в #63830, #65449, #73413.)

Кому это важно

• Все сервисы Go на arm64, где возможны большие стековые фреймы и активна асинхронная предвыборка (по умолчанию с Go 1.14+). В условиях продакшн-нагрузок редкая гонка становится статистически вероятной. Читайте подробнее: https://unskilled.blog/posts/preemption-in-go-an-introduction/

Что делать инженерам прямо сейчас

1. Обновиться до: Go 1.25.x или минимум до 1.24.6 / 1.23.12 (если «зажаты» веткой).
2. Пересобрать сервисы, критичные по доступности, и раскатить обновления в первую очередь на arm64-инфраструктуру.
3. Если апгрейд временно невозможен — минимизируйте большие стек-фреймы (вынос больших буферов в heap), снизьте вероятность попадания preemption в эпилог и проверьте зависимости на предмет собственного asm/unsafe-кода.
4. Отслеживайте релизы Go и связанные тикеты об unwinding/arm64 (см. #73259 и бекпорт #74694).

Источники и материалы:

• Обсуждение с примерами падений: runtime: segfaults in runtime.(*unwinder).next (GitHub, #73259).  https://github.com/golang/go/issues/73259
• Бэкпорт фикса в ветку 1.24: (GitHub, #74694) — релиз Go 1.24.6. https://github.com/golang/go/issues/74694
• История релизов, минор Go 1.23.12 с правками рантайма. https://go.dev/doc/devel/release
• Release notes Go 1.25 (фикс присутствует в мажорной ветке).  https://tip.golang.org/doc/go1.25
• Ранние разборы проблем разворачивания стека/прерываний на arm64 https://github.com/golang/go/issues/63830

Новый стандарт 3.0 уже поддерживается большинством современных браузеров и приносит сразу несколько ключевых нововведений.

Главное из нововведений

• 64-битная адресация: теперь Wasm может использовать i64 вместо i32, что расширяет лимит адресуемой памяти с 4 ГБ до 16 ЭБ (в реальности — до 16 ГБ в браузерах).
• Несколько областей памяти: модули теперь могут напрямую использовать и копировать данные между разной памятью, без обходных трюков с импортом других модулей.
• Сборка мусора (GC): добавлена поддержка управляемой памяти для языков с автоматическим управлением памятью (например, Java, Scala, Kotlin, Dart).
• Типизированные ссылки: улучшенная типизация ссылок и функций позволяет избежать лишних проверок в рантайме.
• Исключения: наконец-то появилась полноценная система обработки исключений — с try, throw и catch, как в других языках.
• Хвостовые вызовы: позволяют не занимать стек при возврате через вызов, что критично для функциональных языков и оптимизаций.
• Расслабленные SIMD-инструкции: добавлены быстрые, но менее детерминированные версии векторных инструкций для повышения производительности.
• Детерминированный профиль: теперь для задач с требованием полной воспроизводимости (например, блокчейны) можно включить строго определенное поведение операций.
• Аннотации в тексте: появилась возможность вставлять пользовательские аннотации прямо в текстовый формат .wat.

Что это значит

WebAssembly становится всё ближе к полноценной виртуальной машине для высокоуровневых языков. В новой версии уже появляются компиляторы для Java, OCaml, Scala и прочих ЯП — благодаря поддержке GC и исключений.

Новый стандарт уже поддерживается в основных браузерах, включая Chrome и Firefox. Независимые движки, такие как Wasmtime, тоже догоняют.

WebAssembly в браузере: как всё начиналось

Прежде чем говорить о настоящем и будущем WebAssembly, вспомним, с чего он начинался. Технология создавалась исключительно для работы в браузере. WebAssembly использовался (и используется сейчас): для оптимизации производительности, миграции legacy-нативных приложений, запуска кода на языках, отличных от JavaScript.

Ярче всего успех этого подхода демонстрирует Figma — популярный редактор для дизайнеров интерфейсов. Для многих стало неожиданностью, что редактор Figma, будучи веб-приложением, написан на C++.

Александр Коротаев, фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

На заре появления WASM многие ошибочно считали его то ли машиной для ускорения JS, то ли нативным модулем, который имеет доступ к операционной системе. Буквально чудо-коробочка, в которую можно поместить весь код, и он станет быстрее в три раза. Но в реальности технология столь ограничена в применении, что она до сих пор остается нишевой, хотя и очень перспективной.

До WebAssembly разработчики Figma использовали технологию asm.js — предшественника WASM. Специальный компилятор преобразовывал (транспилировал) код C++ в высокооптимизированный JavaScript, который браузерные движки могли выполнять с близкой к нативной производительностью. У этого подхода были недостатки: большой размер получаемого кода и затраты на его парсинг и компиляцию в браузере.

Переход на WebAssembly стал переломным моментом. Поскольку WASM — это бинарный машинно-ориентированный формат, он гораздо компактнее и требует меньше ресурсов для обработки браузером. В результате миграции с asm.js на WebAssembly, Figma получила трёхкратный прирост производительности.

Этот кейс наглядно показал, что WebAssembly — это не просто ещё одна веб-технология, а настоящий прорыв, который стирает границы между нативными и веб-приложениями. Успех Figma и подобных проектов заложил фундамент для следующего логического шага: если WebAssembly так эффективен в браузере, почему бы не запускать его где угодно?

Почему WebAssembly выходит за пределы браузера

WebAssembly изначально создавался как безопасная, эффективная и портируемая платформа для компиляции высокоуровневых языков. Ключевые преимущества этого инструмента — изоляция выполняемого кода, платформонезависимость и высокая производительность — оказались востребованы не только в вебе.

Серверные и встроенные системы долгое время страдали от проблем совместимости, безопасности и сложности распространения кода. Традиционные подходы к изоляции (например, контейнеризация) требуют значительных ресурсов и не всегда дают достаточный уровень безопасности. WebAssembly предлагает альтернативу: песочницу с минимальными накладными расходами и встроенными механизмами безопасности.

Главным катализатором этого процесса стал стандарт WASI (WebAssembly System Interface), разработанный при участии Mozilla, Fastly и других компаний. WASI предоставляет стандартизированный интерфейс, где WebAssembly-модули взаимодействуют с операционной системой и решают проблему переносимости между различными платформами.

Александр Коротаев, фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

Открытая «кроссплатформенная» обертка WASI — это довольно большой прорыв в разработке, так как в текущем состоянии все современные продукты, выпускающиеся для разных ОС с одной кодовой базой, имеют большие, подчас legacy модули совместимости, или же запускаются внутри особых песочниц, сильно увеличивающих размер бандла. Например, браузерный движок Electron или React Native.

Как WebAssembly работает вне браузера

Вне браузера WebAssembly исполняется в специальных средах выполнения (runtimes), которые взаимодействуют с операционной системой через WASI. Известные примеры — Wasmtime от Mozilla, Lucet от Fastly и Wasmer.

Эти среды выполняют роль «концептуальной операционной системы», предоставляют модулям WebAssembly стандартизированный доступ к системным ресурсам: файлам, сети, случайным числам и другим функциям.

WebAssembly принципиально отличается от традиционных подходов тем, что изолируется на уровне инструкций, а не процессов. Каждый модуль выполняется в собственной песочнице с чётко определенными границами доступа к ресурсам. Это значительно снижает риск компрометации системы даже в случае уязвимостей в самом коде.

Безопасность как фундаментальное преимущество

Безопасность WebAssembly основана на нескольких уровнях защиты. Модули выполняются в изолированной среде, отделённой от хост-системы с помощью техник изоляции отказов. Это означает, что приложения выполняются независимо и не могут покинуть песочницу без явного разрешения через API.

Система контролирует выполнение кода с помощью статической проверки типов — все функции нужно явно объявлять перед использованием. Даже косвенные вызовы проверяются на соответствие сигнатурам прямо во время работы программы. Такой подход блокирует распространённые атаки — переполнение буфера и внедрение вредоносного кода.

Память в WebAssembly изолирована — напрямую с ней работать нельзя. Когда система обращается к памяти, она проверяет границы доступа, а локальные переменные хранятся в защищённом стеке вызовов.

Важность такого подхода к безопасности сложно переоценить в свете общих трендов защиты данных. К 2025 году безопасность и конфиденциальность стали ключевыми приоритетами для индустрии. Это особенно актуально на фоне растущих рисков при работе с большими языковыми моделями (LLM), которые могут невольно запоминать и воспроизводить конфиденциальные данные из тренировочных наборов.

Если запускать изолированные модули WebAssembly на своей инфраструктуре вместо публичного облака, можно безопасно обрабатывать чувствительные данные без риска утечки.

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

Здесь явно подчеркивается безопасность платформы из коробки, но не стоит забывать, что на разработчике все еще лежит ответственность за безопасность данных и пользователей. Режим «разрешить все» — стандарт для любого MVP, и без аудита перед релизом тут все еще не обойтись. Платформа лишь гарантирует, что память процесса будет защищена от несанкционированного доступа, что уже давно делается во всех популярных операционных системах. Чтобы выйти за пределы стека или прочитать чужую память, надо использовать очень старые компиляторы или сильно низкоуровневые средства разработки.

Серверные применения WebAssembly

Серверный ландшафт традиционно строился на монолитных приложениях и виртуальных машинах, но сегодня индустрия движется к более легковесным и изолированным компонентам. WebAssembly предлагает компромисс между производительностью нативного кода и безопасностью интерпретируемых сред. Эта технология особенно востребована в сценариях, где критически важны быстрое масштабирование и минимальное время запуска.

Микросервисы и бессерверные архитектуры

WebAssembly идеально подходит для микросервисных архитектур благодаря легковесности и быстрому запуску. В отличие от традиционных контейнеров, WASM-модули не требуют отдельной ОС и запускаются за миллисекунды.

Кейс: компания Fastly использует WebAssembly для исполнения пользовательского кода на серверах. Их технический директор Тайлер МакМаллен отмечает: «Мы рассматриваем WebAssembly как платформу для быстрого и безопасного кода в облаке на границе сети».

Безопасные расширения приложений

Многие приложения позволяют пользователям запускать собственный код через плагины и расширения. Но это создаёт риски для безопасности. В WebAssembly пользовательский код выполняется с минимальными рисками.

Веб-сервер Angie использует WASM для безопасности пользовательских модулей. Это решает проблему совместимости, характерную для традиционных модулей, написанных на C.

Экономическая эффективность таких вариантов становится решающим фактором. По данным на 2025 год, глобальный рынок больших языковых моделей (LLM), чьи backend-системы часто используют микросервисные архитектуры, демонстрирует колоссальный рост. Прогнозируется, что к 2033 году он достигнет $140,8 млрд.

Для таких масштабов нужны технологии с качествами, которые как раз предоставляет WebAssembly: безопасность, переносимость и эффективное использование ресурсов. Почти все компании из списка Fortune 500 уже используют генеративный ИИ в своих бизнес-процессах, и для многих из них WebAssembly — ключевой инструмент для развёртывания и масштабирования этих рабочих нагрузок.

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

Здесь все закономерно: бизнес всегда выбирал решения, где можно было написать код один раз и поставить его сразу на несколько платформ. Даже если сами решения сырые и небезопасные, дешевле было увеличить поддержку пользователей и настроить аудит безопасности, чем реализовать фичу для каждой платформы отдельно. Так на рынок вышли Python, Node.js, React Native, стремительно обгоняя конкурентов за счет скорости разработки.

WebAssembly в embedded-системах

WebAssembly успешно работает на серверах, но главные изменения происходят во встроенных системах. В IoT всегда была проблема совместимости: разные процессоры, операционные системы и периферийные устройства.

Технология предлагает принципиально новый подход — единую бинарную форму, способную работать на любом микроконтроллере с минимальными адаптациями. Теперь разработчики могут не привязываться к конкретным платформам и сосредоточиться на бизнес-логике приложения.

Удаленные интерфейсы и централизованный мониторинг

Производители встраиваемых систем всё чаще нуждаются в удаленных интерфейсах и централизованном мониторинге. WebAssembly позволяет повторно использовать код, написанный для embedded-устройств, в веб-интерфейсах для удалённого управления.

Согласно исследованию Qt Company, более 77% респондентов из промышленной автоматизации считают удалённое управление и централизованный мониторинг критически важными в ближайшие десять лет. WebAssembly предоставляет экономичный способ реализации таких решений.

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

А это, пожалуй, самая продающая фича: обычно у компаний, которые выходят на рынок со своими железками, базами данных и прочими продуктами, все продажи буквально построены на том, что программисты у клиента знают, как это быстро встроить. Так, бизнес готов платить деньги. Обычно у них есть проблемы с API для разных языков программирования, ОС и девайсов: либо хорошо все в JS, а в мобилках не заводится, либо наоборот. А то и вообще: стоит забросить поддержку платформы хоть на полгода, сразу всёперестает работать. Потому поставлять модуль для WASI должно быть дёшево, при этом потенциально можно закрыть даже платформы будущего. Это инновация сродни изобретению стандарта USB.

Прототипирование и сотрудничество

WebAssembly упрощает процесс прототипирования и обратной связи для embedded-устройств. Разработчики могут скомпилировать приложение, разместить его на веб-сервере и предоставить доступ всем заинтересованным сторонам. При этом не нужно распространять устройства или проходить сложные процессы публикации.

Компания Qt использует этот подход в Qt Design Viewer, позволяя разработчикам делиться интерактивными дизайнами, созданными в Qt Design Studio, с коллегами по всему миру.

Примеры внедрения: история ByteFog

Компания Inetra из Новосибирска разработала технологию peer-to-peer для доставки видео ByteFog. Система работает на множестве платформ: Windows, Linux, Android, iOS, Web и Tizen.

Изначально веб-версия использовала Netscape Plugin API, но когда основные браузеры прекратили поддержку этой технологии в 2015 году, компания осталась без веб-версии на два года. Поэтому в 2017 году они обратились к WebAssembly.

Используя компилятор Emscripten, разработчики перенесли существующее C++-приложение в браузер. Главной сложностью было разграничить транспортный слой и бизнес-логику через интерфейсы. Основной канал доставки видео заменили на AJAX, а P2P-слой — на WebRTC.

Результат компиляции — двоичный.wasm-файл и «клеевой код» на JavaScript, взаимодействующий с браузерными API. Это позволило запускать сложную P2P-систему Peers.TV напрямую в браузере без плагинов.

Fastly Terrarium: экспериментальная платформа для WebAssembly-приложений

В 2021 году инженеры Fastly выпустили Terrarium — экспериментальную платформу для запуска WebAssembly-модулей на периферийных устройствах (edge devices), над которой работали несколько лет. Сейчас проект всё ещё в демо-версии.

Terrarium показывает, как можно запускать пользовательский код в изолированных средах с минимальной задержкой. Платформа использует рантайм Lucet, разработанный инженерами Fastly, и поддерживает компиляцию из Rust, C++ и AssemblyScript.

Ключевая особенность подхода — стандарт WASI для системных вызовов, что помогаетпереносить модули между разными средами. Это особенно важно для edge-вычислений, где код должен работать на разнородном оборудовании.

По данным тестирования, время запуска модулей составляет около 50 микросекунд, а потребление памяти измеряется килобайтами на инстанс. Такие показатели достигаются за счёт изоляции на уровне инструкций, а не процессов.

Хотя Terrarium не стал коммерческим продуктом, его наработки повлияли на другие решения Fastly. Компания развивает направление WebAssembly-вычислений далее — экосистема постоянно обновляется.

Технические вызовы и ограничения

Несмотря на впечатляющие возможности WebAssembly за пределами браузера, технология сталкивается с объективными сложностями в реальных проектах. Разработчикам приходится решать две задачи одновременно: изолировать код для безопасности и при этом давать доступ к системе. Важно также сохранить кроссплатформенность, но не терять в производительности на конкретных устройствах.

Эти компромиссы особенно заметны в embedded-среде, где каждое решение напрямую влияет на энергопотребление, стоимость и надежность системы.

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

А здесь кроется главное: почему такое решение не было написано ранее? Дело в том, что оно явно затратное по ресурсам, если сравнивать ту же логику, написанную на низком уровне. Сейчас любые устройства стали мощнее, чем ранее, и теперь разница уже не так заметна. Поэтому WASI может широко распространяться, без типичных минусов высокоуровневых абстракций: потребления памяти и энергии сильно выше чем у конкурентов.

Доступ к аппаратным ресурсам

WebAssembly ограничивает прямой доступ к аппаратуре во встроенных системах — это плата за безопасность. Это усложняет работу embedded-разработчикам.

Сообщество WebAssembly уже решает проблемы. Стандарт WASI продолжает развиваться, и в будущем появятся более гибкие способы работы с оборудованием.

Размер файлов и производительность

WebAssembly-модули могут иметь значительный размер, особенно при включении стандартных библиотек. В случае ByteFog размер бандла достигал 100 МБ, что создавало проблемы для инструментов сборки и загрузки в браузере.

Чтобы уменьшить размер, нужно тщательно удалять неиспользуемый код и подбирать настройки компиляции. Кроме того, передача данных между хост-системой и WebAssembly-модулем обходится дорого.

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

Тут имеется ввиду краеугольная проблема WASM модулей — ввод и вывод. Дело в том, что он довольно низкоуровневый, и если в случае с микроконтроллерами они буквально будут говорить на «одном языке» с железом, то более высокоуровневые системы, передающие данные в том же JSON, столкнутся с довольно затратным процессом сериализации данных. Чтение строки с английскими буквами это одно, а текст на разных языках — это уже задачка со звездочкой. Так что в случае LLM надо будет серьезно работать надо протоколом обмена данными.

Инструменты и экосистема

Экосистема WebAssembly вне браузера всё ещё развивается. Поддержка различных языков программирования неравномерна: лучше всего дела обстоят у C/C++ и Rust, с интерпретируемыми языками всё сложнее.

Отладка WebAssembly-модулей ограничена в сравнении с традиционными средствами. Разработчикам часто приходится использовать косвенные методы и работать с преобразованным кодом. Это особенно важно в контексте другой быстрорастущей тенденции — переносить выполнение ИИ-моделей с серверов на сами устройства пользователей (edge computing).

Например, современные компактные LLM, такие как Phi-4-mini-flash, демонстрируют впечатляющую производительность на мобильных чипах ARM, обрабатывая запросы за 90–100 мс прямо на устройстве без облака. Для подобных сценариев WebAssembly с его переносимостью и низким потреблением ресурсов выглядит идеальной средой, если сможет предложить более прямой и эффективный доступ к специфическим возможностям железа.

Будущее WebAssembly вне браузера

Перспективы WebAssembly вне браузера выглядит многообещающим. Стандарт WASI совершенствуется, поддерживая новые системные интерфейсы и возможности. Разработчики получают всё более мощные инструменты для создания и отладки WASM-модулей.

В embedded-сфере WebAssembly может стать стандартом для безопасного выполнения кода на различных устройствах IoT (интернета вещей). Его способность работать на ресурсо-ограниченных устройствах при изоляции делает инструмент привлекательной альтернативой традиционным подходам.

Майлз Боринс, технический директор руководящего комитета Node.js, видит потенциал WebAssembly в решении одной из наибольших проблем фреймворка: «Это способ достичь скорости, близкой к нативной, и повторно использовать код, написанный на других языках (C и C++), сохранять портативность и безопасность».

Александр Коротаев, Фронтенд-разработчик, автор ТГ канала «Трудно быть Коротаевым»:

Как я понял, под фундаментальными проблемами имеется в виду ограничение на кол-во операций с потоками и файлами в текущий версиях Node.js, что не дает серверам на «ноде» тягаться с Nginx на равных.

Итоги

WebAssembly превращается из узкоспециализированной веб-технологии в универсальную платформу для выполнения кода. Безопасность, переносимость и производительность WebAssembly делают его эффективным решением для серверных и встраиваемых систем.

У WebAssembly всё ещё есть проблемы с доступом к аппаратным ресурсам и большим размерам модулей. Однако инструменты и стандарты активно развиваются — скорее всего, эти ограничения постепенно устранят.

Для разработчиков WebAssembly открывает новые возможности повторного использования кода и создания безопасных, переносимых приложений. Для индустрии в целом — это шаг к более безопасным и эффективным моделям распределения и выполнения кода.

Как отмечает Шон Уайт, директор Mozilla по R&D: «WebAssembly уже меняет способы доставки людям новых видов привлекательного контента. С WASI преимущества WebAssembly получат больше пользователей и больше устройств в разных местах».

WebAssembly больше не ограничивается браузером — он становится универсальной платформой для среды, где код должен выполняться безопасно и эффективно везде: от облачных серверов до крошечных устройств интернета вещей.

Больше новостей — в нашем тг-канале «Представляешь»

По его мнению, спрос на программистов будет только расти. Да, нейросети берут на себя часть рутины.

Но именно это, считает Макиннон, и позволит инженерам перейти на новый уровень — заниматься не механической работой, а проектированием систем, решением комплексных задач и созданием новых продуктов.

Почему ИИ — не угроза, а шанс

Макиннон провел параллель с прошлым. В 1978 году, когда появились компиляторы, тоже звучали опасения: «Теперь компьютеры будут писать код сами». Но произошло обратное — разработчики стали продуктивнее, индустрия выросла, а программисты остались ключевыми фигурами технологического прогресса.

Сейчас, по его словам, мы наблюдаем похожую ситуацию: ИИ действительно автоматизирует часть задач, но это не убирает потребность в специалистах — наоборот, расширяет её.

Автоматизация рождает еще больший спрос

Макиннон уверен: даже если ИИ помогает создавать код быстрее, это не отменяет необходимость в новых продуктах. А значит — нужны новые программисты. Он приводит простой пример: запуск iPhone не убил рынок приложений, а породил гигантов вроде Snapchat.

По его словам, спрос на автоматизацию и цифровые инструменты бесконечен — и он растёт быстрее, чем скорость, с которой ИИ повышает эффективность.

«Смотрите на цифры, а не на заявления»

Макиннон скептически относится к заявлениям компаний, которые говорят, что больше не будут нанимать инженеров. Например, Google утверждает, что четверть их кода уже пишет ИИ, а Salesforce в этом году не планирует найм разработчиков.

Но глава Okta уверен: это лишь попытка продемонстрировать клиентам эффективность своих ИИ-решений. Он считает, что через год-два эти же компании вернутся к активному найму, потому что спрос на технологии и продукты не замедляется.

Новая волна инженеров

По прогнозу Макиннона, впереди нас ждет «новое поколение программистов», которые будут строить продукты на базе ИИ-инфраструктуры.

Компании вроде Microsoft, Meta, Salesforce и самой Okta продолжат расширять свои инженерные команды — потому что ИИ делает их не менее нужными, а просто другими.

Что такое облачные IDE и почему они важны

Облачные IDE (или онлайн-редакторы кода) позволяют работать над проектом прямо из браузера, без сложной локальной настройки окружения. На сервере уже установлены необходимые инструменты (компиляторы, интерпретаторы), можно быстро переключаться между различными стеками технологий. Это удобно, когда нужно:

1. Быстро протестировать идею или прототип,
2. Работать из любого места и с любого устройства,
3. Обучаться программированию (особенно новичкам, которым сложно настраивать среду разработки),
4. Совместно редактировать код в реальном времени.

Для меня облачные IDE — отличный вариант, когда нужно не заморачиваться с локальной установкой инструментов, а сразу перейти к коду. А ещё они выручают, когда я не хочу загружать ноутбук гигантскими IDE, особенно если машина не слишком мощная.

Replit

Replit был одним из первых облачных решений, с которыми я столкнулся. Он ориентирован на скорость старта: заходишь на сайт, создаёшь «репл» (так называются проекты в Replit), выбираешь язык — и готово. Уже предустановлен интерпретатор или компилятор, можно писать и сразу же запускать программу.

Возможности

• Поддержка множества языков: Python, JavaScript, C++, Java, Go, Rust и другие.
• Встроенный чат с искусственным интеллектом (Ghostwriter) для помощи в написании кода.
• Возможность совместной работы: можно дать ссылку коллеге, и он зайдёт в ваш проект, чтобы вместе отлаживать или рефакторить код.
• Хостинг: Replit умеет публиковать веб-приложения «на живом URL» одним нажатием кнопки.

Плюсы

• Очень простая регистрация и моментальный старт.
• Социальные функции: можно смотреть публичные проекты других пользователей, форкать их и учиться.

Минусы

• Не всегда удобен для серьёзных проектов: базовые настройки окружения ограничены, а для расширенных сценариев нужен платный тариф.
• Интерфейс может работать медленнее, если проект становится большим или инсталляция зависимостей тяжёлая.

Где пригодится

• Отличный вариант для новичков, которые хотят учиться программировать без сложной настройки локальной среды.
• Быстрые прототипы, демонстрации кода на собеседованиях или парное программирование.

CodeSandbox

CodeSandbox ориентирован, прежде всего, на фронтенд-разработчиков. Он замечательно подходит для проектов на React, Vue, Angular, Svelte и других библиотечных и фреймворковых решениях.

Возможности

• Автоматическое создание окружения для фронтенд-проектов: нужен React? Выбираем шаблон — и сразу получаем структуру, файлы конфигурации и пакетный менеджер.
• «Live preview» (живая перезагрузка): при каждом изменении в коде страница в правой части обновляется без перезагрузки.
• Интеграция с GitHub: можно подтянуть репозиторий, внести правки в CodeSandbox, а затем запушить изменения обратно.
• Возможность запускать бэкенд-сервер (через Docker-контейнеры) в отдельных sandboxes.

Плюсы

• Удобно для веб-разработки: всё уже настроено (Webpack, Vite или другие сборщики).
• Поддержка TypeScript из коробки.
• Отлично работает совместное редактирование, есть возможность прямого «шеринга» результатов.

Минусы

• Фокус именно на веб-технологиях, так что для языков, не связанных с фронтендом, CodeSandbox не всегда подойдёт.
• Бесплатные sandboxes могут засыпать при простое, что не всегда удобно для постоянного хостинга.

Где пригодится

• Быстрые демки UI-компонентов или обучающие примеры для фронтенда.
• Когда нужно показать коллегам, как работает тот или иной React-хук, без установки Node.js локально.
• Создание небольшого прототипа веб-приложения в режиме реального времени.

GitHub Codespaces

GitHub Codespaces — по сути, облачное продолжение Visual Studio Code. Если у вас есть репозиторий на GitHub, вы можете открыть его в Codespaces и получить преднастроенную среду разработки прямо в браузере. Это решение особенно нравится разработчикам, которые уже привыкли к VS Code.

Возможности

• Полноценная интеграция с GitHub: открываем репозиторий, создаём Codespace, и всё готово к работе.
• Расширения VS Code в облаке: многие привычные плагины можно установить и использовать.
• Поддержка Docker и Dev Containers: можно создавать контейнеры со своим набором инструментов, чтобы каждый член команды имел идентичную среду.
• Возможность «подцепиться» к Codespaces и локальным VS Code, если хочется работать в офлайне или со своим привычным окружением.

Плюсы

• Знакомая среда для тех, кто пользуется VS Code.
• Гибкий вариант конфигурации (Dev Containers), позволяющий упростить онбординг новых сотрудников.
• Нет проблем с зависимостями: всё хранится в контейнере, поэтому переходить между проектами очень удобно.

Минусы

• Требует платного тарифного плана GitHub, если нужен серьёзный объём ресурсов (хотя есть ограниченное бесплатное время).
• Для маленьких проектов может быть избыточен, так как мощь Codespaces раскрывается больше в средних и крупных командах.

Где пригодится

• Команды, которые живут в экосистеме GitHub, хотят, чтобы любой разработчик мог моментально начать работать с проектом, не тратя часы на установку зависимостей.
• Сложные проекты, где важно гарантировать одинаковую среду для всех.

JetBrains Fleet

Fleet — новый проект от JetBrains, который позиционируется как «умная и быстрая» IDE нового поколения. Предлагается как облачная среда с возможностью локальной установки. JetBrains известны своими тяжёловесными, но очень функциональными IDE (IDEA, PyCharm, WebStorm и т.д.), а Fleet стремится занять более лёгкую нишу с возможностью работать в облаке.

Возможности

• Режим «смарт-редактирования», когда Fleet по мере необходимости подгружает функции анализа кода.
• Распределённая архитектура: можно разворачивать часть Fleet в локальном окружении, часть — в удалённом, чтобы снизить нагрузку на машину.
• Совместное редактирование кода в реальном времени, причём JetBrains обещают, что это будет «ровно, как в Google Docs, только для кода».

Плюсы

• Потенциально более лёгкая, чем классические JetBrains IDE, работает быстрее на слабом железе.
• Глубокий анализ кода, как и во всех решениях JetBrains, что особенно полезно для больших проектов.

Минусы

• Fleet пока ещё развивается, некоторые функции отсутствуют или реализованы не до конца.
• Менее дружелюбен к новичкам, чем Replit или CodeSandbox, потому что ориентирован скорее на опытных разработчиков.

Где пригодится

• Разработка на языках, где особенно важны рефакторинг и интеллектуальные подсказки: Java, Kotlin, Python и т.д.
• Если нужна более «лёгкая» альтернатива классическим IDE JetBrains, но при этом с возможностью работать удалённо.

StackBlitz

StackBlitz — ещё один «фронтенд-ориентированный» онлайн-редактор, но с упором на выполнение кода прямо в браузере без специальных серверных окружений. Он запускает Node.js-среду в браузере через WebAssembly, благодаря чему проекты могут работать очень быстро и автономно.

Возможности

• Мгновенный запуск Angular, React, Vue, Svelte и т.д., без серверной компоненты.
• Поддержка Node.js-приложений (через WebContainers) прямо в браузере: по сути, локальная VM работает «внутри» вкладки.
• Отличная интеграция с GitHub и возможность деплоя проектов.

Плюсы

• Реально быстрая загрузка и мгновенный старт проектов на популярных фреймворках.
• Почти не зависит от «серверной» стороны, потому что всё работает через WebContainers.
• Хорошо подходит для офлайн-режима (в разумных пределах).

Минусы

• Частично функционал ограничен: если нужны какие-то специфические системные зависимости, WebContainers могут не справиться.
• Не так универсален, как решения уровня GitHub Codespaces. В первую очередь он предназначен для веба.

Где пригодится

• Обучающие примеры фронтенда, демо на конференциях или мастер-классах.
• Когда нужно показать, как работает Angular-компонент или React-хук, а интернет-подключение не самое надёжное.
• Быстрое создание прототипа и проверка идей.

Мой личный опыт и выводы

За 10 лет работы программистом я привык, что «настоящая IDE» должна быть у меня локально, с тщательно настроенными плагинами. Однако чем дальше, тем больше я использую облачные решения. В одних случаях это экономит время на настройке окружения, в других — позволяет быстро работать даже на слабом устройстве, а в третьих — просто удобно для совместной разработки.

• Replit я использую, когда хочу быстро показать фрагмент кода на собеседовании или протестировать идею на маломальном языке, где нет желания ставить компилятор локально.
• CodeSandbox прекрасно подходит для демонстрации и прототипирования фронтенд-проектов. Идеально, если нужно поделиться примером React или Vue-компонента.
• GitHub Codespaces — моё решение для серьёзных проектов, где нужна стабильная облачная среда уровня VS Code, плюс глубокая интеграция с GitHub Actions и репозиториями.
• JetBrains Fleet я «щупаю» как потенциальную легковесную замену IntelliJ IDEA, но с возможностью облачной синхронизации и удалённой мощью серверов JetBrains. Пока рано говорить о полной замене, но направление впечатляет.
• StackBlitz — это «волшебство», когда нужно поднять Node.js в браузере. Очень люблю показывать StackBlitz на воркшопах по фронтенду, потому что всё запускается буквально за секунды.

Какую из этих сред выбрать — зависит от задач и предпочтений. Если вы профессионал, который «сидит в одной IDE 8 часов в день», возможно, вы пока предпочтёте локальные решения. Но всё чаще облачные сервисы дают такую же мощь и удобство, причём сэкономив кучу времени на конфигурации. В любом случае, всем рекомендую попробовать, хотя бы ради эксперимента. Может оказаться, что облачная IDE для некоторых задач станет вашим новым любимым инструментом.

Обновление включает основные компоненты проекта LLVM, а также его подпроекты, такие как clang, lld, libc++ и MLIR.

Релиз стал результатом шести месяцев напряженной работы LLVM-сообщества. За этот период в проект внесли вклад 1502 уникальных автора, создав 18925 коммитов, добавив 3 605 729 строк кода и удалив 1 665 792.

Благодарность сообществу

Разработчики выразили огромную благодарность всем, кто так или иначе помог с этим релизом: от авторов кода до тех, кто проводил ревью и оказывал поддержку. Данный вклад помог сделать новую версию еще более функциональной и стабильной.

Доступ к исходному коду и бинарникам

Исходный код новой версии LLVM можно посмотреть на GitHub.

Официальные бинарные файлы пока недоступны и появятся немного позже.

Для тех, кто нуждается в сторонних бинарниках, они будут размещены в специальной ветке форума проекта.

Стоит отметить, что они не проходят проверку со стороны менеджеров релиза, поэтому использовать их следует с осторожностью.

Следующее обновление

Ожидается, что следующий релиз версии 19.1.1 выйдет через две недели. Разработчики призвали сообщать обо всех найденных проблемах, относящихся к ветке 19.x, чтобы сделать будущее обновление более стабильным и надежным.

Вот самые интересные новые функции для языка C++, появившиеся в этой версии компилятора.

Поддержка C++26

Бесконечные циклы без неопределенного поведения

В C++26, как и в C, теперь разрешены тривиальные бесконечные циклы. Это изменение устраняет неопределенное поведение, которое возникало при написании низкоуровневого кода. Например, следующий код больше не вызывает такового:

Статическое хранение для braced-инициализаторов

Теперь компилятор может оптимизировать код, использующий std::initializer_list, уменьшая количество вызовов memcpy для копирования массивов. Это позволяет размещать массивы в статической памяти.

Неоцененные строки

GCC 14 поддерживает P2361R6, добавляющий понятие неоцененных строк.

Такие строки не используются во время выполнения программы и не конвертируются в исполняемую кодировку, что предотвращает использование числовых escape-последовательностей.

Constexpr cast from void*

Фича P2738R1 позволяет выполнять кастинг из void* в constexpr коде, что упрощает использование различных трюков с type erasure.

Пользовательские сообщения в static_assert

Теперь можно использовать статические утверждения с пользовательскими сообщениями, что делает диагностику ошибок более удобной:

Поддержка C++23

Deducing this

Эта долгожданная функция позволяет добавлять явный параметр this к нестатическим членам функций, что упрощает их перегрузку и уменьшает дублирование кода:

CTAD от наследуемых конструкторов

GCC 14 теперь поддерживает P2582R1, что позволяет использовать аргумент-вывод для шаблонных классов с наследуемыми конструкторами.

Интересуетесь новыми возможностями и языками программирования? Возможно, позиция Golang-разработчика (Deckhouse) в компанию Флант будет для вас вариантом применить свои знания на практике и участвовать в разработке инновационных проектов

JIT (Just-In-Time) компилятор – это инструмент, который компилирует код Python в машинный код «на лету», во время выполнения программы. Все это позволяет языку работать значительно быстрее, чем раньше.

Как работает JIT-компилятор в Python?

• в Python 3.13.0a6 он основан на архитектуре Copy-and-Patch.
• инструмент компилирует байткод Python в машинный код, используя LLVM.
  
• JIT-компилятор генерирует код очень быстро и легко поддерживается.
  
• он полностью интегрирован с интерпретатором Python.
  

Какие преимущества дает JIT-компилятор?

Как минимум, он генерирует код в 5 раз быстрее, чем WebAssembly (Liftoff), в случае с Python 3.13.0a6. Да и результирующий код работает на 50% быстрее, чем код, скомпилированный с помощью устаревшего инструмента.

К тому же JIT-компилятор в Python 3.13.0a6 работает в 100 раз быстрее, чем традиционный JIT-инструментарий LLVM. Здесь результирующий код быстрее уже на 15%, чем тот, что скомпилирован с помощью LLVM.

А как попробовать JIT-компилятор?

Для начала нужно уточнить, что JIT-компилятор в Python 3.13.0a6 — это экспериментальная функция. Для его активации необходимо добавить опцию --enable-experimental-jit при сборке CPython.

Вам также потребуется установить LLVM в качестве дополнительной зависимости.

Скачать нужную версию Python можно по ссылке.

Если вы хотите использовать свои навыки автоматизированного тестирования на переднем крае технологий, присоединяйтесь к команде в 2GIS.PRO на позицию Tech Lead AQA. Изучение новых возможностей Python 3.13.0a6 будет отличным дополнением к рабочему арсеналу.

В общем-то, автокод стал первым языком программирования в том виде, в котором мы привыкли его видеть сегодня: появились буквенные обозначения операций.

В 50-е годы программисты писали код на машинном языке или ассемблере и работали напрямую с адресами памяти компьютера. Конечно, это было сложно и долго, а ошибиться можно было слишком легко. Каждая операция и адрес памяти задавались в виде числовых кодов, после чего их вручную размечали на перфокартах.

Автокод позволил программистам использовать более удобный и абстрактный способ описания операций для компьютера. Он стал использовать символические имена для операций, что делало код более понятным и легким для чтения.

Теперь программисты могли обращаться к переменным по именам, вызывать циклы и условные операторы.

Кто придумал автокод

Первый автокод был разработан Аликом Гленни в 1952 году для компьютера Mark I. Гленни работал в Манчестерском университете, и за свою жизнь успел приложить руку к множеству открытий в мире IT.

К примеру, вместе с Аланом Тьюрингом, знаменитым британским математиком, Гленни разработал компьютер Mark I, который был одним из первых компьютеров, хранящих программу для него прямо на борту.

Первая версия Mark I была представлена в 1949 году, и именно для этого компьютера Гленни разработал высокоуровневый язык. Дело в том, что работать на Mark I было даже сложнее, чем на прочих компьютерах той поры, хотя все они были огромными шкафами без всякого интерфейса и принимали перфокарты.

Чтобы облегчить работу себе и коллегам, Гленни придумал первый современный язык программирования, который компилировался компьютером. При этом Гленни отмечал, что потеря эффективности автокода по сравнению с машинным языком составляла не более 10%.

Вот, как выглядел автокод Гленни:

После работы в Манчестере, Гленни перешел в Исследовательский институт атомного оружия, где в начале 60-х годов разрабатывал компиляторы для FORTRAN и компьютеров IBM.

Автокод Гленни не был единственным автокодом. Условно говоря, автокоды скорее являются семейством первых высокоуровневых языков программирования, которые поддерживали абстракцию и могли компилироваться.

Автокодов была целая куча. Все дело в том, что они разрабатывались под конкретные ЭВМ, потому что все они были устроены по-разному. Если Гленни создал свой автокод для Mark I, то для IBM он бы уже не работал.

Примеры программ на Автокоде Гленни

Пример простой программы на Автокоде Гленни, складывающей два числа:

Пример цикла на Автокоде Гленни, вычисляющего факториал числа:

Пример условной конструкции на Автокоде Гленни, проверяющей четность числа:

Что общего между автокодами и современными языками программирования

Впоследствии программисты смогли доработать автокод Гленни и даже сделать его модульным. Вот, почему можно считать автокоды частью огромного семейства современных языков программирования:

1. Автокоды поддерживали абстракции. Также они включали в себя синтаксические конструкции для работы с данными, операциями и структурами.
2. У автокодов была схожая с современными языками программирования синтаксис и структура.
3. Поздний автокод можно было переносить на разные платформы. Его можно было запускать на разных компьютерах, и он работал без изменений.
4. Автокод предлагал оптимизацию и определение типов данных, которые делали код эффективнее. Все, как в современных языках программирования.
5. Автокод, как и современные языки, в конце концов стал модульным: его можно было использовать в разных проектах и интегрировать с библиотеками и фреймворками. Автокод можно было поделить на функции и модули, чтобы перенести в другие проекты.

Немного о судьбе Алика Гленни

После того, как Гленни покинул Манчестерский университет, разработка автокода не закончилась. Уже в 1955 году Тони Брукер представил собственную версию автокода для того же Mark I.

Позже Брукер написал научную статью, в которой не стал упоминать Гленни как одного из людей, который приложил руку к созданию автокода.

В Википедии статья про Гленни ограничивается парой абзацев. В Британнике у Алика Гленни нет даже отдельной статьи, только одно упоминание.

Он умер в 2003 году.

Вот список шести отличных онлайн-компиляторов Python вместе с их ключевыми функциями.

repl.it

Относительно молодой продукт, уподобляющий свой интерфейс под GitHub и прочие системы версионирования. За последний месяц платформу посетило 84 тысячи человек.

Плюсы:

• Удобный интерфейс с темной темой.

• Поддерживает множество других языков наряду с Python.

• Совместное редактирование кода.

• Встроенный отладчик и терминал.

• Поставляется со встроенным менеджером пакетов.

Минусы:

• За пару секунд до компилятора не добраться, приходится авторизовываться.

• Панель управления — космолет, легко запутаться.

colab.research.google.com

Многослойное решение от Google, которое завораживает своей кажущейся простотой. На деле же Колаб уверенно держится в тройке победителей засчет массированного финансирования Google. На курсах машинного обучения преподаватели используют именно его.

Плюсы:

• Предоставляет бесплатный GPU (графический процессор).

• Встроенное версионирование в духе Google Docs.

• Логика и интерфейс «Поделиться» наследуются от Google Диска.

• Автозаполнение и интерактивные виджеты (например, «причесывание таблицы»).

• Импорт популярных библиотек без установки.

Минусы:

• Зачастую выделенных мощностей не хватает даже для данных, не считающихся «большими». Страница «замораживается».

pythonanywhere.com (от Anaconda)

Развиваемый минимальным составом компилятор от монстра Anaconda.

Плюсы:

• Позволяет запустить bash / среду Python 3.x / файл / ноутбук или даже веб-приложение.
• Поставляется с предварительно настроенной средой с предустановленным большим набором полезных библиотек.

• Бесплатный и платный тарифы.

• Поддерживает просмотр веб-страниц и запуск веб-приложений.

• Позволяет сохранять скрипты и делиться ими.

Минусы:

• Невкусный интерфейс.

mybinder.org (Jupyter Notebook)

Заточенная под развертывание готового кода среда, готовая “принять” ваш репозиторий и выделить под это контейнер Docker.

Плюсы:

• Позволяет импорт напрямую из репозитория.

• Запускается в браузере.

• Поддерживает язык разметки Markdown и LaTeX.

• Каждую ячейку можно запускать отдельно, что отлично подходит для отладки и итеративной разработки.

Минусы:

• Работает только с репозиториями, в пустой компилятор для Hello World не пустит.

trinket.io

Учебная платформа с интерфейсом, наводящим на мысли о плохом UX.

Плюсы:

• Позволяет встраивать сниппеты на свой сайт.
• Эмулятор Sense Hat для Raspberry Pi (одноплатные компьютеры размером с банковскую карту и разъемом для вывода на экран).

• Поддерживает Python 2.7 — 3.x.

• Предоставляет библиотеку примеров и проектов.

Минусы:

• Устаревший и непродуманный UI – добраться до компилятора займет пару минут.

glot.io

Многоязыковой компилятор, предоставляющий самый быстрый доступ к среде исполнения кода.

Плюсы:

• Пускает в компилятор сразу, без регистрации и лабиринта из переходов.
• Поддерживает несколько языков программирования, включая Python.

• Простой и понятный интерфейс.

• Запускает фрагменты кода без создания учетной записи.

• Позволяет вам сохранять фрагменты кода (известные как «gists») для дальнейшего использования.

Минусы:

• Не поддерживает импорт из репозитория.

У каждого решения есть свои достоинства и недостатки. Выбор будет зависеть, конечно, от конкретных потребностей задачи. Возможность использования компилятора в онлайне – все еще спорный вопрос. С широким распространением облачных технологий некоторым удалось вдохнуть в онлайн-компиляторы новую жизнь.

Организация решила наградить разработчиков за их, пожалуй, главное творение — компилятор. По мнению экспертов, именно его создание позволило современному миру стать таким, какой он есть сейчас.

Без их разработки мы бы не смогли писать приложения для наших телефонов. У нас бы не было тех машин, на которых мы сегодня ездим.

Исследователи также написали множество учебников. Они обучили целые поколения студентов тому, как разработка компьютерных программ отличается от электротехники или математики.

Премия Тьюринга выдаётся с 1966 года. Главным призом, помимо всеобщего признания единомышленников, является денежная награда — 1 млн долларов. Её Ульман с Ахо поделят между собой.

Источник: The New York Times

В комментариях подсказывают, что в реальности машинный код получается более оптимизированным. По этой ссылке вы найдете компилятор из языка Си в Assembler, который подсвечивает соответствующие друг другу строки программы на С и Assembler.

0:00 Как программа на C считает числа Фибоначчи

2:28 Как скомпилировать и дизассемблировать программу

3:20 Разбор машинного кода

Что нового в LLVM 7.0?

• В Windows появился отдельный набор инструментов для Visual Studio — LLVM Compiler Toolchain. Как следствие, пропала необходимость принудительно интегрировать LLVM в среду разработки.
• Утилита llvm-rc улучшена для сокращения количества инструментов, необходимых для создания Windows-приложений с помощью фреймворка.
• Оптимизирован механизм преобразования чисел с плавающей точкой в целые числа. Улучшение может повлечь за собой проблемы в местах, где разработчики полагались на неожиданное поведение кода. Во избежание проблем создан новый переключатель в командной строке Clang:

• Значительный прирост в скорости работы компоновщика lld, который теперь поддерживает форматы ELF (Unix), COFF (Windows) и MinGW. lld/COFF уже применяется для формирования официальных сборок Chrome и Firefox, а lld/ELF появится по умолчанию для компоновки компонентов в следующей версии FreeBSD.
• Новый инструмент llvm-mca для прогнозирования количества ресурсов компьютера, которые тратит машинный код, на различных процессорах.
• Появление llvm-exegesis для оценки работы набора команд данных архитектур.

С этими и другими обновлениями новой версии набора компиляторов можно ознакомиться в списке изменений выпуска.

В начале сентября 2018 года вышло обновление LLVM-бэкенда Kotlin/Native для компилятора языка. Среди нововведений — простейшие элементы параллелизма, а также работа с компилятором и стандартными библиотеками Kotlin 1.3-M2.

Принцип работы

Glow собирает вычислительные данные фреймворков и старается оптимизировать код каждого из них, независимо от аппаратных средств акселератора. Компилятор содержит программы и блоки, при помощи которых фреймворк выполняет несколько задач. Распределитель ресурсов памяти компьютера, к примеру, выделяет мощности индивидуально для каждого акселератора.

Устройство акселераторов

Аппаратные ускорители необходимы для выполнения задач машинного обучения. Благодаря функциональным модулям, блокам памяти в чипе и специальных схемам для приложений, они способны эффективно достигать поставленных целей.

Для этого акселераторам необходимо организовать работу всех частей. Поэтому акселераторы вроде фреймворка PyTorch нуждаются в компиляторе.

Исследователи Facebook анонсировали выход версии 1.0 библиотеки PyTorch в начале мая 2018 года. Они предполагали, что крупное обновление поможет облегчить переход от этапа исследований к разработке приложений.

• Мультиязычные компиляторы (Repl.it, JDoodle, Ideone) поддерживают 50+ языков и подходят для быстрых экспериментов • Для Python, JavaScript, PHP и Java есть специализированные онлайн-IDE с отладкой и автодополнением • Большинство сервисов бесплатны и работают прямо в браузере без установки • Онлайн-компиляторы удобны для обучения, собеседований и совместной работы над кодом

Содержание:

• Мультиязычные онлайн-компиляторы
• Python онлайн-компиляторы
• JavaScript онлайн-компиляторы
• PHP онлайн-компиляторы
• Java онлайн-компиляторы

Мультиязычные онлайн-компиляторы

Repl.it — среда для совместной работы с кодом в браузере. Поддерживает более 50 языков, среди которых C, C++, C#, Java, Python, R, JavaScript.

Особенности:

• Есть шаблоны — например, для Django, React.js, Vue, Rails.
• Интеграция с GitHub — можно открывать свои репозитории сразу на Repl.it.
• Возможность поделиться проектом с другими пользователями, есть режим совместной работы.

В бесплатной версии доступно многопользовательское сотрудничество, 500 МБ хранилища и 500 МБ памяти, 0.2 – 0.5 vCPUs. Есть также платная версия с приватными проектами, хостингом до 5 реплов, 5 ГБ хранилища, 2 ГБ памяти и 2 vCPUs.

Если нужны не только языки программирования, но и интерактивные терминалы для работы с MySQL и MongoDB, попробуйте сервис JDoodle. Это инструмент для онлайн-обучения, у которого есть режим совместного использования. Вы можете компилировать код на разных языках и разбираться с базами данных прямо в браузере.

Если нужен не только компилятор, но и другие технологии, попробуйте сервис Coding Ground. Эта платформа предоставляет доступ к 75+ языкам программирования и технологиям. Вы можете использовать встроенный редактор Markdown и запускать Bash Shell в браузере. Кроме того, на сайте есть учебные материалы, в том числе бесплатные справочники и платные видеокурсы.

Ещё один мощный сервис — Ideone. Это онлайн-компилятор и инструмент отладки, который позволяет прямо в браузере выполнять код на более чем 60 языках программирования и их версиях.

Особенности:

• Поддерживаются не только популярные языки, но и Ассемблер, Ada95, COBOL, Fortran и т.д.
• Есть шаблоны и примеры кода.
• Можно выбрать режим доступности кода: общедоступный, частный, секретный (только по ссылке).

В Ideone есть ряд ограничений для пользователей. Например, время компиляции/интерпретации не должно превышать 10 секунд. Максимальное время исполнения для гостей — 5 секунд, для зарегистрированных пользователей — 15 секунд. Размер выделенной оперативной памяти не превышает 256 МБ.

Python онлайн-компиляторы

Для проверки кода на Python подходит сервис Online Python. Здесь представлена простая IDE, которая поддерживает загрузку с компьютера и скачивание кода в виде файла с расширением *.py. Вы можете работать над проектом совместно с коллегами, поделившись ссылкой. В редакторе поддерживается тёмная тема.

В многоязычных компиляторах тоже очень хорошая поддержка Python. Например, на Repl.it есть вторая и третья версии языка, Python with Turtle для обучения, фреймворк PyGame и движок Pyxel для создания игр, библиотека Tkinter для разработки графического интерфейса, а также шаблоны для Django, Multi-Page Flask и даже ботов для Discord.

JavaScript онлайн-компиляторы

Если вам нужен JavaScript онлайн-компилятор, то JSFiddle — один из лучших вариантов. Он позволяет проверить любое сочетание JavaScript, HTML и CSS.

Особенности:

• Поддержка библиотек и фреймворков: Angular, React, Vue, Lodash, jQuery.
• Поддержка CSS, SCSS, SASS, PostCSS, Normalized CSS.
• Режим совместной работы над проектом.

JavaScript, как и Python, есть во всех многоязычных онлайн-компиляторах. Так что если вам не требуется поддержка препроцессоров и постпроцессоров, библиотек и фреймворков, то можно выбрать любой сервис.

PHP онлайн-компиляторы

Лучший выбор для проверки кода на PHP — Sandbox на сайте Online PHP Functions. Здесь можно выбрать версию языка, начиная с 4.4.9 и до последней. На сайте также есть подсказки по функциям PHP. Они выполнены в виде шпаргалок, разбитых на темы: Arrays, Date and Time, Math и так далее. Есть и пошаговые туториалы.

Выполнить код на PHP можно и с помощью многоязычных онлайн-компиляторов. Однако они не предлагают такой большой выбор версий. Более того, практически везде отсутствует последняя версия языка.

Java онлайн-компиляторы

Если требуется Java онлайн-компилятор, попробуйте Codiva.io. В нём нет такого разнообразия языков, как на других сервисах. Кроме Java поддерживаются только C и C++.

Особенности:

• Компиляция кода по мере его ввода.
• Поддержка автозаполнения на Java.
• Есть консоль для интерактивного ввода данных пользователем.

Можно также использовать компилятор Java на сайте OnlineDGB. Здесь есть встроенный отладчик и автоматическое форматирование. Вы можете поделиться примерами кода с другими пользователями, сохранить их или скачать в виде файла с расширением *.java.

Часто задаваемые вопросы

Можно ли использовать онлайн-компиляторы для серьёзной разработки?

Онлайн-компиляторы подходят для прототипирования, обучения и быстрой проверки идей. Для полноценной разработки лучше использовать локальные IDE — они обеспечивают работу с файловой системой, отладчиком, системами контроля версий и не имеют ограничений по времени выполнения и памяти.

Безопасно ли выполнять код в онлайн-компиляторах?

Большинство сервисов запускают код в изолированных песочницах (sandbox), что обеспечивает безопасность. Тем не менее не стоит вставлять в них пароли, API-ключи и другие конфиденциальные данные — код может сохраняться на серверах сервиса или быть доступным другим пользователям по ссылке.

Какой онлайн-компилятор лучше выбрать новичку?

Для начинающих лучше всего подойдёт Repl.it — он поддерживает множество языков, имеет понятный интерфейс и встроенные шаблоны для популярных фреймворков. Если вы изучаете конкретный язык, выбирайте специализированный компилятор: Online Python для Python, JSFiddle для JavaScript, Codiva.io для Java.

Чтобы сделать процесс разработки более эффективным, используйте также полезные сервисы для программистов. Как и онлайн-компиляторы, они помогают сэкономить время на решении разных задач.

Особенности компилятора Zapcc

Увеличение скорости сборки заметно для проектов, написанных на C++ с применением шаблонов и большого количества заголовочных файлов. Для языка Си ускорение менее явное. Во время проверки производительности компилятора пересборка Boost.Math с использованием Zapcc проходила в 10–50 раз быстрее по сравнению с Clang. ПО актуально только для проектов на C++, так как для кода на языке Си кэширование отключается.

Благодаря специальному фоновому процессу zapccs система имеет возможность компилировать код и поддерживать в оперативной памяти кэш компиляции всех этапов сборки. На выходе качество и производительность итогового генерируемого кода аналогичны Сlang.

C++ — язык программирования, представленный в 1983 году и активно используемый по сей день. В марте 2017 года группа WG21 приняла стандарт C++17.

Поддержка стандартов C++

В libstdc++ появились новые возможности стандартов C++17, такие, как std::filesystem, std::char_traits, std::to_chars, std::from_chars, а также экспериментального C++2a: std::to_address и std::endian. Добавлена поддержка расширений математических функций __gnu_cxx::airy_ai и __gnu_cxx::airy_bi.

Оптимизация

Механизм PGO генерирует улучшенный код на основе анализа особенностей его выполнения. Режим оптимизации -freorder-blocks-and-partition на системах x86/x86-64 разделяет тело функции на «горячие» и «холодные» области выполнения. Он применяется по умолчанию, начиная с уровня «-O2». Также в системе оптимизации улучшен способ представления отладочной информации в формате DWARF.

Диагностика

Расширенные средства диагностики точнее находят конфликты в коде и предлагают подсказки по их устранению. Например, теперь в случае пропущенных скобок } и ) компилятор указывает на место возможного пропуска. В случае обращения к приватным полям класса или структурам выдается подсказка по использованию функции-обертки. Конфликтующие типы шаблонов выделяются цветом или отображаются в виде иерархии.

Архитектуры

Для ARM64 появилась поддержка механизма SVE с расширенными инструкциями для векторной обработки данных. Внесена поддержка архитектур Armv8-R, Armv8.3-A и Armv8.4-A, а также процессоров Arm Cortex серий A75, A55 и R52.

Новые расширения

Добавлена поддержка процессоров Intel Cannon Lake c расширениями AVX512VBMI, AVX512IFMA и SHA ISA. Intel Ice Lake поддерживается c AVX512VNNI, GFNI, VAES, AVX512 VBMI2 и другими расширениями. CET (Intel Control-flow Enforcement Technology) для систем x86 активируется при помощи опций -mibt, -mshst и -mcet.

С полным списком изменений в новой версии можно ознакомиться на официальном сайте разработчиков.

Напомним, что предыдущая версия компилятора — 7.3 вышла в январе 2018 года. Разработчики внедрили в GCC защиту от атак типа Spectre, а также устранили проблемы с совместимостью.

Особенности

Поддержка технологии Retpoline для защиты от второй версии атаки типа Spectre (CVE 2017-5715) на системах x86 и PowerPC добавила в компилятор несколько новых переключателей, а именно: -mindirect-branch, -mfunction-return и -mindirect-branch-register для обхода спекулятивного исполнения кода. Помимо патчей, в GCC 7.3 представлено 99 исправлений багов.

От разработчиков все еще ожидается внедрение поддержки портирования патчей Spectre на более старые версии GCC. Несмотря на немалое число фиксов, в новом цикле GCC 7.4 присутствует более 200 неисправностей.

У этого инструмента единственная цель — максимально сократить время сборки без ущерба для корректности исполнения. При изменении исходного кода Zinc анализирует все зависимости и компилирует подмножество исходных файлов, на которые оказали влияние внесённые правки. Таким образом сгенерированный код получается абсолютно идентичным выходу чистой компиляции.

3 ноября разработчики представили новую, усовершенствованную версию компилятора — Zinc 1.0.

Ключевая особенность v1.0 — анализ зависимостей на основе классов. Этот механизм был разработан для более рафинированной обработки зависимостей, исключающей общие случаи излишней компиляции. Сравнительные тесты показали, что новый механизм сокращает процесс сборки до 40 раз.

Пример семикратного увеличения скорости

И что же в ней такого особенного? Для сравнения были взяты две версии Zinc: 0.13.x и 0.1.x.

Исходные данные: ScalaTest, основной модуль которой состоит из 40 377 строк кода на Scala (не считая комментариев и пустых строк).

Испытание: обычная операция в любой кодовой базе — добавление метода.

В данном случае стоит задача добавить новый метод к классу с большим числом зависимостей (вроде AndHaveWord в Matcher.scala) после корректного «разогрева» компилятора и компиляции проекта.

Насколько быстро с этим справится v0.13.x?

Инкрементальная компиляция заняла у нее 21 секунду. Настала очередь нового алгоритма.

Эта версия завершила перекомпиляцию всего лишь за 3 секунды. В данном примере Zinc 1.0.0 оказался быстрее своего предшественника в 7 раз.

Подобные эксперименты дают совершенно разные результаты, зависящие от особенностей Scala и используемой архитектуры. Но главная идея в здесь том, что разработчикам можно смело ожидать увеличения скорости компиляции при решении ежедневных задач. Больше всего от этого выигрывают проекты Scala на основе cake pattern или интенсивного type-level программирования. По словам тестировавших алгоритм программистов, в некоторых проектах скорость компиляции в Zinc 1.0 превосходила скорость старой версии в 22 раза.

Краткий список нововведений

В ходе работы над новой версией инкрементального компилятора были выполнены следующие задачи:

• Усовершенствован инкрементальный алгоритм: устранены «узкие места», которые раньше не удавалось скомпилировать до конца;
• Исправлены баги в инкрементальной компиляции Scala bridge и Java;
• Улучшена обработка type-level программ;
• Усовершенствованы старые Zinc API и созданы дружественные API для дополнения недостающего функционала общего доступа;
• Закончена миграция к Scala 2.12. Zinc подготовлен для JDK8;
• Добавлен анализ на основе протокола передачи данных с долгосрочной бинарной поддержкой.

С полным списком улучшений можно ознакомиться здесь.

Новая версия Zinc уже доступна в sbt 1.0.

Во-первых, необходимо поддерживать на должном уровне работу многих фреймворков. Во-вторых, нужно гарантировать высокую производителность на разном железе, используя портируемый код, который подойдёт как для запуска в веб-браузере, так и на видеокартах дата-центров. В-третьих, необходимо убедиться, что работа фреймворков будет обеспечена на ещё не вышедшем железе.

Компилятор всему голова

Amazon считает, что ключом к решению подобных проблем является используемый компилятор. Группа исследователей Вашингтонского университета и AWS представили свой подход в виде компилятора NNVM, основанный на применении стека TVM. Его целью является предоставление многократно используемой цепочки инструментов для компиляции описания высокоуровневых нейронных сетей из фреймворков глубинного обучения в низкоуровневые коды, используемые в бэкенде.

Компилятор NNVM

Целью компилятора является представление входных данных из разных фреймворков в качестве стандартизированных вычислительных графов с последующим их переводом в исполняемые графы.

Компилятор поддерживает модели в форматах OpenML (фреймворки Keras и Caffe), Apache MXNet и используемого Facebook и Microsoft открытого формата ONNX (Open Neural Network Exchange), при помощи которого передаются модели для обучения в фреймворках Caffe2, PyTorch и CNTK (Cognitive Toolkit). Результатом компиляции является код для различных бекэндов, включая вычислительные ядра CUDA, OpenCL и Metal. Также возможна генерация кода LLVM, на основе которого формируются машинные инструкции для архитектур x86 и ARM или представление WebAssembly.

Процесс компиляции кода

• Формирование промежуточного графа вычислений на основе входных данных, полученных из фронтенд-интерфейсов фреймворков;
• Оптимизация графа и выделение в нём операторов с подпрограммами обработки данных;
• Компиляция операторов в исполняемые модули и развёртывание для различных бэкендов с минимальными зависимостями.

Полученные после компиляции модули могут быть сгенерированы в необходимый код на разных языках программирования: С++, Python, JavaScript, Java, Objective-C — для дальнейшего использования на мобильных платформах, видеокартах, серверах и в веб-браузерах.

Производительность компилятора

Сотрудники Amazon сравнили в производительности фреймворк MXNet и новый компилятор NNVM на двух разных аппаратных кофигурациях: ARM-процессор на Raspberry Pi и видеопроцессор Nvidia в облачных сервисах Amazon.

В случае видеокарт Nvidia для фреймворка MXNet в качестве бекэнда использовалась библиотека cuDNN на графическом ускорителе Nvidia K80. Компилятор NNVM показал ускорение в 1,2 раза для наборов данных ResNet18 и MobileNet.

На Raspberry Pi демонстрируемые результаты ещё лучше. Скорость обработки ResNet18 у NNVM в 2,2 раза выше, а MobileNet — в 11,5 раз. Это связано главным образом с тем, что в MXNet глубина свёртки не оптимизирована (из-за отсутствия подобных операторов в библиотеке dnn), тогда как NNVM использует прямую генерацию эффективного кода.

Код компилятора и инструкция по его использованию доступны на GitHub.

И что у них получилось?

Новый компилятор Falcon был создан на основе LLVM. Главный плюс LLVM — возможность разбить оптимизатор на набор библиотек, которые будут получать на вход промежуточное представление кода и генерировать следующую промежуточную версию, которая затем будет передана дальше.

Falcon 1.0 уже превосходит по производительности Zing C2 в некоторых тестах, но это только начало. Компания уже получает наработки от пользователей с ранним доступом, которые помогают определить, какие места можно было бы оптимизировать сильнее.

Falcon уже можно попробовать?

В данный момент можно получить бесплатную 30-дневную лицензию.

Примечательные нововведения в GCC

• Полностью прекращена поддержка компилятора Java (GCJ).
• Реализована экспериментальная поддержка готовящегося стандарта C++17.
• Множество улучшений в меж- и внутрипроцедурных оптимизациях, добавлены новые оптимизации для позднего связывания.
• Добавлена поддержка архитектуры набора команд RISC-V…
• …и операционной системы Fuchsia.
• Для новых целей теперь по умолчанию используется LRA (local register allocator).
• Прекращена поддержка чипов ARMv5 / ARMv5E, добавлена поддержка ARMv8.2-A и ARMv8.3-A, Cortex A73, Broadcom Vulcan, ThunderX CN81xx/CN83xx/CN88xx/CN99xx и Qualcomm Falkor.
• Появилась возможность использования OpenMP 4.5 для спецпроцессоров NVIDIA PTX.

Подробности о выпуске можно узнать в полном списке изменений, нововведений и исправлений.

Какая-какая компиляция?

Статическая, или Ahead-Of-Time (AOT) компиляция — это самая обычная компиляция, которую мы привыкли видеть в языке Си. Исходный код превращается в исполняемый, и на выходе получается исполняемый файл, который можно запустить позже. На статическую компиляцию требуется дополнительное время до начала работы программы, отсюда и название. Существует ещё динамическая, или Just-In-Time (JIT) компиляция — она осуществляется прямо во время работы программы, “на лету”. Именно она и используется в Java в настоящий момент.

А в Java 9 хотят заменить её на статическую?

Нет. В Java 9 планируют добавить возможность AOT-компилятор в качестве альтернативы (но не замены) существующим инструментам. Утилита будет называться jaotc. В Java 9 она гарантированно будет работать только для модуля java.base, который содержит всё необходимое для работы с объектами, потоками и структурами данных — то, без чего не может обойтись ни одно приложение. Исходя из этого, AOT-компиляцию в Java 9 всё ещё можно назвать лишь экспериментальной возможностью.

А зачем это нужно?

AOT-компиляция имеет несколько специфических преимуществ. Во-первых, это защита от декомпиляции. Байткод Java можно без особого труда декомпилировать в код на Java, и, таким образом, взломать программу (которая, например, требует лицензионный ключ). Исполняемый код же можно лишь дизассемблировать, и, думается, любой может сравнить сложность поиска каких-то деталей в коде на Java и ассемблерном коде. Обфускация же далеко не панацея, т.к. она трудно реализуема при активном использовании рефлексии и всё равно не даёт стопроцентной защиты. Во-вторых, стоит обратить внимание на время запуска приложения. Для первого запуска (так называемого “холодного старта”) приложению требуется значительное количество времени. Для скомпилированного статически кода на Java стартовое время не отличается от старта аналогичной программы на Си:

То есть, получается, со статической компиляцией мы получим в Java скорость Си?

Нет. Си достигает значительной скорости за счёт многих допущений небезопасного поведения. Например, в случае выхода за границы массива в Си случится segfault (в лучшем случае), а в Java просто вылетит ArrayOutOfBoundsException. Подобные проверки не бесплатны, за них приходится платить производительностью как в случае динамической компиляции, так и в случае статической.

Неверным также является представление, что Си в целом работает быстрее Java. Так, в Java компилятору доступен весь код всех подключенных библиотек, а значит, он может оптимизировать их работу наиболее выгодным для данного приложения путём. В Си же библиотеки могут подключаться в виде машинного кода, и никакие дополнительные оптимизации для них недоступны.

Так значит, JIT для Java подходит лучше? Это ведь всё-таки динамический язык.

Такое утверждение тоже будет неверным. Оптимизации, которые производит компилятор, могут быть достаточно сложными и ресурсоёмкими, могут требовать итеративного пересчёта и анализа всей программы целиком. Зачастую в процессе оптимизации возникает такое количество дополнительных данных, что хранить их в оперативной памяти невозможно, и требуется их промежуточная запись на диск. Всего этого JIT-компилятор просто не может себе позволить. Очень заметна разница в производительности между JIT-исполняемым кодом и AOT-компилированным, например, при работе с элементами пользовательского интерфейса.

Что-то я совсем запутался. Так что же лучше?

На этот вопрос нельзя дать однозначного ответа. Для разных приложений и для разных целей выбор может быть разным. Главное, что теперь он будет. Конечно, AOT-компиляторы Java существовали и раньше, однако мало кто из них может похвастаться полноценной поддержкой свежих спецификаций Java. Теперь, когда за дело взялись специалисты из Oracle, возможно, ситуация изменится в лучшую сторону. Про AOT-компиляцию Java кода есть отличный доклад Никиты Липского, на который мы в основном и опирались при подготовке данной статьи:

Можно привести пример, в каких ситуациях статическая компиляция будет явно лучше, чем JIT?

При разработке для встраиваемых систем и мобильных платформ, скорее всего, AOT-компиляция будет лучшим выбором. Встраиваемые системы чаще всего не обладают теми же вычислительными мощностями, что и настольные компьютеры или сервера, а чем слабее железо, тем дороже динамическая компиляция. В случае с мобильными устройствами решающую роль играет другой фактор — нагрузка на аккумулятор. Динамическая компиляция требует много большего расхода энергии, чем выполнение уже скомпилированного кода. Так, для iOS политика распространения приложений вовсе запрещает любую динамическую загрузку кода, поэтому Java фактически невозможно использовать для программирования под устройства Apple.

А можно больше подробностей про то, что именно мы увидим в Java 9?

Мы увидим утилиту jaotc, которая сможет создавать нативные исполняемые файлы для Linux x64, основанные на модуле java.base.

Выглядеть это будет примерно следующим образом. Мы можем создать ELF-файл:

Затем подключить его в качестве библиотеки для исполнения другого кода:

Причём (по крайней мере, в этом релизе) для AOT-компиляции и для запуска должны использоваться одни и те же параметры:

Больше технических деталей можно узнать на сайте OpenJDK.

Ответ дает книга «Computer Science: A Programmer’s Perspective» за авторством Рендела Брайанта и Девида О’Халарона.

Компьютеры и компиляторы поддерживают различные типы для хранения данных — в частности, целых чисел и чисел с плавающей запятой. Каждый отдельный тип может отличаться от других, например, способом представления хранимой информации и объемом занимаемой памяти.

Язык программирования C поддерживает различные типы для хранения как целых чисел, так и чисел с плавающей запятой. Символьный тип char, обычно используемый для представления отдельного символа, может также хранить беззнаковые числа. Более распространенный для этих целей int образует целое семейство типов за счет возможных префиксов: short, long и long long — и все различных размеров. В таблице ниже указано, сколько байт занимает в памяти каждый тип в зависимости от разрядности системы.

Та же ситуация и с указателями (char*): в системе для хранения адресов используется все то же одно машинное слово, размер которого зависит от разрядности.

Перевод  пункта 2.1.3 «Data sizes» из книги «Computer Science: A Programmer’s Perspective»

В этой статье мы в хронологическом порядке перечислим важнейшие этапы развития парсеров как инструмента анализа данных.

1960

Выпущена спецификация ALGOL 60, в которой впервые описан язык с блочной структурой. Комитету ALGOL хорошо известно, что никто не знает, как парсить такой язык. Но они считают, что, если они детально описали язык с блочной структурой, то для него будет изобретен анализатор/парсер. Рискованный подход, который впоследствии окупился.

1961

Нед Айронс выпускает свой парсер ALGOL. Фактически, алгоритм Айронса является первым подобным анализатором, который был описан в печати. Парсер Неда является лево-рекурсивным (форма рекурсивного спуска) парсером . В отличие от современного рекурсивного спуска, алгоритм Айронса носит общий характер и является синтаксически-управляемым. «Общий» означает, что они могут разобрать что написано в БНФ (форма Бэкуса – Наура — формальная система описания синтаксиса, в которой одни синтаксические категории последовательно определяются через другие категории). «Синтаксически-управляемый» (декларативный) означает, что анализатор фактически создается из БНФ — парсер не нужно создавать самому.

1961

Почти одновременно, появляются самокодируемые (т.е. с возможностью внесения изменений в исходный код) подходы к реализации леворекурсивных алгоритмов. Сейчас их рассматривают как рекурсивный спуск. В течение следующих лет самокодируемые подходы становятся все более популярными для леворекурсивных анализаторов, чем синтаксически-управляемые алгоритмы. Важную роль сыграли следующие три фактора:

• В 1960-х память и CPU очень ограничены. Ручное кодирование (hand-coding) окупается даже тогда, когда выигрыш от его применения мал.
• Чистый леворекурсивный анализ — очень слабый метод синтаксического анализа. Ручному кодированию часто приходится преодолевать эти ограничения. Это утверждение верно как в 1961, так и в наши дни.
• Леворекурсивный анализ хорошо работает в сочетании с ручным кодированием — они дополняют друг друга.

1965

Дональд Кнут (Don Knuth) изобретает алгоритм LR. Ученый в первую очередь заинтересован в математической стороне задачи. Кнут описывает алгоритм анализа, но его подход считается непрактичным.

1968

Джей Эрли (Jay Earley) изобретает алгоритм, названный в его честь. Как и алгоритм Irons, алгоритм Эрли является синтаксически-управляемым и носит общий характер. В отличие от алгоритма Irons, не использует метод поиска с возвратом. Основная идея Эрли состоит в том, чтобы отслеживать этапы работы алгоритма в таблицах. Алгоритм Эрли заманчив, но имеет три основных недостатка:

• Во-первых, есть ошибка в обработке правил нулевой длины.
• Во-вторых, при право-сторонней рекурсии необходимо применять алгоритм дважды.
• В-третьих, чтобы создать таблицы, необходимо вести учёт системных ресурсов, что, по меркам аппаратных средств 1968 года, является довольно сложной задачей.

1969

Фрэнк ДеРемер (Frank DeRemer) описывает новый вариант LR Кнута. Для алгоритма LALR ДеРемера необходим только стек и таблица состояний, размер которой можно легко изменить.

1972

Ахо (Aho) и Алманн (Ullmann) описали простой способ исправить ошибку правила нулевой длины в оригинальном алгоритме Эрли. К сожалению, это исправление требует даже больше системных ресурсов, чем алгоритм Эрли.

1975

Белл Лэбс (Bell Labs) преобразует свой компилятор языка C из самокодируемого рекурсивного спуска в алгоритм LALR ДеРемера.

1977

Выходит первая «Книга дракона». Этот, вскоре ставший классическим, учебник назван так из-за обложки, на которой изображен рыцарь, бросающий вызов дракону. На копье рыцаря выгравированы буквы «LALR». Впредь, говорить легкомысленно LALR — значит запятнать герб теории синтаксического анализа.

1979

Bell Labs выпустила новую версию UNIX — седьмую. V7 включает в себя безусловно наиболее полный, полезный и доступный инструментарий для разработки компиляторов. Центральное место занимает инструментарий Yacc, генератор синтаксических анализаторов на основе LALR. С небольшим трудом Yacc парсит свой собственный язык ввода, а также язык основного компилятора V7 — переносимого компилятора языка C. Кажется, что после двух десятилетий исследований, проблема синтаксического анализа наконец решается.

1987

Ларри Уолл (Larry Wall) представляет Perl 1. Perl позволяет решать более сложные задачи, чем отличается от уже существующих языков. Ларри активно использует LALR — насколько известно автору, чаще, чем кто-либо до или после него.

1991

Джуп Лео (Joop Leo) обнаруживает способ ускорить правосторонние рекурсии в алгоритме Эрли. Алгоритм Лео является линейным практически для любой: как однозначной, так и неоднозначной грамматики, представляющей практический интерес. Аппаратное обеспечение в 1991 на шесть порядков быстрее, чем в 1968 году, так что вопрос учёта системных ресурсов стал не столь важен. Однако, если дело касается скорости, то выигрывает алгоритм Эрли. Алгоритм Лео оказался важным открытием, но его практическая реализация появится лишь через 20 лет.

1990-е

Алгоритм Эрли забыт. Все приверженцы LALR довольны, не так ли? Нет. Пользователи LALR делают неприятные открытия. В то время как LALR автоматически генерирует свои анализаторы, их отладка настолько трудна, что проще написать парсер самому. После отладки их LALR анализаторы при правильных входных данных работают быстро. Но почти все, что они говорят пользователям о некорректных входных данных — лишь сообщение о неверном формате без указания дополнительной информации. По словам Ларри, LALR «быстр, но глуп».

2000

Ларри Уолл принимает решение о радикальном переопределении Perl — издании Perl 6. Он даже не рассматривает вопрос о повторном использовании LALR.

2002

Эйкок (Aycock) и Хоспул (Horspool) опубликовали результаты своих опытов по созданию быстрого, практичного парсера Эрли. Однако при этом не использовалось улучшение, предложенное Джупом Лео — они, кажется, не знают о нем. Их собственный метод ускорения ограничен в своих показателях и сложности, которые он несет с собой, они могут быть даже контрпродуктивными при оценке времени. Но в этой работе ценным оказалось решение ошибки правила нулевой длины. И на этот раз оно не требует никакого дополнительного учета системных ресурсов.

2006

GNU объявляет, что был переписан парсер компилятора GCC. В течение трех десятилетий, компиляторы языка C промышленного флагмана использовали LALR в качестве парсера — доказательство утверждения, что LALR и серьезный алгоритм эквивалентны. Теперь GNU заменяет LALR технологией, которую тот заменил четверть века назад: рекурсивным спуском.

С 2000 и до сегодняшнего дня

С отступлением от LALR приходит крах престижа теории синтаксического анализа. Спустя полтора века, мы пришли к тому, с чего начали. Если вы возьмете оригинальный алгоритм Ned Irons 1961 года, измените имена и даты и переведете код из смеси ассемблера и ALGOL в Haskell, то вы бы легко смогли выпустить его в наши дни и представить как новый и революционный подход.

Парсер Marpa

Оригинальное, давно заброшенное представление алгоритма Эрли — эффективный, практичный, общий и синтаксически-управляемый парсер — теперь, по сути, вполне возможно применять на практике. Все кусочки мозаики встали на свои места.

Эйкок и Хоспул решили проблему правила нулевой длины. Джуп Лео разработал ускорение для правосторонней рекурсии. И вопрос учета системных ресурсов разрешился сам по себе: машинные операции в настоящее время в миллиард раз быстрее, чем в 1968 году, и скорость, вероятно, уже не столь значима — в настоящее время главной проблемой стали кэш-промахи.

Но в то же время как разрешились проблемы оригинального алгоритма Эрли, появился новый метод. С таким же мощным, как алгоритм Эрли, синтаксически-управляемый подход будет работать намного эффективнее, чем с левосторонним парсером. В настоящее время не так много программистов используют чисто декларативный парсер из-за печального опыта работы с LALR. Как говорится, раз обожжешься, другой раз остережешься.

Чтобы зарекомендовать себя в IT-сообществе Marpa необходимо осуществлять не только декларативный, но и процедурный синтаксический анализ. Так Marpa позволяет пользователю указывать события — вхождения символов и правил — во время которых работа декларативных алгоритмов приостанавливается. В это время приложение может вызвать процедурную логику и продолжить пошагово продвигаться от токена к токену. Процедурная логика позволяет в любой момент вернуться к синтаксически-управляемому анализу. В таблицах Эрли сохраняются все данные о состоянии: все правила и все возможные ожидаемые символы распознаются при анализе во всех возможных вариантах. В настоящее время алгоритм Эрли более эффективен при разработки процедурной логики, чем рекурсивный спуск.

Перевод статьи «Parsing: a timeline»

Почему строка auto a = 1; воспринимается компилятором C как корректная?

Я пользуюсь MS Visual Studio 2012, и вот этот код:

компилируется без ошибок, несмотря на то, что я использую расширение *.c исходника. Т.е. таким образом, я создаю код на чистом C, а насколько мне известно использование auto без указания типа стало возможным только в C++11 – заметьте, в C++, а не C.

Означает ли это, что у меня не так настроен компилятор, или этот код действительно корректен в C?

Ответ

auto – это старое ключевое слово C, обозначающее “локальную область видимости”. auto a эквивалентно auto int a, а в силу того, что в данном примере область видимости ограничена блоком, в котором объявлена переменная, то это то же самое, что и просто int a.

Это ключевое слово перешло в C еще из его предка, B, в котором не существовало базовых типов, а все было int(*): сами int‘ы, указатели на них, массивы int‘ов и т.п. И объявлялось все с помощью auto и extern. Подход “все, что тут есть – это int” в C было решено оставить, поэтому int‘овые переменные можно объявить и так:

В стандарте ISO C от подобного подхода отказались, однако многие компиляторы все еще поддерживают bacward-совместимость. Если это кажется вам странным, то вспомните о том, что вот такая строка будет корректной:

В C++ это слово вернули, но уже с новым смыслом (теперь эта конструкция позволяет явно не указывать тип переменной), ведь вряд ли множество программистов использовало это слово с оригинальным значением, особенно если учесть, что от “всего, что ты видишь – это int” отказались уже в C++98. Единственным исключением осталось тогда auto T a, чем все равно никто не пользуется.

Если вам не лень и очень интересно, можете покопаться в истории языка за авторством Страуструпа.

Кстати, интересно было организовано хранение строк в B. Строка была массивом int‘ов, каждый элемент которого хранил несколько символов. Таким образом, B – это тот же BCPL с другим синтаксисом.

Источник (StackOverflow)