Hacker News Digest

Filip Pizlo выпустил проект Fil-C, добавляющий проверку безопасности памяти в clang и включающий параллельный сборщик мусора. Инструмент демонстрирует высокую совместимость с существующим кодом, позволяя с минимальными исправлениями собирать полный Linux userspace. По измерениям, производительность составляет 1-4x (и более широкий диапазон по другим тестам), что для многих рабочих нагрузок является приемлемым. Проект основан на долгой линии исследований в области безопасности памяти, включая работы самого автора в Apple, где некоторые предыдущие итерации уже используются в производстве.

Несмотря на преимущества, Fil-C имеет ограничения: он динамически, а не статически предотвращает ошибки, программы все еще могут аварийно завершаться, есть накладные расходы на память (3-6x), и он не решает проблему гонок данных. Автор отмечает интересную возможность применения - проверки границ Fil-C могут сделать указательный код на C безопаснее, чем небезопасный Rust, и предлагает идею адаптации для компиляции небезопасных блоков Rust с дополнительными проверками.

• Почти все программы имеют пути, которые могут привести к краху, но это не означает, что они будут достаточно часто встречаться, чтобы быть проблемой.
• Fil-C обеспечивает безопасность памяти, но требует сборщика мусора и может быть медленнее, чем Rust.
• Стоит ли переписывать код на Rust, если Fil-C может обеспечить безопасность памяти без переписывания.
• Стоит ли переписывать код на Rust, если Fil-C может обеспечить безопасность памяти без переписывания.

Fil-C - реализация C и C++ с безопасной памятью, позволяющая существующему коду работать безопасно без изменений. Несмотря на молодость проекта и одного активного разработчика, Fil-C уже компилирует весь безопасный пользовательский Linux. Это форк Clang с лицензией Apache v2.0, который изначально был медленным, но после оптимизации работает всего в несколько раз медленнее оригинала. Тест с Bash показал практически незаметную разницу в производительности.

Основная сложность проекта - обработка указателей. Текущая реализация "InvisiCaps" разделяет указатели на доверенную "capability" и недоверенную "address" части, позволяя им соответствовать естественному размеру архитектуры. Для поддержки безопасности Fil-C использует другую внутреннюю ABI, чем Clang, что требует полной перекомпиляции проекта. При выделении объекта в куче Fil-C добавляет два слова метаданных для проверки границ доступа и хранения дополнительной информации о указателях.

• Fil-C — это компилятор C → C, добавляющий проверки безопасности памяти, но при этом оставляющий программы полностью совместимыми с существующим кодом и не требующий изменений в исходном коде.
• Проект разрабатывается в рамках Nix, что позволяет легко собирать любые пакеты с Fil-C, а также предоставляет кэш сборок.
• Обсуждение выявило, что Fil-C в первую очередь ориентирован на безопасность, а не на производительность, и что он не решает проблему безопасности в полном объеме, но является важным шагом вперед.
• Некоторые участники обсуждения выразили обеспокоенность по поводу того, что Fil-C может быть непрактичен из-за производительности, но другие отметили, что для некоторых приложений безопасность важнее производительности.

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

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

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

TPDE-LLVM — новый бэкенд LLVM-O0, который в 10–20 раз быстрее стандартного, при сопоставимой скорости выполнения и росте кода на 10–30 %. Работает с IR Clang-O0/O1, цели x86-64 и AArch64.
Данные SPEC CPU 2017 (x86-64, ускорение компиляции и размер кода относительно LLVM 19 -O0):

бенчмарк	O0 IR	O1 IR
perl	11.4× / 1.27×	15.1× / 0.97×
gcc	12.5× / 1.32×	17.6× / 1.01×
omnetpp	21.5× / 1.24×	26.5× / 1.03×
геом.ср.	13.3× / 1.27×	17.6× / 0.97×

Как работает: три прохода — очистка IR, анализ (циклы + liveness), единый codegen (lowering, регистры, кодирование).
Поддержка: как библиотека, llc-подобный инструмент, патч для Clang. DWARF и улучшенный рег-аллокатор в планах.
Ограничения: не все IR-конструкции, векторы, TLS-глобалы, i260 и т.д.

Что ускорило бы LLVM ещё сильнее:

• убрать ConstantExpr внутри функций;
• запретить гигантские структуры/массивы как значения;
• упростить доступ к TLS и произвольную битовую арифметику.

• Пользователи обсудили, что Gentoo всё ещё используют с флагом -O8 для максимальной производительности.
• Кто-то спросил, нужно ли добавить пометку «(2020)» к цитируемому тексту.
• Упомянули, что «все» якобы перешли на Arch, где компилятор якобы умеет -O11.
• Уточнили: пост 2025 года, но он цитирует запись 2020-го; попросили модератора исправить.

TPDE-LLVM: 10-20× быстрее -O0
Новый open-source бэкенд TPDE-LLVM ускоряет компиляцию в режиме -O0 в 10–20 раз при сопоставимой скорости выполнения и увеличении кода на 10–30 %. Поддерживаются x86-64 и AArch64, типичное IR Clang O0/O1.

SPEC 2017 (x86-64)	Ускорение	Размер
perl	11.4×	1.27×
gcc	12.5×	1.32×
mcf	9.7×	1.27×
omnetpp	21.5×	1.24×
xalanc	19.0×	1.24×
x264	10.5×	1.26×
deepsjeng	9.6×	1.25×
leela	21.4×	1.24×
xz	11.0×	1.30×
geomean	13.3×	1.27×

Как работает
Три прохода: очистка IR, анализ (циклы + живость), кодогенерация (lowering, регистры, код) за один проход. Подробности — в статье.

Планы

• DWARF, улучшенный регистровый аллокатор.
• Поддержка Flang/Rust неполная (векторы, FP-операции).
• Нет non-ELF, других целей.

Использование
Библиотека, llc-подобный инструмент, патч для Clang.

Почему не ускорить LLVM?
LLVM 18→20 стал быстрее на 18 %, но 10× требует радикальных изменений.

Что мешает ещё быстрее

• ConstantExpr внутри функций.
• Структуры/массивы произвольного размера.
• Прямой доступ к TLS-глобалам.
• Арифметика произвольной битности (i260).

Факты

• 4 байта padding в Instruction для служебных номеров.
• PHINode::getIncomingValForBlock квадратичен при >1 k предков.
• 90 % времени tpde-llc — парсинг биткода.

• TPDE — новый бэкенд, генерирующий код на 10–20× быстрее LLVM, но чуть медленнее -O0.
• Участники спорят, насколько «парето-улучшение» реально: поддерживается лишь «типичное» подмножество LLVM-IR, векторные инструкции и экзотика не работают.
• Некоторые вспомнили Copy-and-Patch и другие подходы, где LLVM используется для библиотеки патчей, но теряется 2,5× в рантайме из-за регистров.
• Основная узкость теперь — фронтенды (rustc, Clang), которые даже при TPDE занимают >98 % времени сборки.
• Желают скорейшего переноса в Swift и Wasmer, но сомневаются в готовности сообщества LLVM что-то менять.