Hacker News Digest

Разработчик Ruby-гема Karafka столкнулся с редким, но критическим багом, когда 2700 идентичных ошибок NoMethodError: undefined method 'default' for an instance of String обрушили систему. Ошибка возникала при доступе к elem[:partition] в FFI::Struct, хотя код нигде не использовал метод #default, характерный для Hash.

Исследование показало, что проблема в версиях FFI ниже 1.17.0, где отсутствуют write-барьеры, позволяющие сборщику мусора Ruby освобождать внутренние Hash-объекты. После освобождения память могла перераспределяться под другие объекты, например, строки. Баг проявляется с вероятностью "один к миллиону", но катастрофичен по последствиям. Пользователи использовали Alpine Linux с musl libc, что могло усугубить ситуацию из-за особенностей компиляции и выравнивания структур.

• Обсуждение выявило, что причиной проблемы была давно исправленная ошибка в ffi, а не в Ruby или в коде клиента.
• Участники спора оспаривают, стоит ли считать статью «LLM-шлаком» из-за плохого стиля, даже если сама техническая информация в ней точна.
• Некоторые участники считают, что стиль может быть вызван тем, что автор предпочитает кодить, а не писать, и что технически важная информация была доставлена.
• Другие участники спора отмечают, что статья была полезна и что важно сосредоточиться на техническом содержании, а не на стиле написания.

• DuckDB + S3 + WASM = браузер без бэкенда, но с потенциальными проблемами с памятью и стоимостью трафика.
• Пользователи спрашивают, где учиться таким техникам и как избежать OOM-крашей.
• Обсуждается, что S3 не так уж и дешёв при публичном доступе, а R2/Cloudflare и MinIO могут быть альтернативами.
• Появляется вопрос, как защититься от DDoS и нестабильности памяти в браузере.
• Участники делятся опытом, что DuckDB не всегда стабилен и требует тонкой настройки потоков и памяти, особенно при работе с большими данными.

Проект MyraOS представляет собой операционную систему Unix-подобного типа для архитектуры x86, созданную с нуля без использования стороннего кода. Автор проекта Dvir Biton разработал ядро системы, файловую систему, драйверы и пользовательские утилиты самостоятельно, что делает его впечатляющим достижением в области разработки ОС.

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

• Проект получил много похвал за качество кода и полезность, но также вызвал критику за использование устаревших ресурсов и отсутствие современных инструментов.
• Участники обсуждали, что в 2025 году нужно обновить учебные материалы для новичков в разработке ОС, чтобы они не ориентировались на 32-битный x86 и устаревшие устройства.
• Предложения включали: предоставление ISO-образов для тестирования, создание обучающего видео, и сотрудничество с такими проектами как copy.sh.
• Также обсуждались проблемы, такие как управление памятью и отладка, и как они масштабируются в контексте разработки ОС.
• В конце обсуждение сошлось на то, что проект является вдохновляющим примером, но может быть улучшен с использованием современных практик и инструментов.

Автоматические инструменты перевода кода с C на Rust полезны, но создают небезопасный и неидиоматичный код. Авторы Jaemin Hong и Sukyoung Ryu исследуют эти проблемы и предлагают решения с использованием статического анализа. Основные трудности включают различия в управлении памятью, типах данных и моделировании ресурсов между двумя языками.

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

• Обсуждение вращается вокруг проблемы автоматического перевода C в Rust и обратно, включая проблемы с безопасностью, размером массивов и управлением памятью.
• Участники отмечают, что автоматический перевод может привести к небезопасному коду, особенно если не удается точно определить размеры массивов.
• Также обсуждается, что если Rust потеряет популярность, то может появиться необходимость в обратном переводе, что вызывает сомнения в целесообразности таких усилий.
• Некоторые участники подчеркивают, что вместо полного переписывания, возможно, лучше сосредоточиться на создании инструментов, которые могли бы помочь в безопасной работе с памятью в C.
• В конце концов, обсуждение подводит к мысли, что вместо попыток автоматического перевода, лучше было бы сосредоточиться на создании инструментов, которые могли бы помочь в безопасной работе с памятью в C.

