Оптимизирующие компиляторы отслеживают эффекты каждой инструкции в промежуточном представлении (IR), которые могут варьироваться от полного отсутствия эффектов до записи в конкретную переменную или полностью неизвестных воздействий. Автор рассматривает эту тему как продолжение предыдущего поста об IR, подчеркивая важность правильных вопросов: не "какой это код?", а "какие эффекты он производит?". Эффекты помогают компилятору определять, можно ли переупорядочивать, дублировать или удалять инструкции, особенно когда речь идет о доступе к памяти, где ключевым фактором является алиасинг (ссылки на один и тот же объект).

В статье представлены два основных подхода к представлению эффектов: битовые множества и списки диапазонов кучи. Автор подробно разбирает пример компилятора Cinder (Python JIT), который использует битсет под названием AliasClass для отслеживания эффектов работы с кучей. Каждый бит в этом множестве представляет отдельное расположение в куче, а операции объединения и пересечения выполняются с помощью побитовых операций. Интересно, что этот подход аналогичен представлению решетки типов в Cinder, где каждый бит неявно представляет множество, а операции над множествами реализованы через битовые операции И и ИЛИ.

• Пользователи ожидали, что статья будет про эффект Манделы или уязвимости Spectre из-за заголовка.
• Один участник отметил, что теперь они случайно прочитали про компиляторы.
• Завершающий комментарий содержит шутку про "Men in Black" и изменение логотипа Fruit of the Loom.

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

Появление NextSilicon на рынке может привести к усилению конкуренции и потенциальному снижению цен для потребителей. Компания, судя по всему, стремится занять нишу в сегменте, где до сих пор доминировали два основных игрока. Это развитие может стимулировать инновации как со стороны NextSilicon, так и со стороны Intel и AMD в ответ на новую угрозу.

• СервисеHome подчеркнул, что Maverick-2 — это не векторный, а data-flow процессор, что важно для понимания его позиционирования.
• Дискуссия показала, что сравнение с Anton, A64FX и другими архитектурами неуместно, так как они решают разные задачи.
• Участники отметили, что для Maverick-2 нужен JIT-подход к софту, а не переписывание существующего кода.
• Было отмечено, что в отличии от GPGPU, Maverick-2 не требует переписывания кода под CUDA/OpenCL модель, но вместо этого требует компиляции под его нативную модель.
• В конце обсуждение сошлось на то, что если рынок действительно нуждается в таком процессоре, то NEC или другой вендор мог бы его сделать, но это не делаеться, потому что это не их фокус.

Проект JIT-компилятора для PostgreSQL сталкивается со сложностями из-за особенностей современных процессоров. Автор объясняет, что даже хорошо написанный интерпретатор может проигрывать в производительности из-за непредсказуемости переходов в switch-based интерпретаторах.

Используя технику "computed gotos" (динамических переходов), можно значительно ускорить интерпретацию, сделав шаблоны переходов более предсказуемыми для предсказателя ветвления процессора. Это может дать до 15-20% прироста производительности.

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

Кроме того, автор отмечает, что оптимизация под современные процессоры (особенно с их out-of-order исполнением и предсказанием ветвлений) требует осторожного подхода. Например, код должен быть структурирован так, чтобы минимизировать зависимости по данным и максимизировать параллелизм на уровне инструкций.

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

• Обсуждение затронуло ограничения JIT в iOS из-за политики Apple, что влияет на производительность и возможности использования JIT в этой системе.
• Участники обсудили, что JIT-компилятор может быть полезен для оптимизации, но его отсутствие в iOS ограничивает возможности приложений.
• Также обсуждались различные аспекты производительности интерпретатора и JIT, включая влияние на предсказание переходов и спекулятивное исполнение.
• Участники упомянули, что JIT может быть полезен для DSL или других специализированных языков, но ограничения iOS могут затруднить это.

