Hacker News Digest

Экспериментальный пакет golang.org/x/exp/simd предоставляет платформенно-независимый доступ к SIMD-инструкциям в Go, позволяя писать высокопроизводительный код для обработки массивов данных без привязки к конкретной архитектуре. Он абстрагирует низкоуровневые инструкции (такие как SSE, AVX, NEON) через универсальный API, где разработчик описывает операции над векторами, а компилятор и рантайм подбирают оптимальную реализацию под текущее оборудование. Это упрощает написание кода, который одновременно работает эффективно на x86, ARM и других платформах, избегая необходимости вручную писать ветвления по наборам инструкций или использовать cgo/ассемблер.

Пакет поддерживает типизированные векторные типы (например, v128 для 128-битных регистров) и операции над ними: загрузка/сохранение из памяти, арифметика, логические операции, перестановки и редукции. Особое внимание уделено безопасности и предсказуемости: все операции имеют чётко определённое поведение, включая обработку случаев, когда запрашиваемая ширина вектора недоступна на текущей платформе (в этом случае происходит паника или fallback на скалярный код, в зависимости от режима). В экспериментальном режиме пакет позволяет включать автовекторизацию через флаги компилятора, а также предоставляет инструменты для benchmarking и проверки генерации кода. Хотя пакет всё ещё находится в exp и может меняться, он демонстрирует путь к тому, чтобы SIMD стал доступной частью стандартного Go-стека для задач вроде обработки изображений, сигналов, криптографии и научных вычислений.

Экспериментальный пакет simd в Go дает прирост производительности от 30% до 5x по сравнению со скалярным кодом, при этом имея лишь небольшой оверхед относительно платформенно-специфичных реализаций. Это подтверждают тесты @ImJasonH, задачи по обработке видео и аудио (speech-to-text/text-to-speech). SIMD устраняет необходимость в CGO для векторизации, упрощая сборку и убирая зависимости от C/C++. Это делает Go привлекательнее для системных задач, включая разработку баз данных (например, streambed). Технические особенности: — Поддержка архитектур с переменной длиной вектора (SVE, RVV) обеспечивает будущестойкость. — Генерация специализированных версий функций при компиляции исключает runtime-накладные расходы. — Автоматическая векторизация в компиляторе Go (CL 791740) уже в разработке и показывает хорошую эффективность. Рекомендации и альтернативы: — Для максимальной скорости стоит использовать платформенно-специфичный код, оставив портативную реализацию как запасной вариант. — Чтобы сохранить портативность, длину вектора следует ограничивать минимально поддерживаемым размером целевых платформ. — В качестве альтернативы CGO можно использовать Go-ассемблер и пакет unsafe (как в go-pherence). — Предложено создать линтер для автоматической замены числовых циклов на SIMD-операции. Дискуссии: — Некоторые критикуют Go за игнорирование долгосрочных запросов (например, 13-летнее ожидание generics) при внедрении SIMD без явного спроса. — Возник спор о влиянии SIMD на проблему накладных расходов CGO: часть пользователей считает, что SIMD полностью устраняет необходимость в CGO.

В архитектуре AMD Zen 2 инструкция RDRAND16 ошибочно устанавливает флаг CF=0 при генерации нуля, что заставляет программы перезапрашивать значение. Проблема заключается в ложном флаге ошибки, а не в самом генераторе. В поколениях Zen 3 и Zen 4 эта ошибка отсутствует. Официальное уведомление AMD касается RDSEED, а не RDRAND, и не охватывает Zen 2. Пользователям рекомендуется проверить версию BIOS и микрокода, так как подобные баги в Zen 2 исправлялись ранее. Для минимизации рисков рекомендуется: 1. Использовать абстракции, автоматически повторяющие попытки при CF=0. 2. Рассматривать аппаратный RNG лишь как источник энтропии для CSPRNG, а не как источник готовых значений. 3. Применять постобработку данных. Ядро Linux уже смешивает энтропию из разных источников через ChaCha8 и Blake2b, что делает сторонние XOF-решения избыточными. Специалисты отмечают, что отсутствие нуля редко критично, так как RDRAND обычно лишь семенит CSPRNG, а криптографии важна высокая энтропия, а не равномерное распределение. Тем не менее, подобные ошибки могут не выявляться стандартными тестами и требуют анализа распределения значений (например, через гистограммы). В некоторых критических системах на Linux-серверах RDRAND отключают как источник энтропии из-за повторяющихся багов AMD.