включ) 3. При (0) в 0. (0 и 0 в 0. Ты в ко 0. (0) и не и (0) сок в

• Обсуждение в основном вращается вокруг вопроса, действительно ли Rust нуждается в сборщике мусора, и если да, то какой именно: консервативный, точный или же просто счетчик ссылок.
• Участники спора подчеркивают, что Rust уже имеет встроенные механизмы управления памятью, включая владение, заимствование и счетчик ссылок, что ставит под сомнение необходимость сборщика мусора.
• Некоторые участники высказывают мнение, что встроенный в Rust счетчик ссылок может быть достаточен для большинства случаев использования, и что добавление сборщика мусора может быть излишним.
• Другие участники подчеркивают, что даже если сборщик мусора и будет добавлен в Rust, он будет опциональным и не будет влиять на существующие программы, которые не нуждаются в нем.

Разработка BASIC-интерпретатора в 2025 году: реализация строковых переменных и сборка мусора

Проект по созданию BASIC-интерпретатора для платформы Intellivision ECS 1983 года выпуска перешёл на новую стадию — добавление поддержки строковых переменных. Изначально система могла работать лишь с числовыми данными, но теперь добавлена работа со строками (A$, B$, C$), включая операции присваивания, ввода и вывода, а также конкатенацию.

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

Реализация включает функции для работы со строками, такие как конкатенация, функции LEFT$, RIGHT$, MID$ и другие. Всё это работает на процессоре CP1610 с тактовой частотой 894 кГц, демонстрируя, что даже на ограниченных системах возможна эффективная работа со строками.

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

• В 1978 году Хэл Финни написал 2-килобайтный интерпретатор BASIC для Intellivision, который стал первым встроенным языком программирования для игровой системы.
• Участники обсуждали, что в те годы размер кода и экономия памяти были критически важны, и как это влияло на дизайн и сообщения об ошибках.
• Обсуждение затронуло вопросы раннего периода персональных компьютеров, включая такие редкие темы, как Oregon Trail и TRS-80.
• Ностальгия по тем временам, когда даже простейшие вещи, такие как строки ошибок, были предметом гордости разработчиков, и как это сравнивалось с современными стандартами.

Разработчик выложил на Hacker News фреймворк на C, и я, как исследователь безопасности, сразу заметил три классические ошибки: не проверяемый Content-Length, переполнение при копировании тела запроса и переполнение при записи ответа. Пример кода показывает, как непроверенное поле Content-Length используется как размер для malloc и memcpy, что может привести к утечке памяти или чтению за пределы буфера. Подобные проблемы встречаются везде, где C-фреймворки принимают ввод из сети или файловой системы.

• Обсуждение крутится вокруг того, что «хороший код на C» должен минимизировать выделение памяти и избегать atoi() и strdup() без проверки ошибок, что приводит к уязвимостям.
• Участники спорят о том, насколько критичны эти проблемы в контексте обучения и использования ИИ-помощи, и о том, что новички в C могут не осознавать эти ловушки.
• Обсуждается влияние ИИ на качество кода и безопасность, а также то, что влияние ИИ на обучение языкам может маскировать проблемы, которые иначе были бы очевидны.
• Участники также обсуждают, что влияние ИИ на обучение языкам и на то, что это может привести к проблемам, если человек не понимает, что делает ИИ, и что это может быть опасно.
• В обсуждении также поднимается вопрос о том, что ИИ может быть использован для аудита кода и нахождения проблем, и о том, что это может быть использовано для улучшения качества кода.

Cloudflare столкнулся с редким, но критичным багом в компиляторе Go для ARM64: при раскрутке стека может возникнуть race condition, что приводит к фатальному панику. Подробный разбор показал, что проблема в том, что компилятор неправильно генерирует барьер-инструкции, необходимые для безопасной работы с памятью. Это подтверждено исследованием исходников Go и ARM-мануалов. В итоге Cloudflare не только предоставила подробный отчет и тест-кейс в апстрим, но и предложила временное решение, которое уже встроено в их инфраструктуру и позволяет избежать проблемы до официального патча.

• Компилятор Go имел баг, из-за которого при определённом сочетании инструкций в ARM64-версии Go могла прерваться сборка мусора, что приводило к нестабильности. Исправление уже в коммите f7cc1e5 и войдёт в Go 1.20.
• Обсуждение подняло вопрос о том, насколько редки такие баги компиляторов в наши дни и какие факторы этому способствуют.
• Некоторые комментаторы поделились историями о том, как в прошлом им приходилось сталкиваться с багами компиляторами даже в таких "безопасных" языках как Go.
• Обсуждение также затронуло вопрос о том, насколько критично было быстрое обновление, и было отмечено, что Cloudflare уже использует ARM-серверы в продакшене.

Для высокой производительности B+Tree узлы должны размещаться в памяти как единый непрерывный блок, что улучшает локальность данных и повышает вероятность попадания в кэш процессора. В C++ это требует отказа от std::vector из-за дополнительной косвенности через отдельное выделение памяти, и вместо этого используется гибкий массив (flexible array member) — техника, унаследованная из C. Массив переменной длины объявляется как последний член структуры без указания размера, что позволяет динамически выделять память под весь узел и его записи единым блоком.

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

This pattern was officially standardized in C99,No it wasn't; the C99 flexible array uses [] not [1] or [0].When using the [1] hack, you cannot use the sizeof the structure to get the offset, because it includes the [1] array.When using C99, you also cannot use sizeof to get th

Виртуальная машина для языка Scheme реализована на C с использованием кучи для хранения пар. Основана на модели из работы Дабвига «Three Implementation Models for Scheme», что делает её компактным учебным примером интерпретатора Lisp-подобных языков.

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

• Обсуждение производительности и особенностей различных реализаций Scheme, включая Chez Scheme, MIT Scheme и другие.
• Упоминание роли Кента Дибвига как создателя Chez Scheme и его влияния как преподавателя и исследователя.
• Вопросы о технических деталях и возможных ошибках в представленном коде, включая проблемы с указателями и порядком вычислений.
• Идеи о бутстраппинге компиляторов и интерпретаторов, включая использование LLM для генерации ассемблерного кода.
• Общие положительные отзывы о минималистичных и элегантных реализациях Scheme, таких как обсуждаемый код.

Rust-разработчик взглянул на Vec<T> и обнаружил, что вместо ожидаемых трёх полей ptr, len, capacity внутри структура скрыта целая иерархия обёрток: RawVec, RawVecInner, Unique, NonNull и NonNull<T> — всё ради безопасности и гибкости. Это вызвало вопрос: зачем такая сложность, если можно было обойтись тремя полями? Ответ оказался в том, что каждый слой добавляет безопасность и абстракцию, защищая от ошибок с указателями.

• Обсуждение развивалось вокруг того, что стандартная библиотека Rust предоставляет безопасные абстракции над низкоуровневыми деталями, но при этом не скрывает их полностью, и что это влияет на то, как код на Rust выглядит и ощущается.
• Участники обсуждали, что сложность реализации Vec в стандартной библиотеке Rust отражает компромисс между безопасностью и производительностью, и что это влияет на то, как разработчики думают о системе типов и управлении памятью в Rust.
• Также обсуждались вопросы о том, как документация и обсуждение в сообществе Rust может быть улучшена, включая сравнение с C++ и обсуждение того, как язык программирования влияет на то, как мы думаем о коде.
• Участники также затронули тему того, что сложность реализации может отпугнуть новичков, но что это может быть уменьшено путем улучшения документации и обучающих материалов.
• В конце концов, обсуждение завершилось тем, что участники сошлись на том, что хотя Rust и предоставляет мощные и безопасные абстракции, это не делает его легким для новичков без качественного обучения и документации, и что это может быть улучшено.

Аренная память в Rust предлагает альтернативу прямым ссылкам для структур с циклическими зависимостями, таких как двусвязные списки или графы объектов. Вместо указателей используются индексы (хэндлы) в заранее выделенном массиве (арене), что позволяет обойти ограничения системы владения Rust, сохраняя при этом детерминированное поведение и безопасность.

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

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

• Обсуждается сложность реализации двусвязных списков и циклических ссылок в Rust из-за системы владения, предлагаются решения через арены, weak pointers и изменения в языке.
• Поднимаются вопросы безопасности памяти: арены и handles могут предотвратить неопределённое поведение, но не исключают ошибки в пределах границ, что может привести к уязвимостям.
• Сравниваются подходы к управлению памятью: ручное управление через арены vs. сборка мусора, отмечаются компромиссы между производительностью, безопасностью и сложностью разработки.
• Высказываются мнения о месте Rust среди других языков: он конкурирует с C++ по производительности и безопасности, а с GC-языками — по простоте, но имеет крутую кривую обучения.
• Обсуждается необходимость и сложность добавления в Rust стабильного API для аллокаторов и других низкоуровневых возможностей для большей гибкости и контроля.

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

Одной из ключевых особенностей Zig является его минималистичный дизайн и предсказуемость выполнения, что снижает сложность отладки и поддержки кода. Язык активно развивается и набирает популярность в сообществе за счёт своей прозрачности и эффективности. Практический вывод: Zig может стать отличным выбором для проектов, где критичны контроль над памятью и производительность.

• Критики выражают сомнения в целесообразности использования Zig для крупных проектов из-за отсутствия гарантий памяти, как в Rust или Swift, и нестабильности языка до версии 1.0.
• Сторонники Zig отмечают его сильные стороны: простоту, явный контроль над выделением памяти, отличную совместимость с C и возможность писать код без использования кучи.
• Обсуждаются практические примеры успешного использования Zig в реальных проектах (Tiger Beetle, Ghostty), несмотря на нестабильность.
• Поднимается вопрос о своевременности выхода книги по языку, который всё ещё активно меняется, что может быстро сделать издание устаревшим.
• Утверждается, что безопасность памяти — это спектр, а не бинарный выбор, и что простота Zig может снижать количество логических ошибок в целом.

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

Однако эти улучшения требуют осторожного подхода: они доступны через runtime-флаги и могут иметь компромиссы, например, увеличение пауз или нагрузки на CPU. Разработчикам стоит тестировать новые настройки в боевых сценариях, а не включать их вслепую. Инструменты мониторинга, такие как счетчики GC и дампы памяти, помогут оценить эффект для конкретного приложения.

• Пользователи отмечают значительное повышение производительности в .NET 10 по сравнению с .NET 8, особенно в приложениях для анализа аудио и текста.
• Высказываются опасения, что оптимизации .NET могут отдалить его от совместимости с WASMGC, что критично для использования в браузере.
• Обсуждаются потенциальные риски, такие как переполнение стека в программах, которые ранее работали стабильно, и сложность настройки GC.
• Упоминаются альтернативные фреймворки для кроссплатформенной разработки (Avalonia, Flutter, MvvmCross) на фоне скептического отношения к стабильности и будущему MAUI.
• Поднимаются вопросы о применимости .NET для high-frequency trading и оптимизации LINQ, а также о сравнении с JVM и другими языками (F#, Java).

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

Можно использовать небезопасный код с указателями для полного избежания проверок, но это рискованно: ошибки ведут к сбоям или уязвимостям. Решение — тип Span<T>, который объединяет ссылку на данные и их длину, обеспечивая безопасный нулевой копирование доступ без дополнительных проверок. Это позволяет писать высокопроизводительный код без ущерба для безопасности, сочетая низкоуровневую эффективность с управляемыми гарантиями.

• Использование Span<T> и ReadOnlySpan<T> позволяет избежать лишних выделений памяти и повысить производительность, особенно при работе со строками и массивами.
• Эти структуры предоставляют безопасные, безграничные представления памяти, заменяя необходимость в небезопасном коде и указателях.
• Оптимизации с помощью Span<T наиболее эффективны в сценариях с интенсивной обработкой данных (например, парсинг, игры), а не в типичных CMS, где узкие места обычно в БД или кэше.
• Внедрение Span<T в .NET стандартизировало ранее фрагментированные подходы к работе с памятью, улучшив interoperability между библиотеками.
• Хотя Span<T предлагает контроль, сравнимый с Rust, он ограничен моделью сборки мусора C#, тогда как Rust предоставляет более строгие гарантии времени жизни на уровне компилятора.

В ядре Linux начался процесс отказа от устаревшего метода mmap() в структуре file_operations, который используется с 1992 года. Проблема в том, что он даёт драйверам прямой доступ к критическим структурам управления памятью (VMA), что усложняет обработку ошибок и создаёт риски стабильности. Вместо него введён новый метод mmap_prepare(), вызываемый раньше в процессе маппинга и использующий более безопасный дескриптор vm_area_desc.

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

• Обсуждение касается внутренней переработки в ядре Linux, а не удаления системного вызова mmap(), что успокаивает участников.
• Упоминается исторический контекст использования /dev/zero для выделения анонимных страниц памяти и его возможная замена.
• Участники шутливо предлагают создать новые виртуальные устройства, такие как /dev/seven (источник символа ^G) и /dev/yes (бесконечный поток "y\n").
• Подчёркивается консервативность и глубокая интеграция структуры file_operations в API ядра, что делает её изменение значительным событием.
• Обсуждается принцип "We do NOT break userspace" (Мы НЕ ломаем пользовательское пространство) как фундаментальный для разработки ядра Linux.

GrapheneOS разработала hardened malloc — аллокатор памяти с акцентом на безопасность для защиты от уязвимостей, связанных с повреждением памяти. Он использует расширенное адресное пространство в 48 бит вместо стандартных 39 бит в Android, что увеличивает энтропию ASLR до 33 бит. Это позволяет эффективнее изолировать структуры данных и выделения памяти через mmap, усложняя атаки.

Аллокатор применяет строгие меры защиты: размещает небольшие объекты в отдельных регионах с защитными страницами, добавляет канарейки для обнаружения переполнений и использует рандомизацию размещения метаданных. Эти механизмы значительно затрудняют эксплуатаюцию уязвимостей, таких как переполнение буфера или использование-after-free, делая GrapheneOS одной из самых защищённых мобильных ОС.

• Критика "усиленных" аллокаторов: снижают производительность, не предотвращают удаленное выполнение кода и их возможности часто преувеличивают.
• Предложение альтернативы: Apple kalloc_type с MTE и аппаратными изменениями для обеспечения целостности памяти.
• Упоминание другого подхода: аллокатор Solaris SPARC ADI.
• Отмечено, что решения от Apple более впечатляющие и продемонстрировали влияние на известные эксплойты.

Объектные хранилища вроде Amazon S3 стали основой для современных систем данных благодаря почти неограниченной ёмкости, низкой стоимости и высокой долговечности. Однако их высокая задержка и стоимость каждого запроса создают серьёзные проблемы для приложений, требующих низкой задержки, таких как потоковые системы вроде RisingWave. Задержки в сотни миллисекунд накапливаются при частых чтениях, делая систему медленной и дорогой.

Для решения этой проблемы разработан гибридный кеш Foyer на Rust, объединяющий память и локальный диск. Он снижает количество обращений к S3, ускоряя доступ к горячим данным в памяти и тёплым — на диске, что сокращает задержки и затраты. Архитектура Foyer включает шардированный кеш в памяти для высокого параллелизма и дисковый кеш с эффективным управлением данными, координируемые единым компонентом. Это позволяет достичь баланса между скоростью и ёмкостью, критически важного для реального времени.

• Обсуждение библиотеки Foyer для гибридного кеширования (память + диск) и сравнение с альтернативами (CacheLib, rclone, S3 Mountpoint, AWS Storage Gateway).
• Вопросы о производительности S3 и целесообразности кеширования из-за задержек и стоимости запросов.
• Технические детали реализации: инвалидация кеша, запись в S3, поведение в гибридном и in-memory режимах.
• Проблемы с работой сайта Medium (модальные окна, блокировка прокрутки) в Firefox.
• Критика формата комментариев и призыв к содержательным обсуждениям.

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

В Zig же разработчик напрямую управляет памятью через аллокаторы, используя указатели и мутацию без сложных правил времён жизни. Это требует дисциплины, но даёт больше гибкости и скорости написания кода. Для CLI-инструментов, где производительность и простота часто важнее абсолютной безопасности памяти, Zig оказывается практичнее. Безопасность — это не только отсутствие ошибок памяти, но и читаемость, скорость разработки и соответствие задаче.

• Обсуждение затрагивает проблемы безопасности в C, связанные с ручным управлением памятью, и ироничные комментарии по этому поводу.
• Пользователи делятся мнениями о современных языках (Nim, Odin, V, D, Zig), отмечая их преимущества, такие как интероперабельность с C и гибкость в управлении памятью.
• Уточняется функциональность Zig: он не компилируется в C, но имеет инструмент для трансляции C-кода в Zig, при этом компилируясь напрямую в машинный код.
• В обсуждении присутствует юмористический тон относительно утверждения, что разработчики не являются идиотами.

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

• Добавлена поддержка Valgrind в Go для тестирования криптографического кода на постоянное время выполнения и отслеживания инициализации памяти.
• Обсуждаются преимущества Valgrind для обнаружения утечек памяти и тонких ошибок, несмотря на наличие других инструментов, таких как ASan/MSan.
• Подчёркивается важность аннотаций для корректного анализа неинициализированной памяти, особенно при использовании unsafe-кода или CGO.
• Высказываются опасения, что эффективность зависит от повсеместного использования инструмента всеми пакетами, чтобы избежать большого количества ложных предупреждений.
• Некоторые пользователи выражают скептицизм, считая необходимость в Valgrind признаком недостатков языка, в то время другие видят в этом мощное дополнение к инструментарию.

В Wild-линковщике для Rust применяют несколько продвинутых техник оптимизации параллельной работы. Например, используют split_off_mut для безопасного разделения мутабельных срезов Vec<SymbolId> между потоками, что позволяет обрабатывать символы каждого объекта параллельно без блокировок, сохраняя кэш-локальность.

Для инициализации вектора без задержек на основном потоке задействуют крейт sharded-vec-writer: предварительно аллоцируют память, разбивают её на сегменты по числу символов в объектах и заполняют их параллельно через VecWriter, что ускоряет стартовую фазу.

В случаях, когда требуются случайные записи в общий вектор (например, для обработки дубликатов символов в C++), переходят на атомарные операции. Вместо стабильного, но ограниченного AtomicU32::from_mut_slice (только nightly) или постоянного использования атомиков (что снижает производительность), временно преобразуют &[SymbolId] в &[AtomicSymbolId] через unsafe-конверсию, экономя на издержках синхронизации в основном коде.

• Обсуждаются оптимизации Rust, такие как преобразование Vec в IntoIter и обратно для эффективного повторного использования аллокации, что реализовано в стандартной библиотеке как специальный случай.
• Высказываются предостережения против некоторых "трюков производительности", например, перемещения аллокации в другой поток для освобождения, из-за особенностей работы аллокаторов и сомнительной выгоды.
• Поднимается вопрос о надёжности оптимизаций компилятора (LLVM) в релизных сборках, которые могут меняться между версиями и сложны для верификации, что контрастирует с медленными debug-сборками.
• Отмечается, что многие трюки направлены на обход ограничений borrow checker для получения разрешения на выполнение операций, а не на решение аппаратных задач производительности.
• Обсуждается преимущество Rust в безопасном параллелизме (например, с Rayon) по сравнению с C/C++, где обеспечение потоковой безопасности значительно сложнее.

Своп-память часто воспринимается как устаревший механизм, однако она играет ключевую роль в эффективном управлении памятью. Основная её цель — не просто предоставить «аварийную» память, а обеспечить справедливое и оптимальное перераспределение ресурсов. Без свопа система вынуждена агрессивно вытеснять файловые кэши, что может снизить производительность и увеличить нагрузку на диск.

На ядрах Linux версии 4.0+ алгоритмы свопа значительно улучшены, уменьшая риски избыточного вытеснения страниц. Для SSD использование свопа практически эквивалентно по задержкам работе с файловыми страницами, а на HDD оправдано снижение параметра vm.swappiness. Важно отметить, что отключение свопа не предотвращает проблем в условиях нехватки памяти — оно лишь смещает их в другую область, не решая коренную проблему.

• Обсуждение затрагивает практический опыт использования swap: от успешных кейсов с распределенными системами и Raspberry Pi до проблем с производительностью при нехватке памяти.
• Участники спорят о необходимости swap: одни считают его полезным для вытеснения неактивных страниц, другие — вредным, продлевающим период нестабильности системы при нехватке памяти.
• Критикуется работа OOM killer в Linux за непредсказуемость и предлагаются альтернативы (earlyoom, systemd-oomd, ручной вызов через SysRq).
• Поднимается вопрос о проектировании программ: следует ли избегать аллокации большого объема неиспользуемой памяти или полагаться на swap и перезапуски.
• Отмечается разница в поведении ядер Linux: старые активно использовали swap, современные более консервативны, что вызывает споры о настройках размера swap (от 1.5x RAM до полного отказа).

Новый интерфейс std.Io.Reader в Zig может приводить к неопределённому поведению при использовании с буфером произвольного размера. Например, при передаче ридера из zstd-декомпрессора в функцию вывода с буфером 64 байта код либо аварийно завершается в режиме отладки, либо зацикливается в релизе. Проблема в том, что некоторые ридеры требуют конкретного размера буфера у писателя, но это требование не всегда очевидно или документировано.

Ситуация усугубляется тем, что сбой может зависеть от входных данных: с одними данными код работает, с другими — нет. Это создаёт риски для библиотек, где тип ридера неизвестен заранее, например, при обработке HTTP-заголовков. Автор спрашивает, не ошибся ли он, но если нет — это серьёзный изъян в дизайне API.

• Обсуждается потенциальная проблема безопасности или баг в Zig, но участники склоняются к тому, что это скорее единичная ошибка, а не системная уязвимость.
• Участники дискутируют о ценностном предложении языка Zig, описывая его как современную альтернативу C с лучшей эргономикой, компиляцией во время выполнения (comptime), явным управлением памятью и меньшим количеством неопределённого поведения.
• Критикуется реакция создателя Zig, Эндрю Келли, на конструктивную критику, которую некоторые участники сочли резкой и недружелюбной.
• Zig позиционируется как мощный инструмент для низкоуровневого программирования с ультранизкой задержкой (например, для HFT или игр), где безопасность не является приоритетом, в противовес Rust.
• В качестве альтернатив для модернизации C++ упоминаются другие языки, такие как Carbon.

Реализация Redis на языке Zig, демонстрирующая потенциал этого молодого языка для системного программирования. Проект повторяет базовые функции популярной базы данных, включая работу с ключами, строками, списками и хешами, используя эффективность и безопасность Zig.

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

• Обсуждаются альтернативы Redis, такие как kvrocks, Garnet и Redka, с поддержкой хранения данных на диске и работой в условиях ограниченной памяти.
• Участники дискутируют о стабильности языка Zig для реальных проектов, отмечая частые изменения в стандартной библиотеке и отсутствие версии 1.0.
• Поднимается вопрос о названии проекта "RiiZ" и возможном нарушении торговой марки Redis из-за схожести имен.
• Отмечается, что проект является учебным для изучения Zig, а не коммерческим продуктом, и пока не поддерживает все функции Redis (например, аутентификацию, поиск ключей).
• Обсуждаются технические детали реализации памяти и деструкторов в Zig, а также возможность использования LLM для генерации кода на этом языке.

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

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

• Создание минималистичной ОС на Zig в рамках 1000 строк кода с базовыми функциями: загрузка, управление памятью, планирование задач и вывод текста.
• Критика и вопросы по реализации: отсутствие консольного вывода, несоответствие README, проблемы сборки на разных платформах.
• Обсуждение технических деталей: формат выходных файлов, поддержка архитектур (RISC-V, ARM), использование библиотек.
• Рекомендации по улучшению: исправить .gitignore, уточнить версии компилятора, дополнить документацию.
• Ссылки на аналогичные проекты и запрос на более глубокий анализ целей проекта и опыта использования Zig.

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) или отладки.

• 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-переписей.

CVE-2024-50264: кратко о сложнейшей гонке в AF_VSOCK
Уязвимость введена в 2016 г. (ядро 4.8); это race между connect() AF_VSOCK и POSIX-сигналом, приводящий к UAF 80-байтового объекта virtio_vsock_sock. Триггер доступен обычному пользователю без user-ns. Ограничения: объект быстро освобождается, UAF-запись делает kworker, система легко падает. За это баг получил Pwnie 2025 «Best Privilege Escalation».

Управление сигналом без самоубийства процесса
Вместо SIGKILL, который убивает эксплойт, используется «бессмертный» сигнал 33:

sev.sigev_signo = 33;
timer_create(CLOCK_MONOTONIC, &sev, &race_timer);
timer_settime(...);  // точный момент прерывания connect()

Сигнал 33 зарезервирован NPTL, процесс его не видит и не завершается.

kernel-hack-drill: тренажёр для ядерных атак
Проект https://github.com/a13xp0p0v/kernel-hack-drill автоматизирует:

• сборку нужных версий ядра Ubuntu 24.04 (6.11 OEM/HWE) с разными конфигурациями KASLR/KCFI/SLAB_QUARANTINE;
• запуск в KVM с заданным RAM/CPU и ssh-форвардингом;
• однокнопочный запуск PoC и сбор crash-дампов.

Инструмент позволил быстро перебирать стратегии перераспределения kmalloc-96, искать объекты-спрей, тестировать разные техники обхода защит и отлаживать эксплойт без ручной пересборки ядра.

Новый путь эксплуатации
Автор отказался от сложной цепочки @v4bel и @qwerty и применил упрощённую схему:

1. Спрей sendmsg()-controlled объектами размером 96 байт, чтобы перехватить освобождённый virtio_vsock_sock.
2. UAF-запись переписывает поле sk_prot, указывая на поддельную структуру proto в userspace-буфере.
3. При последующем вызове close() ядро переходит по контролируемому указателю и исполняет ROP-цепочку, поднимая shell до root.

kernel-hack-drill сократил время от идеи до рабочего PoC с недель до нескольких часов.

• Участники в восторге от глубокого и единоличного описания use-after-free, но признают, что текст местами труден для чтения из-за «роботизированной» подачи.
• Многие чувствуют себя «бесполезными» на таком низком уровне и восхищаются талантом исследователей уязвимостей.
• Поднимается вопрос о мотивации: исследователи редко чинят баги, потому что это требует других навыков и ломает их инсентивы.
• Обсуждается, поможет ли Rust в ядре Linux: write-after-free технически блокируется, но unsafe-области всё ещё оставляют риски.

Разработка собственной ОС освобождает от ограничений коллективной работы и позволяет экспериментировать с необычными паттернами. Вдохновлённый статьёй LWN «Object-oriented design patterns in the kernel», я реализовал все сервисы ядра через «виртуальные таблицы» (vtables) — структуры с указателями на функции, обеспечивающие полиморфизм на чистом C.

Базовая идея

struct device_ops {
    void (*start)(void);
    void (*stop)(void);
};

struct device {
    const char *name;
    const struct device_ops *ops;
};

Разные устройства регистрируют свои реализации ops, а вызывающий код работает с единым интерфейсом. Таблицу можно менять на лету без изменения клиентов.

Применение в моей ОС

• Сервисы: сетевой менеджер, оконный сервер и др. описываются структурой

struct service_ops { void (*start)(void); void (*stop)(void); void (*restart)(void); };

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

• Планировщик: интерфейс yield, block, add, next реализуется разными стратегиями (round-robin, SJF, FIFO). Политику можно заменить без пересборки ядра.
• Файлы: как в Unix, «всё есть файл». Сокеты, устройства и обычные файлы предоставляют одинаковые read/write, скрывая сложность реализации.

Модули ядра
Такой подход легко расширяется динамически загружаемыми модулями-драйверами, как в Linux.

• Обсуждение показывает, что в ядре Linux и других проектах на C давно применяют «объектно-ориентированные» приёмы через структуры с указателями на функции (таблицы виртуальных методов).
• Некоторые считают это удобным и экономным по памяти, другие — источником проблем с читаемостью, отладкой и оптимизацией.
• Упоминаются готовые микро-фреймворки (co2, carbon) и примеры из tmux, где такие паттерны уже используются.
• Спор идёт о необходимости явного параметра this: одни ценят прозрачность, другие — «сахар» неявного this в C++/Java.
• Вопрос «почему бы не перейти на C++/другой язык» сводится к контролю над памятью, отсутствию «магии» и возможности оставаться на C ради производительности и простоты.

SDS — библиотека динамических строк на C от автора Redis.
Предоставляет удобный API: создание, копирование, конкатенация, форматирование, сравнение, обрезку и пр.
Скрывает ручное управление памятью, хранит длину и оставшийся буфер в заголовке, что ускоряет операции и делает буфер-переполнение невозможным.
Совместима с обычными char* (нулём-терминатором), поэтому строки можно передавать в любые функции стандартной библиотеки.
Используется в Redis, хорошо протестирована, распространяется под BSD-лицензией.

• Пользователи обсуждают, почему в SDS предпочитают sdscat(s, "...") вместо stscat(&s, "..."): главное — производительность и простота.
• Некоторые удивлены, что sds — это char* без const, что может привести к ошибкам при передаче в libc-функции, не обновляющие метаданные.
• Автор antirez напоминает: актуальная версия SDS живёт внутри Redis, куда она мигрировала и развивалась дальше.
• Разгорелся спор «зачем вообще писать на C, если есть C++ и string_view»; ответы: embedded, совместимость, «не платишь за то, что не используешь», а также исторические причины (Redis начинался в 2009, string_view появился в C++17).
• Подчёркивают: C-код можно встраивать куда угодно, а C++ уже требует рантайма и ограничивает переносимость.

• Участники жалеют, что выразительные языки с нативной компиляцией и автоматическим управлением памятью (Nim, D) не стали массовыми.
• Любители Nim хвалят его скорость, надёжность компилятора и эргономику, но жалуются на малую экосистему, устаревшую документацию и сложность кросс-компиляции.
• Скептики считают, что «выразительность» и макросы делают язык нишевым, требуют больше знаний и усложняют чтение чужого кода.
• Многие отметили, что успех языка определяют не фичи, а деньги, стандартная библиотека, тулинг и сообщество; Rust выиграл именно этим.
• Часть разработчиков ушла из Nim в Rust, Go или Zig из-за зрелости инструментов и богатой экосистемы, но продолжают следить за Nim и надеются на его рост.

Ghostty GTK-часть переписана с нуля
Проект завершён: Linux/BSD-версия теперь полностью использует GObject из Zig и проверена Valgrind.

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

• Zig-структуры обёрнуты в GObject; память управляется счётчиками ссылок.
• При обновлении конфига старый объект освобождается автоматически, когда исчезают ссылки.
• Появились сигналы, свойства, действия GTK и современные UI-файлы Blueprint.
• Новые виджеты добавляются быстрее (анимированная рамка, вкладки в заголовке и т.д.).

Valgrind Каждый коммит прогонялся под Valgrind.

• Потребовался большой suppression-файл (в основном GTK/драйверы).
• Найдены: утечка и неопределённое обращение в Zig-коде, ошибка WeakRef в GTK, которые иначе вызывали редкие краши.

• Ghostty переписывает GUI на GTK/Zig, столкнувшись с проблемами GObject и управления памятью.
• Участники обсуждают, что GTK навязывает свою ООП-модель и счётчики ссылок, что сложно сочетать с Zig/Rust.
• Некоторые считают GTK не «родной» на Linux и предлагают Vala, Qt или собственный UI.
• Пользователи жалуются на баги прокрутки, копирования, nano и отсутствие поиска.
• Автор признаёт выбор GTK компромиссом ради кроссплатформенности и «родного» вида.

Как обогнать memcpy

Профилируя Shadesmar, увидел: при больших (>512 КБ) сообщениях 97 % времени уходит на memcpy между процессной и разделяемой памятью. Решил ускорить копирование.

---

Разбор memcpy

perf показал:
__memmove_avx_unaligned_erms — это memcpy через memmove, AVX, 32 байта за раз, поддержка не выровненных блоков и ERMS (железный цикл REP MOVSB).

• memmove выбран, т.к. допускает перекрытие.
• Для <4 КБ используется SSE2, иначе — REP MOVSB + AVX.
• Не-временные (NT) инструкции и prefetcht0 уменьшают кэш-промахи.

---

Способ 1: простой REP MOVSB

void _rep_movsb(void *d, const void *s, size_t n) {
  asm volatile("rep movsb"
               : "=D"(d), "=S"(s), "=c"(n)
               : "0"(d), "1"(s), "2"(n)
               : "memory");
}

Тот же цикл, что и в glibc, но без лишней логики.

• Часть выгоды даёт отказ от лишнего копирования: часто данные можно использовать на месте.
• Несколько участников отмечают, что без контроля кэшей и правильной сериализации бенчмарки теряют смысл.
• График в конце вызывает сомнения: скачки пропускной способности выглядят неправдоподобно.
• Для IPC обсуждают zero-copy через размещение данных сразу в shared memory (Iceoryx, Boost.Interprocess, DPDK).
• Большинство сходится к выводу: для обычных задач лучше довериться стандартному memcpy/std::memcpy, особенно в glibc.

Моя предыдущая статья о обобщённых структурах данных в C готовила почву к теме: структура, которая заменяет динамические массивы, даёт стабильные указатели и хорошо работает с аренными аллокаторами. Её переоткрывали много раз под разными именами: “levelwise-allocated pile” (2001), в Zig — Segmented List, частично похожая на C++ std::deque. Мне нравится название Per Vognsen — Segment Array.

Скачать мой однофайловый заголовок segment_array.h можно, подписавшись на рассылку.

Идея проста: фиксированный массив указателей на сегменты; каждый следующий сегмент вдвое больше предыдущего; новые сегменты выделяются по мере необходимости. Поскольку элементы не двигаются, указатели на них стабильны, не остаются “дыры” в арене, а доступ по индексу — за O(1).

Реализация

Структура на C:

typedef struct { u32 count; int used_segments; u8 *segments[26]; } SegmentArrayInternal;

Почему всего 26 сегментов? Из 64 бит указателя обычно реально используются 48, так что 49 сегментов уже перекрывают адресное пространство (~256 ТиБ). Я предпочитаю индекс u32 (до ~4 млрд элементов) — это даёт 32 сегмента. Ещё убираем 6 маленьких (1..32), начинаем с 64, остаётся 26 сегментов — хватает для 4 294 967 232 элементов (чуть меньше UINT32_MAX). Фиксированный массив рядом со структурой снижает риск промаха кэша.

Размеры сегментов — степени двойки: проще математика и быстрые сдвиги для индексов.

#define SMALL_SEGMENTS_TO_SKIP 6

#define log2i(X) ((u32) (8*sizeof(unsigned long long)
- __builtin_clzll((X)) - 1))