Команда GRiSP достигла ключевого рубежа в портировании JIT-компилятора Erlang BEAM на ARM32: впервые выполнила функцию Erlang через сгенерированный машинный код. Используя эмулятор QEMU, они запустили минимальный модуль hello.erl, который вызывает встроенную функцию erlang:halt/2 с кодом возврата 42. Это подтвердило работоспособность базовой цепочки: загрузка BEAM, инициализация JIT, компиляция и выполнение кода.

JIT инициализирует общие фрагменты кода и модуль erts_beamasm, содержащий критические инструкции для управления процессами, такие как run_process и normal_exit. Модуль hello был помещён в предзагружаемые модули, чтобы обеспечить его выполнение при старте системы. Код доступен в репозитории GitHub, а работа ведётся при поддержке Erlang Ecosystem Foundation.

• Обсуждение причин разработки JIT-компилятора для ARM32 в Erlang, включая актуальность 32-битных ARM-микроконтроллеров на рынке встроенных систем.
• Дебаты о текущем статусе архитектуры ARM32: участники отмечают, что она не устарела и до сих пор поддерживается в новых реализациях (v8-a, v8-m), несмотря на её нишевый статус.
• Вопросы о целесообразности запуска Erlang на маломощных устройствах: одни видят потенциал, другие сомневаются в необходимости из-за ограничений памяти и производительности.
• Обсуждение технических деталей: путаница с ESP32 JIT, сравнение с RISC-V, особенности наборов инструкций (Arm/Thumb/Thumb2).
• Замечание о том, что «более высокая скорость» других языков является субъективной характеристикой («при определенных определениях быстрее»).

Проект предлагает необычный взгляд на C++ как на интерпретируемый язык, оспаривая традиционное представление о нём исключительно как о компилируемом. Автор демонстрирует, что с помощью современных инструментов и техник C++ можно использовать в интерактивном режиме, подобно Python или JavaScript. Это открывает возможности для быстрого прототипирования и экспериментальной разработки без необходимости полной перекомпиляции.

Ключевая идея заключается в использовании JIT-компиляции и REPL-окружений, что делает C++ более гибким и доступным для исследовательских задач. Такой подход может сократить время разработки и упростить тестирование идей, сохраняя при этом все преимущества производительности и низкоуровневого контроля, характерные для C++.

• Участники обсуждают техническую реализацию проекта, предполагая использование метапрограммирования шаблонов, DSL и специальных флагов компилятора (GCC/Clang).
• Высказывается недоумение и замешательство по поводу принципов работы проекта, а также желание получить более подробное текстовое объяснение.
• Предлагаются альтернативные инструменты для интерпретации C++ (Clang-Repl, Xeus cling, AngelScript).
• Несколько пользователей делятся положительными впечатлениями от видео и творческого подхода автора.
• Один из комментариев содержит ироничное замечание о значении слова "based" в данном контексте.

Lua_u_

Lua_u_ (строчная u, /ˈlu.aʊ/) — это быстрый, компактный, безопасный, постепенно типизированный встраиваемый язык сценариев, основанный на Lua.

Мотивация

Примерно в 2006 году Roblox начал использовать Lua 5.1 в качестве языка сценариев для игр. Со временем мы значительно развили реализацию и язык: для поддержки растущей сложности игр на платформе Roblox, увеличения размеров команд и написания большого объёма кода (более 1 млн строк к 2020 году) нам пришлось инвестировать в производительность, удобство использования, инструменты языка и ввести постепенную систему типов. Подробнее…

Песочница

Luau ограничивает набор стандартных библиотек, доступных пользователям, и реализует дополнительные функции песочницы для возможности запуска непривилегированного кода (написанного разработчиками игр) вместе с привилегированным кодом (нашим). Это создаёт среду выполнения, отличающуюся от традиционной для Lua. Подробнее…

Совместимость

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

Синтаксис

Luau синтаксически обратно совместим с Lua 5.1 (код, действительный для Lua 5.1, также действителен для Luau); однако мы расширили язык набором синтаксических функций, делающих его более привычным и эргономичным. Синтаксис описан здесь.

Анализ

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

Производительность