Эмуляция x86-TSO на ARM — одна из самых сложных задач в совместимости архитектур, поскольку x86 требует строгой согласованности памяти (Total Store Ordering), тогда как ARMv8.0 использует слабую модель упорядочивания, позволяющую значительные аппаратные оптимизации. Это означает, что запись в память на x86 мгновенно видима всем ядрам, а загрузка гарантирует видимость всех предшествующих записей — поведение, ожидаемое программистами. На ARM же записи могут задерживаться в кеше и не быть сразу видимыми другим ядрам без явных барьеров, что нарушает семантику x86-кода, особенно в многопоточных приложениях и синхронных структурах данных.

Ключевые проблемы включают необходимость эмуляции атомарных инструкций (например, LOCK CMPXCHG), которые на ARM требуют дорогостоящих барьеров или циклических попыток с использованием LDXR/STXR; обязательную обработку split-lock операций (когда доступ пересекает границу кеш-линии), которые на ARM не поддерживаются аппаратно и требуют дорогостоящих программных обходов; и работу с некешируемой памятью (uncached), где доступы должны строго соблюдать порядок и не могут быть буферизованы — критично для устройств ввода-вывода и видеопамяти. На UMA-системах (например, Tegra, Snapdragon с Adreno 600+) проблема частично решается через принудительное использование кэшированных буферов в видеодрайверах, что исключает доступ к uncached памяти. Пользователи Asahi Linux с аппаратным битом TSO избегают проблемы естественным образом, но добавление дискретного PCIe GPU вновь вводит несовместимость. Несмотря на прогресс вендоров в решении отдельных аспектов, полное устранение накладных расходов остаётся вызовом, и эмуляция x86-TSO продолжает требовать значительных компромиссов между производительностью и корректностью.

Обсуждение дополняет статью, раскрывая практические аспекты эмуляции x86 на ARM: Apple внедрила TSO-режим в чипы, но не устранила все крайние случаи; FEX демонстрирует прогресс в эмуляции на Linux с поддержкой Steam и Crossover. Apple добавила TSO-режим в свои чипы для эмуляции x86 благодаря вертикальной интеграции и контролю над железом, но это не устраняет все крайние случаи. Спор: слабая модель памяти ARM не даёт значительных преимуществ в производительности, тогда как автор Rosetta 2 утверждает, что она улучшает производительность за счёт гибкой оптимизации. FEX — открытый фреймворк для эмуляции x86 на ARM, спонсируемый Valve, используется в Steam Deck и Crossover Beta, демонстрируя значительный прогресс в эмуляции x86 на Linux. Эмуляция одного ядра может обойти проблемы упорядочивания памяти, но с потерей производительности — приемлемо для устаревших рабочих нагрузок, где скорость не критична. При эмуляции x86 на ARM в пользовательском режиме (например, FEX на Linux) накладные расходы TSO на нативный ARM-код незначительны, так как нативного ARM-кода выполняется крайне мало. Разработка TSO-режима в Apple требовала координации множества команд, что стало возможным благодаря стратегическому приоритету продукта на высоком уровне. FEX на macOS позволяет запускать Wine на чипах M-series, но его использование ограничено из-за анти-ИИ политики, требующей форка. Вопрос о компиляции бинарников в байткод вместо эмуляции не решён, поскольку это требует переписывания всего экосистемного стека, а не только эмулятора.

Платформенный процессор, система управления режимом SMM, C6‑DRAM и микрокод процессора можно «разблокировать», перепрограммируя переводы физических адресов DRAM.
skitter-creek-bath-salts вмешивается в нижние уровни иерархии памяти, переписывая регистры контроллера DRAM, чтобы любой виртуальный адрес *p мог указывать в произвольное место физической памяти. При разрушении адресных преобразований исчезают и защита, построенная на них: SEV, SGX, TDX, TrustZone, pKVM, CoVE, SMRAM и даже скрытые регионы PSP и ME становятся доступными.