u32 capacity_for_segment_count(int segment_count) { return ((1 << SMALL_SEGMENTS_TO_SKIP) << segment_count) - (1 << SMALL_SEGMENTS_TO_SKIP); }

void *_sa_get(SegmentArrayInternal sa, u32 index, size_t item_size) { int segment = log2i((index >> SMALL_SEGMENTS_TO_SKIP) + 1); u32 slot = index - capacity_for_segment_count(segment); return sa->segments[segment] + item_sizeslot; }

log2i использует __builtin_clzll (подсчёт ведущих нулей) для быстрого вычисления номера сегмента.

Clang оптимизирует _sa_get до ~10 инструкций x86-64 (-O3), так что узким местом будет память, а не вычисления индекса. При последовательной итерации можно обходить сегменты напрямую; в segment_array.h есть макрос.

Выделение нового элемента:

u32 slots_in_segment(int segment_index) { return (1 << SMALL_SEGMENTS_TO_SKIP) << segment_index; }

void *_sa_alloc(SegmentArrayInternal *sa, size_t item_size) { if (sa->count >= capacity_for_segment_count(sa->used_segments)) { size_t segment_size = item_size * slots_in_segment(sa->used_segments); sa->segments[sa->used_segments++] = malloc(segment_size); } sa->count++; return _sa_get(sa, sa->count-1, item_size); }