В дополнение к полностью кастомному фронтенду, реализующему парсинг, линтинг и проверку типов, среда выполнения Luau включает новый байткод, интерпретатор и компилятор, сильно оптимизированные для производительности. Интерпретатор Luau может конкурировать с интерпретатором LuaJIT в зависимости от программы. Также доступен опциональный компонент для ручной JIT-компиляции на платформах x64 и arm64, который может значительно ускорить определённые программы. Мы продолжаем оптимизировать среду выполнения и переписывать её части для ещё большей эффективности. Хотя наша общая цель — минимизировать время, которое программисты тратят на настройку производительности, некоторые детали о характеристиках производительности предоставлены для любознательных.

Библиотеки

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

© 2025 Roblox.

• Переход на Luau обусловлен системой типов, но язык имеет шероховатости и слабую документацию, а сообщество практически отсутствует.
• Luau значительно сложнее и объёмнее стандартного Lua, что связано с реализацией системы типов и дополнительных возможностей.
• Существуют альтернативные реализации и среды выполнения Luau, такие как Lune, предназначенные для использования вне Roblox.
• Сообщество отмечает проблемы обратной совместимости между различными форками Lua (LuaJIT, Luau, PUC Lua), что создаёт фрагментацию.
• Luau сравнивают с Teal, но они fundamentally разные: Teal — это транспилятор, а Luau — полноценный форк Lua с собственной средой выполнения.
• Разработчики Roblox работают над улучшением поддержки Luau вне своей платформы, включая создание standalone-рантаймов.
• Несмотря на критику, инженерные решения в Luau, особенно в области производительности, оцениваются как впечатляющие.

Ускорение .NET 10

• JIT умеет инлайнить виртуальные вызовы и разворачивать цепочки интерфейсов; PGO по умолчанию.
• GC: меньше пауз, новые режимы Server & Dynamic Adaptation, утилизация памяти ↓15 %.
• BCL: List<>, Dictionary<>, Span, RegEx, UTF8/JSON, LINQ быстрее в 1,2-3×; новые API IndexOfAnyInRange, StringValues.
• C# 14: встроенные буферы, ref поля в struct, vector-типы, zero-copy P/Invoke.
• ASP.NET: 30 % RPS, 50 % latency; HTTP/3, IHttpSysRequestTimingFeature, pooled H/3 connections.
• MAUI: старты экранов в 2× быстрее, меньше аллокаций, AOT для Android/iOS.
• EF Core: компилируемые модели, pooled DB contexts, batching ↑40 %.
• Blazor WebAssembly: SIMD, AOT, сжатие IL + caching → 45 % меньше трафика.
• Серверные шаблоны: оптимизированные Docker-образы, ReadyToRun + AOT, меньше RAM.
• Инструменты: динамический профилировщик в VS, dotnet trace --live, Perfetto, новые счётчики.

• C# стремительно быстрее: LINQ ускорили в 300×, Native AOT догоняет Go, каждый мажор даёт –10–20 % CPU на 20 000 серверах.
• Всё это — благодаря «arena-» и escape-анализу, стековым структурам, ref’ам и другим приёмам, раньше доступным лишь в Rust/C++.
• Однако оптимизации не гарантированы: если код «не пройдёт borrow-checker», ускорения может не быть, а понять, где аллокации, всё труднее.
• Обновления .NET почти безболезненны: минуты работы и пара строк в CI, при этом старые API продолжают жить летами.
• Спорный момент — экосистема: кому-то кажется, что пакеты устаревают быстрее, чем в других языках; другие считают стабильность ASP.NET Core лучшей из виденных.

Где живёт JIT-код

Ruby не выбрасывает байт-код — он остаётся в ISEQ. В структуре метода поле jit_entry либо NULL (интерпретатор), либо адрес скомпилированной машинной функции. Байт-код нужен для деоптимизации.

Как Ruby запускает JIT

Перед каждым вызовом метода VM проверяет jit_entry. Если указатель не нулевой — переход на него, иначе обычный интерпретатор. Одна проверка, один jmp.

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

ZJIT ждёт 25 вызовов для профилирования и 30 для компиляции (числа настраиваются). Пока счётчик jit_entry_calls не достигнет порога, метод работает в байт-коде.