Эксперимент проведён на процессорах AMD Family 16h, где документация раскрывает регистры переводов, позволяющие менять маппинг без блокировки. Техника универсальна: схожие схемы переплетения, перемешивания и переключения используют все современные контроллеры памяти — от x86 до ARM и RISC‑V. Таким образом, «разблокировка» DRAM открывает путь к новым атакам и исследованиям, показывая, что даже самые защищённые области DRAM можно обойти, если знать, как «перепутать» их адресацию.

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

Основная идея — полностью эмулированная графическая среда, работающая на реальном IBM PC XT с процессором 8088, где каждый запущенный элемент (окно, панель, мини‑приложение) представляет отдельный процесс, имеет собственный док‑тик и независимый буфер памяти. При этом ядро управляет прерывками, планированием и выделением сегментов так, что даже простые программы, как MINES (1,5 КБ) или HELLO, загружаются в собственные 2 КБ и 512‑байтные области без модификации кода.

Особенности, которые запоминаются: одновременная работа до пяти программ, включая «живой» About‑box, отображающий состояние планировщика, и плавный XOR‑трекинг курсора при перемещении окна; минимизация не останавливает фоновые задачи, а лишь скрывает их визуализацию; иконки файлов берутся непосредственно из первого сектора диска, а графические редакторы (Paint, Fractal) используют буферы и кольцевые истории, позволяющие выполнять фоновые операции, пока запущены ресурсоёмкие приложения. Всё это демонстрирует, как ограниченные ресурсы IBM PC XT могут поддерживать современный‑по‑удобству пользовательский интерфейс.

Тред обсуждает реализацию графической ОС Os8088 для IBM XT, 286, 386: участники анализируют код, производительность и опыт использования подобных систем, а также роль ИИ в разработке. Проект признаётся интересным примером графической ОС на старом железе, но некоторые скептически относятся к применению ИИ. Обсуждается уязвимость к перезаписи обработчиков прерываний и таймера — одни считают это значимой проблемой, другие — нет. Предлагаются улучшения: поддержка сети, улучшение интерфейса, портирование приложений вроде WordStar и VisiCalc. Отмечается потенциал ИИ в создании сложных систем, но подчёркивается необходимость человеческого участия в разработке и документировании.

Главная идея — поиск самого медленного одиночного процессорного инструкта, а не ускорения кода. Чем дольше один вызов, тем ниже «потолок» производительности, который можно достичь.

В x86‑версии рекорд держит fxrstor64, который за ≈ 62 секунды (≈ 198 млрд циклов) загружает 512‑байтовый FPU‑/MMX‑/XMM‑контекст из медленной MMIO‑зоны, пока остальные ядра «бьют» соседний регистр 4‑байтовыми чтениями, полностью загружая PCIe‑шину. На AMD Ryzen 7 5800H эта техника дала ≈ 74,5 млрд циклов, а в теоретическом варианте с xrstor64 (8 КБ‑состояние) потенциально ≈ 10¹² циклов.

Кратко: использование специфичных инструкций ввода‑вывода и насыщение шины прерываниями превращает обычный загрузчик состояния в рекордный «замедлитель».

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

Интерактивный эксплорер исходного кода Linux kernel позволяет просматривать дерево файлов и структуры данных, открывать исходники для изучения. Гид начинается с первой главы "Understanding Linux Kernel Before Code": ядро — не процесс, а всегда присутствующая система, мост между аппаратным и ПО; оно обслуживает пользовательские процессы через системные вызовы, прерывания и планировщик; организована в слои — виртуальные, отображенные, изолированные и контролируемые.

Рекомендуемые файлы для изучения: init/main.c, kernel/fork.c, include/linux/sched.h, arch/x86/kernel/entry_64.S. Тест знаний проверяет: разницу kernel и процесса (kernel — не процесс, а сама система), способы обслуживания (оркестрация syscalls, interrupts, scheduling), характеристики слоев (virtual, mapped, isolated, controlled). Гид включает 9 глав — от системных основ до scheduling, I/O и virtualization, с веткой @master.