Замечание: можно сделать ёмкость строго степенью двойки, если первые два сегмента одинакового размера. Код станет менее изящным, но это спасает от ~50% потерь памяти при использовании как массива бакетов в хеш-таблице со степенью двойки.

Дженерики

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

#define SegmentArray(type)
union {
SegmentArrayInternal internal;
type *payload;
}

Дальше макросы используют payload, чтобы передавать сведения о типе…

• Обсуждается структура «сегментированный массив» (экспоненциальные сегменты), её плюсы и минусы, и сравнение с существующими решениями: std::deque, ropes, Zig std.SegmentedList, rust-array-stump, plf::colony.
• Критика терминологии: это не «массив» в классическом смысле из‑за неконтигуозной памяти; многие API ожидают сплошной/страйдовый буфер и не подойдут.
• Производительность: при локальных L1-итерациях вычислительная часть индексации может быть ощутима; для больших объёмов память становится бутылочным горлышком. Предлагаются оптимизации итерации по сегментам и замечания про clz/bsr/lzcnt и опции компилятора.
• Виртуальная память как альтернатива: резервирование большого диапазона и по мере роста коммит страниц/guard pages; отмечены плюсы на Linux (MAP_POPULATE, mremap), но плохо для embedded/WASM.
• Сравнение с deque: фиксированные блоки vs экспоненциальные, поддержка prepend, рандом-доступ есть; реализация MSVC критикуется за малый размер блока, GNU/libc++ лучше.
• Недостатки сегментов: ухудшение предвыборки/кэш-локальности при линейной итерации, отсутствие стабильной непрерывности для API, сложность с хеш-таблицами при росте (rehash), потенциальный перерасход памяти при экспоненциальных размерах.
• Предложения: настраиваемый минимальный размер сегмента, функции «склейки» мелких сегментов, разбор условий, когда экспоненциальные сегменты оправданы, и замечания о чрезмерной макротрюковости в C/C23.