Почему возвращаются к интерпретатору

JIT делает упрощающие предположения (типы, классы). Если они нарушаются — контроль возвращается к байт-коду, который всегда корректен. Это «деоптимизация»: быстро, но безопасно.

• Участники обсуждают, возможно ли ускорить Ruby с помощью фонового JIT, который постепенно перекомпилирует методы по мере накопления профильной информации (tiered compilation уже есть в .NET и JS-движках).
• Предложен снимок «прогретой» VM для мгновенного старта, но проблема — глобальное состояние C-библиотек; Emacs делает это через unexec.
• MRI Ruby не распараллеливает потоки и не дружит с JIT: язык позволяет динамически менять классы, что ломает оптимизации.
• Альтернатива — JRuby/TruffleRuby на JVM, но они теряют часть динамики и накладывают ограничения JVM.
• Соглашение: Ruby вряд ли догонит Java по скорости из-за динамической типизации и дизайна языка.

luminal — библиотека для глубокого обучения, работающая «со скоростью света».

Основное

• Язык: Rust
• Цель: максимально быстрое вычисление градиентов и обучение нейросетей.
• Подход: компиляция вычислительного графа в высокооптимизированный нативный код (LLVM).

Возможности

• Автоматическое дифференцирование.
• JIT-компиляция графов.
• Поддержка CPU и GPU (CUDA).
• Минимальные накладные расходы: нет Python-интерпретатора и лишних библиотек.

Примеры

let x = Cpu::tensor([1.0, 2.0, 3.0]);
let y = x.relu().sum();
let g = y.backward(); // градиент за наносекунды

Установка

cargo add luminal

Статус

Проект в активной разработке; API может меняться.

• Luminal — это ML-фреймворк, который вместо ручных правил формулирует оптимизацию как поиск по огромному пространству возможных ядер (tiling, потоки, инструкции и т.д.) с помощью e-graphs.
• Сейчас на M-серии MacBook Llama-3 8B Q8 выдаёт 15-25 ток/с; это ниже llama.cpp, но команда строит трекер производительности и продолжает улучшать поиск.
• Поиск ограничен 12 базовыми линейно-алгебраическими операциями, что делает задачу похожей на «superoptimisation» и позволяет добавлять аппаратно-специфичные инструкции (tensor cores, PTX/ASM) без роста frontend.
• Для оценки качества ядра используется реальное время выполнения на целевом железе; масштабировать планируют распараллеленным профилированием на кластерах GPU.
• Отличие от TVM/tinygrad — единое пространство поиска, включающее как параметры тайлинга, так и алгебраические преобразования (например, softmax → flash-attention).

bolt — компактный встраиваемый язык на C:

• высокая скорость, реал-тайм, статическая типизация
• целевые задачи: скрипты в играх, IoT, системы с ограниченными ресурсами

Основное

• репозиторий: Beariish/bolt
• лицензия: MIT
• компилятор ~150 КБ, зависимости отсутствуют

Возможности

• синтаксис C-подобный, сборка мусора без пауз
• FFI к C «из коробки»
• компиляция AOT/JIT, кроссплатформенность (x86, ARM, RISC-V)

Быстрый старт

git clone https://github.com/Beariish/bolt
cd bolt && make
./bolt examples/hello.bt

hello.bt

import std.io;

fn main() {
    io.println("Привет, bolt!");
}

• Пользователи одобрили идею быстрого статически типизированного скрипт-языка для встраивания, но сразу спутали «embedded» с «embedded-systems» и отметили отсутствие поддержки ARM/32-бит и отказ от целочисленных типов.
• Критика синтаксиса import a, b from module: неудобен для автокомплита и повышает риск конфликтов имён; автор готов добавить псевдонимы.
• Сомнения в заявленной скорости: несколько человек привели замеры, где Bolt проигрывает LuaJIT и даже обычной Lua 5.4.
• Подняты вопросы о полноте типовой системы (генерики, полиморфизм), отладке, LSP, сборке мусора и долгосрочной поддержке.
• Плюсы: понятный C/Python-подобный синтаксис, удобный Result-тип, потенциальная замена Lua в играх и редакторах.

