A Note on Fil-C
Filip Pizlo выпустил проект Fil-C, добавляющий проверку безопасности памяти в clang и включающий параллельный сборщик мусора. Инструмент демонстрирует высокую совместимость с существующим кодом, позволяя с минимальными исправлениями собирать полный Linux userspace. По измерениям, производительность составляет 1-4x (и более широкий диапазон по другим тестам), что для многих рабочих нагрузок является приемлемым. Проект основан на долгой линии исследований в области безопасности памяти, включая работы самого автора в Apple, где некоторые предыдущие итерации уже используются в производстве.
Несмотря на преимущества, Fil-C имеет ограничения: он динамически, а не статически предотвращает ошибки, программы все еще могут аварийно завершаться, есть накладные расходы на память (3-6x), и он не решает проблему гонок данных. Автор отмечает интересную возможность применения - проверки границ Fil-C могут сделать указательный код на C безопаснее, чем небезопасный Rust, и предлагает идею адаптации для компиляции небезопасных блоков Rust с дополнительными проверками.
Комментарии (137)
- Почти все программы имеют пути, которые могут привести к краху, но это не означает, что они будут достаточно часто встречаться, чтобы быть проблемой.
- Fil-C обеспечивает безопасность памяти, но требует сборщика мусора и может быть медленнее, чем Rust.
- Стоит ли переписывать код на Rust, если Fil-C может обеспечить безопасность памяти без переписывания.
- Стоит ли переписывать код на Rust, если Fil-C может обеспечить безопасность памяти без переписывания.
What .NET 10 GC changes mean for developers 🔥 Горячее 💬 Длинная дискуссия
В .NET 10 сборщик мусора получает серьёзные улучшения, которые могут вдвое или втрое сократить использование памяти и повысить производительность. Ключевые изменения включают расширенный escape-анализ для выделения объектов на стеке, оптимизацию делегатов и настройку размеров регионов кучи. Также активирована система DATAS, автоматически адаптирующая сборку мусора под поведение приложения, особенно в контейнерах.
Однако эти улучшения требуют осторожного подхода: они доступны через runtime-флаги и могут иметь компромиссы, например, увеличение пауз или нагрузки на CPU. Разработчикам стоит тестировать новые настройки в боевых сценариях, а не включать их вслепую. Инструменты мониторинга, такие как счетчики GC и дампы памяти, помогут оценить эффект для конкретного приложения.
Комментарии (196)
- Пользователи отмечают значительное повышение производительности в .NET 10 по сравнению с .NET 8, особенно в приложениях для анализа аудио и текста.
- Высказываются опасения, что оптимизации .NET могут отдалить его от совместимости с WASMGC, что критично для использования в браузере.
- Обсуждаются потенциальные риски, такие как переполнение стека в программах, которые ранее работали стабильно, и сложность настройки GC.
- Упоминаются альтернативные фреймворки для кроссплатформенной разработки (Avalonia, Flutter, MvvmCross) на фоне скептического отношения к стабильности и будущему MAUI.
- Поднимаются вопросы о применимости .NET для high-frequency trading и оптимизации LINQ, а также о сравнении с JVM и другими языками (F#, Java).
WASM 3.0 Completed 🔥 Горячее 💬 Длинная дискуссия
Завершена работа над Wasm 3.0
Три года назад была завершена версия 2.0 стандарта Wasm, добавившая векторные инструкции, массовые операции с памятью, множественные возвращаемые значения и простые ссылочные типы.
Сегодня мы рады объявить о выпуске Wasm 3.0 как нового действующего стандарта. Это крупное обновление включает несколько важных функций, разрабатывавшихся до восьми лет.
-
64-битное адресное пространство. Память и таблицы теперь могут использовать
i64вместоi32, расширяя доступное пространство с 4 гигабайт до 16 эксабайт (теоретически). На вебе 64-битная память ограничена 16 гигабайтами, но для невеб-экосистем это открывает возможности для работы с огромными приложениями и наборами данных. -
Множественная память. Теперь один модуль может объявлять и напрямую использовать несколько областей памяти, включая копирование данных между ними. Это позволяет инструментам вроде wasm-merge работать со всеми модулями Wasm и открывает новые возможности для безопасности, буферизации и инструментирования.
-
Сборка мусора. Wasm добавляет поддержку автоматически управляемого хранилища через сборщик мусора. Компиляторы могут объявлять layout структур данных через типы struct и array, а также нетипизированные целые числа — всё остальное, включая представление значений исходного языка, остаётся их ответственностью. Wasm предоставляет только базовые строительные блоки, избегая встроенных объектных систем.
-
Типизированные ссылки. Расширение системы типов теперь поддерживает богатые формы ссылок, описывающие форму значения в куче, что избегает дополнительных проверок во время выполнения. Эта система также доступна для ссылок на функции, позволяя безопасные косвенные вызовы без проверок типа или границ через инструкцию
call_ref. -
Хвостовые вызовы. Важный механизм для языковых реализаций, особенно функциональных языков и внутренних техник (например, заглушек). Вызовы полностью общие и работают как для статических, так и для динамических получателей.
-
Обработка исключений. Ранее не было эффективного способа компиляции обработки исключений в Wasm. Теперь исключения определяются через теги с данными, могут быть выброшены и перехвачены обработчиками — новым видом инструкций блока с диспетчеризацией по тегам.
-
Расслабленные векторные инструкции. (Описание сокращено)
Комментарии (427)
- Переход на 64-битную адресацию по умолчанию снимает ограничения для ресурсоёмких веб-приложений, таких как видеоредакторы.
- Добавлена низкоуровневая поддержка сборки мусора (GC), позволяющая компиляторам управлять структурой данных.
- Сообщество выражает разочарование отсутствием прямого доступа к DOM и JS-объектам из WebAssembly.
- Множественные памяти и улучшенная типизация ссылок могут оптимизировать взаимодействие с API (например, WebGPU).
- Разработчики отмечают проблемы с опытом использования (DX) и сложность компиляции в WASM.
- Обсуждаются потенциальные применения новых возможностей для языков C#, Java, Go и Python.
- Остаются нерешённые вопросы, такие как работа на микроконтроллерах и поддержка сокетов.
Fil's Unbelievable Garbage Collector 🔥 Горячее 💬 Длинная дискуссия
Fil-C — это C/C++-совместимый язык с безопасной памятью и современным инструментарием. Его сердце — FUGC, параллельный, конкурентный, точный, неперемещающий сборщик мусора.
Ключевые черты FUGC
- Параллельность: маркировка и очистка выполняются на всех ядрах.
- Конкурентность: потоки-мутаторы не останавливаются; блокировки только на медленных путях аллокации.
- On-the-fly: нет глобальной паузы; «мягкие рукопожатия» просят потоки асинхронно сканировать стек.
- Grey-stack: повторное сканирование стеков до фикс-поинта; барьер только при записи, быстрая сходимость.
- Dijkstra-barrier: при записи указателя объект помечается CAS-relaxed.
- Точность: LLVM-плагин
FilPizlonatorточно знает, где все указатели. - Неперемещаемость: объекты не двигаются; освобождённые блоки «перенаправляются» через InvisiCap.
Safepoint-механизм
- Компилятор вставляет
pollcheck: быстрая проверка или колбэк для GC. - «Мягкое рукопожатие» запускает колбэк на всех потоках.
- Состояния enter/exit позволяют блокироваться в syscall без pollcheck’ов; GC сам выполняет колбэк для «exited» потоков.
- Safepoint защищает от гонок: загруженный указатель будет жив до следующего safepoint’а.
По желанию можно включить полный stop-the-world (FUGC_STW=1) для fork(2) или отладки.
Комментарии (247)
- Fil-C — это С-компилятор с точным параллельным GC (FUGC) и capability-указателями, позволяющий запускать «как есть» CPython, SQLite, OpenSSH и др., теряя в худшем случае 4× производительности.
- Вместо ручного free и UB-оптимизаций LLVM код живёт под барьером Дейкстры и soft-handshake safepoint’ами; указатели превращаются в «InvisiCap» (base+offset), теряющие силу при приведении к integer.
- Проект исследовательский, но уже промышленно полезен: нет сборок под 32-бит, Windows и embedded без MMU, нет пока поколенческого GC и ARM/RISC-V.
- Споры: «lock-and-key» предсказуемее RAM, но требует атомиков; GC = «мусор потом» vs compile-time проверки; можно ли дождаться AI-стат-анализа вместо Rust-переписей.
Lisp from Nothing, Second Edition 🔥 Горячее
LISP FROM NOTHING
344 стр., 2025, Lulu Press, 6"×9", 19 иллюстраций, код бесплатно.
Купить: мягкий переплёт | твёрдый | PDF
Исходники | Превью (PDF) | Опечатки | Видео-обзор
Книга исследует минимальный LISP, способный интерпретировать и компилировать себя, и показывает, каким был хакинг в эпоху перфокарт и мейнфреймов. Во втором издании добавлена глава о связи LISP с λ-исчислением, улучшены макросы и стиль.
Примеры кода
- Метациркулярный интерпретатор: CL, Scheme
- Компилятор (~400 строк): liscmp.lisp.html
- Система: lisp.lisp.html
- Сборщик мусора: gc.lisp.html
Весь код книги (~100 КБ)
λ-исчисление в Scheme (~6 КБ)
Генератор перфокарт Postscript
Обложка главы «Let There Be LISP»
Комментарии (97)
- Читатели восторженно отзываются о сайте и книгах Нильса М. Хольма, называя их «личной поэзией» и «культурными артефактами», созданными ради самого процесса.
- Автор подтверждает: главное для него — красота и простота изложения, а не практическая польза или научная новизна.
- Покупатели жалуются на выбор: «хочется всё сразу», но автор советует начать с одной книги и прислал шпаргалку «какую выбрать».
- Обсуждаются входные требования: книга не для новичков; рекомендуют The Little Schemer, ANSI Common Lisp и A Gentle Introduction.
- Возник спор о названии «Lisp from Nothing» при пометке «не вводная книга»; автор уточняет, что «nothing» значит «с нуля», а не «для нулевых».