• Логотип Multics

• Домой

  • История »
    • Возможности
    • Мифы
    • Project MAC
    • Даты
    • Глоссарий
    • Проект истории
    • Последний сайт
  • Люди »
    • Истории
    • Фотографии
    • Юмор
    • Памятные вещи
  • Библиотека »
    • Статьи и доклады
    • Технические статьи
    • Документы разработки
    • Исходники
    • Симулятор
  • Сайты »
    • Хронология площадок
    • AFDSC (Пентагон, Вашингтон)
    • ASEA (Вестерос, Швеция)
    • Avon (Бристоль, Англия)
    • Bell Canada (2 площадки)
    • CISL (Кембридж, Массачусетс)
    • CNO (Миннеаполис, Миннесота)
    • DND-H (Галифакс, Канада)
    • DOCKMASTER (АНБ, Мэриленд)
    • FORD (Детройт, Мичиган)
    • GM (Детройт, Мичиган)
    • Майнц (Германия)
    • MIT (Кембридж, Массачусетс)
    • NWGS (ВМС США, 4 площадки)
    • OU (Рочестер, Мичиган)
    • PRHA (Сан-Хуан, Пуэрто-Рико)
    • RADC (Рим, Нью-Йорк)
    • RAE (Фарнборо, Англия)
    • STC (Лондон, Англия)
    • System-M (Финикс, Аризона)
    • Systeme X (Лувесьен, Франция)
    • UC/ACTC (Калгари, Канада)
    • USGS (3 площадки)
    • USL (Лафайет, Луизиана)
    • VPI (Блэксберг, Вирджиния)
  • О сайте »
    • Изменения
    • Новости
    • Ссылки
    • Галерея
    • Карта сайта