• Пользователи хвалят интерактивный гид по исходникам Linux kernel как удобную "карту" для новичков, сравнивая с Талмудом и инструментами вроде Elixir Bootlin.
• Отмечены баги: ошибки загрузки файлов (entry_64.S), GitHub API rate limits, проблемы с сертификатом .dev, мобильной версией и позиционированием в файлах.
• Сравнения с Elixir (лучше поиск, теги, мобильность); пожелания AI-объяснений, графов зависимостей, локального деплоя и версий для CPython/Emacs/Vim.
• Критика: отсутствие поиска/редактирования/grep, слабые квизы (возможно AI-generated), ожидания большего от "AI-эры".

FEX-Emu — быстрый эмулятор пользовательского режима x86 и x86-64 для Linux, позволяющий запускать x86-приложения на ARM64-устройствах. Он обеспечивает широкую совместимость с 32- и 64-битными бинарными файлами и может использоваться совместно с Wine/Proton для запуска Windows-игр. Эмулятор поддерживает перенаправление вызовов API в библиотеки хост-системы (OpenGL/Vulkan) для снижения накладных расходов, а также экспериментальный кэш кода для минимизации зависаний в играх.

В основе FEX лежит продвинутый бинарный рекompiler, поддерживающий все современные расширения набора инструкций x86(-64), включая AVX/AVX2. Используемая в нем собственная промежуточная репрезентация (IR) позволяет генерировать более оптимизированный код, чем традиционный splatter JIT. Модульная архитектура включает в себя комплексный слой трансляции системных вызовов, реализующий даже нишевые возможности вроде seccomp, и позволяет использовать FEX как бэкенд WoW64/ARM64EC в Wine.

• FEX позволяет запускать x86-64 игры на ARM64-устройствах, используя Wine/Proton, но сталкивается с проблемами совместимости из-за различий в модели памяти и DRM.
• Valve спонсирует FEX, что может быть частью стратегии по переходу игровой экосистемы на ARM.
• Проблемы с DRM и анти-чит системами, а также с производительностью графических API, таких как DirectX, которые не могут быть напрямую перенаправлены на хост-систему.
• Несмотря на это, FEX демонстрирует высокую производительность и совместимость с большинством игр, включая Cyberpunk 2077.
• Возможность запуска Windows игр на ARM64-устройствах с помощью FEX и Wine/Proton может быть ограничена из-за отсутствия поддержки ARM ноутбуков и отсутствия графических драйверов.

Transmeta стала последним крупным IPO эпохи доткомов, собрав $273 миллионов 7 ноября 2000 года. Несмотря на то, что компания была производителем процессоров, а не интернет-стартапом, ее запуск считается символическим завершением интернет-бума. Аналитики часто называют это IPO последним успешным технологическим размещением до Google в 2004 году. Компания привлекла внимание благодаря найму Линуса Торвальдса, который продолжал разработку ядра Linux, работая в Transmeta.

Transmeta предложила революционный подход к созданию процессоров, используя программную эмуляцию x86-архитектуры вместо аппаратной реализации. Их первый процессор Crusoe работал на 30% менее эффективно, чем аналоги от Intel, и хотя компания выпустила два поколения чипов, она не смогла конкурировать по производительности. Отсутствие собственных производственных мощей и неспособность догнать гигантов отрасли привели к тому, что инновационная технология так и не принесла коммерческого успеха.

• Transmeta поставила на то, что динамическая компиляция сможет обогнать традиционные процессоры, но в итоге не смогла удержать рынок и была вынуждена переключиться на лицензирование IP и стала патентным троллем.
• Компания стала жертвой собственной идеи: она не смогла конкурировать с Intel и AMD, но зато Intel позже использовал её идеи в своих продуктах.
• Команда Transmeta, включая Linus Torvalds, в конце концов оказалась в других компаниях, где их опыт и знания были использованы для создания новых продуктов.
• Проект показал, что динамическая компиляция может быть полезна для энергоэффективности, но не для производительности, и что рынок ноутбуков в начале 2000-х был не готов к такой технологии.
• История Transmeta стала примером того, как иногда даже самые продвинутые технологические идеи могут не прижиться из-за плохого тайминга или рыночных условий.

В 2025 году SIMD в Rust продолжает развиваться, предлагая значительный прирост производительности до 64x для операций с u8 на современных процессорах. Основная проблема - фрагментация наборов инструкций: ARM использует обязательный NEON (128 бит), WebAssembly - 128-bit packed SIMD, а x86 имеет сложную иерархию от SSE2 до AVX-512 (512 бит). Для x86 разработчики выбирают между указанием target-cpu (например, x86-64-v3) и использованием function multiversioning для поддержки различных процессоров.