Добро пожаловать на LWN.net

Этот материал для подписчиков стал доступен благодаря читателю LWN. Тысячи подписчиков зависят от LWN как от источника новостей о Linux и свободном ПО. Если статья вам понравилась, пожалуйста, рассмотрите возможность оформления подписки. Спасибо за визит!

Антонио Куни, давний инженер по производительности Python и разработчик PyPy, на EuroPython 2025 в Праге представил доклад «Мифы и сказки про производительность Python». По его мнению, привычная «мудрость» о скорости Python часто вводит в заблуждение. На примерах он показал реальные узкие места и пришел к выводу: в конечном счете предел оптимизаций упирается в управление памятью. Он начал ранний проект SPy, который, возможно, приведет к сверхбыстрому Python.

Он попросил зал поднять руки, кто считает «Python медленным или недостаточно быстрым» — рук было много (в отличие от PyCon Italy). Годы работы с производительностью и общение с разработчиками породили набор мифов, которые он хочет развеять.

Мифы

Миф: «Python не медленный». Да, часто «достаточно быстрый», особенно как «склеечный» язык в эпоху «важен только GPU». Но это верно лишь для части задач. Есть множество программ, где скорость Python критична — отсюда постоянные усилия по оптимизации интерпретатора и перенос горячих участков в Cython, Numba и т.п.

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

Королларий «это всего лишь клей»: «просто перепишите горячее в C/C++» (сегодня — в Rust). Прием рабочий, но быстро упирается в стену: принцип Парето подсказывает оптимизировать 20% кода, где 80% времени, но затем срабатывает закон Амдаля — ускорив горячую часть, вы упираетесь в остальной код, который начинает доминировать во времени выполнения.

Еще миф: «Python медленный, потому что интерпретируемый». Интерпретация — лишь малая часть. Даже выражение p.x * 2 в C/C++/Rust — это загрузка, умножение, сохранение. В Python же нужно определить тип p, вызвать getattribute(), распаковать p.x и 2, выполнить операцию с учетом перегрузок и протоколов, упаковать результат, выделить память и т.д. Это диктуют семантика и динамичность языка, не способ исполнения.

Статические типы

С распространением тайпингов слышно: «теперь компиляторы могут пропускать лишнее и считать напрямую». Пример:

def add(x: int, y: int) -> int:
    return x + y

print(add(2, 3))

Но аннотации не применяются во время выполнения, и можно вызвать:

print(add('hello ', 'world'))  # type: ignore

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

• Обсуждение сосредоточено на мифах о скорости Python: динамичность языка, непредсказуемость типов и плохая кэш-локальность мешают компиляторам и JIT достигать производительности системных языков без компромиссов по совместимости и простоте.
• Многие отмечают, что JIT и спекулятивное выполнение помогают на «хэппи-пате», но становятся хрупкими: небольшие изменения кода могут срывать оптимизации и резко просаживать скорость.
• Популярные пути ускорения — PyPy, Numba, Pythran, mypyc, а также перенос «горячих» участков в C/C++/Rust или использование DSL/субсетов (SPy); однако граница вызовов и динамика Python часто «съедают» выгоды.
• Отмечают альтернативы и эволюцию: Mojo как супермножество Python с статикой и компиляцией, возможное сосуществование компиляторов рядом с CPython вместо «Python 4».
• Критики указывают, что популярность Python не доказывает его производительность; многие реальные «тормоза» — это не CPU, а I/O и сеть, где помогают async и масштабирование.
• Скептики считают, что «быстрым» Python не станет без отказа от ключевых динамических свойств (примерно как в JS — оптимизации на общий случай, но с ограничениями); часть участников предлагает оставлять Python для скриптинга и клеевого кода.
• Вопросы многопоточности, старта интерпретатора и GIL остаются проблемными; параллельно обсуждают идеи «final»-квалификаторов, иммутабельности и GPU/параллельных подходов, но признают их практические ограничения.