• Поиск

• Меню: История: Возможности | Мифы | Project MAC | Даты

• Участники обсуждают влияние Multics на современную вычислительную технику: от безопасности и архитектуры до наследия в текущих проектах (например, STOP, происходящий от SCOMP/STOP).
• Делятся воспоминаниями об использовании Multics в британских университетах в 80-х: система считалась быстрой, апгрейды памяти были ощутимыми, доступ через терминалы и JANET, позитивный опыт работы.
• Мнения расходятся: одни критикуют «всеобъемлющесть» дизайна и сложность (в контраст к UNIX), другие подчёркивают сильные стороны Multics — кольца защиты, строгие политики доступа (MAC/ACL), сегментную память и отсутствие переполнений буфера.
• Отмечают ограниченную портируемость Multics к немногим мэйнфреймам, несмотря на теоретическую переносимость.
• Ссылаются на полезные ресурсы: мифы о Multics, оценка безопасности B2, страницы по безопасности данных (AIM/MAC), «Три вопроса» для анализа багов, меморабилии, хронологии и список недавних изменений.
• Обсуждают спад активности оригинальных установок (последние закрытия около 2000 г.), эмулятор DPS8M и печальные новости об уходе участников проекта.
• Несколько комментаторов переосмыслили роль UNIX после знакомства с историей Multics и более ранними идеями (Xerox PARC), видя в Multics самостоятельную и богатую идеями систему, а не только «предтечу UNIX».

Добро пожаловать на 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/параллельных подходов, но признают их практические ограничения.

The reason you are not seeing crashes when allocating with Rust and freeing with C (or vice versa) is that by default Rust also uses the libc allocator.https://stdrs.dev/nightly/x86_64-unknown-linux-gnu/src/std/s... Lots of detail, little substance, and misleading section headers