В Rust существует четыре подхода к SIMD: автоматическая векторизация (самый простой), продвинутые итераторы, портируемые абстракции и сырые интринсики. В то время как ARM стандартизировал NEON, а WebAssembly требует компиляции двух бинарных файлов, x86 остается самой сложной платформой из-за множества расширений и необходимости обеспечения обратной совместимости.

• Обсуждение показало, что Rust пока не может предложить стабильный и удобный способ работы с SIMD, в отличие от C# и C++.
• Основная причина — std::simd всё ещё в nightly, а стабильная альтернатива отсутствует.
• Участники также отметили, что даже в ночной ветке API нестабилен и может измениться, что делает его использование в production-окружениях проблематичным.
• Некоторые участники выразили обеспокоенность тем, что отсутствие стабильной SIMD-поддержки может отпугнуть потенциальных пользователей Rust, особенно в областях, где эффективное использование SIMD критично.
• В то же время, другие участники подчеркнули, что Rust всё ещё молодой язык и что сообщество может в конце концов решить эту проблему, как это было с другими функциями в прошлом.

AMD совершила стратегический прорыв в 2003 году, выпустив Athlon 64 — первый 64-битный процессор x86, который заставил Intel отказаться от собственного проекта Itanium и последовать за конкурентом. Intel изначально не хотела расширять x86 до 64 бит из-за архитектурного наследия и предпочла бы начать с чистого листа, создав более эффективный Itanium, но он провалился из-за отсутствия обратной совместимости и слабой поддержки софта.

AMD пошла на риск, понимая, что Itanium угрожает её существованию, и предложила рынку плавный переход: пользователи могли работать с 32-битными приложениями на полной скорости, а позже перейти на 64-битные ОС без потери совместимости. Это сработало — Microsoft поддержала архитектуру, а рынок оценил удобство. Athlon 64 не только выжил, но и заставил Intel лицензировать технологию AMD, что изменило расстановку сил в индустрии.

• Intel разработала собственные 64-битные расширения для x86 (Yamhill) ещё до AMD64, но отказалась от их внедрения из-за опасений конкуренции с Itanium (IA-64).
• Ключевым фактором успеха AMD64 стала обратная совместимость с существующим x86-софтом, в отличие от радикально новой и несовместимой архитектуры Itanium.
• Переломным моментом стало доминирование AMD с Athlon 64, однако Intel позже вернула лидерство с архитектурой Core, а затем вновь уступила с приходом AMD Zen.
• Решение Microsoft отказаться от поддержки 16-битного кода в 64-битных Windows было технически обосновано ограничениями AMD64, а не маркетинговым выбором.
• Разработка AMD64 велась с учётом опыта других архитектур (например, DEC Alpha) и включала устранение ряда недостатков x86, таких как малое количество регистров.

Nvidia и Intel объявили о совместной разработке процессоров Intel x86 RTX SOC для ПК с графикой Nvidia, а также о создании пользовательских серверных процессоров x86 от Nvidia. В рамках масштабной сделки Nvidia приобрела акции Intel на сумму $5 млрд.

• Опасения по поводу негативного влияния на конкуренцию: инвестиции Nvidia могут угрожать развитию графического подразделения Intel (Arc), которое сдерживает цены на GPU и важно для Linux-сообщества.
• Стратегический интерес Nvidia: сделка может быть направлена на получение доступа к производственным мощностям Intel (фабрикам) и созданию гибридных решений (CPU + GPU), а не на прямую конкуренцию на рынке видеокарт.
• Политический и экономический контекст: инвестиции могут быть продиктованы желанием правительства США поддержать национального производителя полупроводников и диверсифицировать цепочки поставок.
• Исторические параллели: сравнение со сделкой Microsoft и Apple в 1997 году, которая спасла последнюю, и надежды на аналогичный положительный исход для Intel.
• Влияние на архитектуру и рынок: возможный сдвиг в сторону интеграции графики в SoC (системы на кристалле) и потенциальные риски для x86-64 лицензирования Intel.