Hacker News Digest

Chrome 155 добавил поддержку JPEG XL — современного формата изображений, обеспечивающего на 30–50% лучшую компрессию по сравнению с JPEG, включая lossless режим и нативную поддержку HDR. Реализация выполнена на Rust в библиотеке jxl-rs, что устраняет типичные уязвимости C++-кодеков (переполнение буфера, use-after-free) благодаря памяти-безопасному языку, при этом сохраняя высокую производительность через SIMD-оптимизации, вдохновлённые библиотекой Highway и использующие стабилизированную функцию target_feature_11. Разработчики подтвердили отсутствие memory safety багов после omfattющего fuzzing и AI-поддержки проверки кода. Поддержка JPEG XL в Chrome стала результатом давнего запроса сообщества, отражённого в Interop 2026, где формат был одним из самых популярных предложений. Команда призывает веб-разработчиков использовать .jxl в своих пайплайнах для более быстрой, богатой и безопасной веб-среды, обещая продолжать улучшать формат на основе обратной связи.

Firefox планирует добавить поддержку JPEG XL в версии 158, расширив кросс‐браузерную совместимость. Chrome ранее удалил поддержку в версии 110, но восстановил её в Chrome 155, что указывает на смену стратегии. Safari пока не поддерживает прогрессивную загрузку в libjxl, а также анимацию и прогрессивный рендеринг JPEG XL на iOS, отставая от Chrome и Firefox, которые уже включили эти возможности. По данным caniuse, поддержка JPEG XL составляет лишь ~17 % сайтов, в отличие от ~97 % для WebP, что отражает низкую текущую адаптацию. Совместимость с приложениями остаётся проблемой: Telegram, macOS и многие просмотрщики не открывают JXL‐файлы. Rust‐реализация обеспечивает защиту от типичных уязвимостей C++ (переполнение буфера, use‐after‐free), но её производительность может варьироваться — заявленная скорость «примерно так же быстро, как лучшая небезопасная альтернатива» требует проверки на реальной нагрузке. Для типичного веб‐контента AVIF обычно показывает лучшую компрессию и скорость, тогда как JPEG XL считается менее подходящим. По расширению .jxl нельзя определить, используется ли сжатие с потерями или без, что усложняет пользовательский опыт. Создание JPEG XL в некоторых графических редакторах (например, Affinity) даёт плохие результаты и нестабильную компрессию, отпугивая пользователей. Для научных изображений, требующих более 8‐битной глубины, лучше использовать AVIF, так как текущий декодер JPEG XL ограничивает внутреннее представление 8‐битами.

Fearless SIMD v1.0 устраняет необходимость в unsafe коде при работе с SIMD-операциями в Rust, предоставляя безопасный и производительный доступ к векторным инструкциям. Библиотека достигает этого благодаря макросу kernel!, который использует целевые признаки компилятора (target feature v1.1) для вызова intrinsics без unsafe, а также модулю безопасного трансмутирования, вдохновлённому bytemuck и zerocopy, который заменяет небезопасные загрузки и хранения через сырые указатели на безопасные абстракции. Это позволяет избежать тысяч unsafe блоков, типичных для других SIMD-абстракций, при сохранении полного контроля над производительностью.

Библиотека предлагает два варианта операций с платформозависимым поведением: точный (переносимый) и быстрый (платформозависимый), позволяя разработчикам выбирать между корректностью и скоростью в зависимости от ожидаемых данных. Она поддерживает как фиксированные, так и аппаратно-зависимые векторные размеры, обеспечивая полное использование аппаратных возможностей на любой платформе. При необходимости можно безопасно спускаться до платформенно-специфичных intrinsics без накладных расходов, сохраняя при этом переносимость остального кода. Fearless SIMD уже используется напрямую в 30 crate и косвенно — более чем в тысяче, что подтверждает её роль в экосистеме Rust. Несмотря на надежды на стабилизацию std::simd, библиотека останется актуальной благодаря своим уникальным возможностям: мультиверсионированию, поддержке аппаратной ширины векторов и планам по интеграции с будущими расширениями вроде SVE и RISC-V V без разрыва API. Обещаны три года обновлений безопасности для v1.0 и последующих версий.

Fearless SIMD v1.0 успешно заменил nightly-зависимые решения в продакшен-коде, позволив пользователям запускать высокопроизводительные SIMD-алгоритмы на стабильном Rust без unsafe, что подтверждено реальными кейсами вроде PhastFT и memchr-n.

• Fearless SIMD позволил пользователю O3marchnative перенести PhastFT с nightly std::simd на стабильный Rust, что стало критически важным для практического использования библиотеки.

• Dr_Emann использовал Fearless SIMD для создания memchr-n, который превзошёл по производительности официальный memchr-крейт даже для наборов из 1–3 байт, подтвердив практическую эффективность.

• Пользователь JMKH42, создавший ранний SIMD-крейт SIMDeez, признал сложность реализации подобных решений и выразил одобрение команде Fearless SIMD, подчеркнув значимость их достижения.

• Спор: modulovalue предполагает, что компиляторы не умеют трекать специфичные свойства float (например, отсутствие NaN), что мешает оптимизации SIMD, но athrowaway3z возражает, что такие условия редко сохраняются за пределами простых случаев и не влияют на производительность в реальных сценариях.

• barchar указывает, что LLVM уже использует value tracking / known bits analysis, что означает, что частичная оптимизация по свойствам векторов возможна без изменения языка, но не применяется массово к SIMD-операциям.

• adastra22 предлагает NotNan<f64> из ordered-float как существующее решение для безопасного представления float без NaN, что может частично решить проблему, о которой спрашивает modulovalue.

• Archit3ch отмечает, что Julia позволяет расширять компилятор без патчинга, что контрастирует с Rust и подчёркивает уникальность подхода Fearless SIMD в рамках статической типизации.

• O3marchnative подтверждает, что Fearless SIMD был выбран после оценки других portable SIMD-крейтов, и именно его функциональность позволила завершить порт PhastFT, что указывает на его превосходство над альтернативами.

This is quite amazing. Fearless SIMD is what finally allowed my FFT crate, PhastFT, to run on stable Rust [0]. PhastFT previously depended on Rust’s std::simd (as well as multiversion), which still requires nightly [1].One of the main contributors to v1.0 of fearless_simd started out by helping me… — @O3marchnative

AMD Ryzen 7 9800X3D (Zen 5) показал прирост производительности около 50% за два года по сравнению с 5800X3D (Zen 3) в Geekbench 6: однопоточный результат вырос с 2016 до 2969 баллов (+47%), многопоточный — с 11 832 до 18 751 (+58%). Это произошло не за счёт тактовых частот: максимальный boost увеличился лишь с 4,5 ГГц до 5,2 ГГц (+15%). Основной вклад внес рост числа транзисторов — с ~11 млрд до 16 млрд (+50%), направленный на улучшение ядер.

Архитектурные улучшения включали увеличение ширины выдачи инструкций с 6 до 8 за цикл, рост количества целочисленных ALU с 4 до 6, расширение буфера переупорядочивания с 256 до 448 записей, удвоение L2-кэша на ядро (512 КБ → 1 МБ) и увеличение L1 данных с 32 КБ до 48 КБ. Для SIMD-операций Zen 5 перешёл на четыре 512-битных блока (против четырёх 256-битных в Zen 3/4), удвоив ширину загрузок и хранилищ. Эти изменения сделали ядра значительно шире и эффективнее, подтверждая тренд на рост параллелизма на уровне микроархитектуры. Zen 6 может продолжить эту траекторию с ещё более радикальными изменениями.

Заявление о 50% росте производительности Ryzen за два года преувеличено: интервал между X3D-версиями Zen 3 и Zen 5 составляет около 4 лет. Прирост обусловлен не только архитектурой, но и переходом на DDR5, увеличением кэша L3, техпроцессами TSMC (7nm, 5nm, n4p) и ростом числа транзисторов с 11 млрд до 1 трлн при увеличении частоты всего на 15%. Дополнительный вклад внесли обновления Linux-ядра (6.18–7.3), давшие ~8% прироста на EPYC. Zen 5 демонстрирует рекордные IPC и кэш-хиты (6.0 IPC/core при 5.1 ГГц, >99.8% предсказания ветвлений, >99.99% попаданий в L2). Процессоры Zen 5 и EPYC 9454P показывают феноменальную эффективность в IO-интенсивных задачах и работе с большими базами данных. В целом Threadripper и EPYC превосходят Xeon и Core по производительности и энергоэффективности. Пользователи систем 2019–2020 годов отмечают их долгосрочную жизнеспособность. Владелец 64-ядерного Threadripper PRO 3995WX считает, что ему больше не потребуется апгрейд. Оговорки и сравнения: — Сравнение с Apple M1/M4 несправедливо: Apple достигла 52% роста в однопоточном режиме за 3 года, и x86 не сокращает этот разрыв. — Современные CPU сближаются с VLIW-архитектурами за счет расширения конвейера и гибкого управления ресурсами. — Ранние X3D были ограничены термически, поэтому последующий рост — это накопление улучшений, а не резкий скачок. Рекомендации: — Для большинства апгрейд выше 5700X3D не оправдан из-за высокой цены DDR5 (в 2 раза дороже за ГБ) и малой разницы в играх. — Для серверных задач с высокой пропускной способностью памяти рекомендуется EPYC 9454P с 384 ГБ RAM.

Xiaomi’s новое процессорное ядро Xring O3 демонстрирует резкий сдвиг в архитектуре мобильных чипов: оно превосходит Apple по многопоточной производительности и оснащено 44 МБ кэша — больше, чем у большинства ноутбучных Intel-процессоров. Ядра C1-Ultra имеют 21 порт выполнения, включая шесть для SIMD-операций по 128 бит, что превышает количество портов у современных Intel и AMD. Хотя AMD Zen 5 опережает в обработке 512-битных векторов, для ARM это рекордная ширина SIMD.

Основной тренд — взрывной рост числа исполнительных юнитов и кэша. Процессоры теперь нацелены на параллельную обработку тысяч независимых операций в цикл: сложения, умножения, матричные вычисления через SME2 и SVE2. Это не просто ускорение — это переосмысление вычислений под задачи ИИ и высокопроизводительных вычислений. Большинство транзисторов теперь тратятся не на частоту, а на параллелизм и объём кэша, что делает мобильные чипы конкурентоспособными даже с десктопными решениями.

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

• Спор: Некоторые отмечают, что Xring O3 использует готовое ARM-ядро C1-Ultra, как и MediaTek, и Xiaomi не создавала собственную архитектуру ядра, лишь настраивала интерконнекты и физическую реализацию на TSMC 3nm.

• Спор: Хотя многопоточная производительность выше, однопоточная уступает Apple M5 Max, что ставит под сомнение утверждение о полном превосходстве, особенно в реальных сценариях использования.

• Все согласны, что ключевой метрикой является производительность на ватт, а не абсолютная скорость — многие отмечают, что высокая мощность и кэш не имеют значения, если устройство перегревается и деградирует под нагрузкой.

• Реальные результаты в смартфоне с ограничениями охлаждения и энергопотребления могут быть на 20-30% ниже лабораторных, как это было с MediaTek Dimensity 9500, что делает текущие цифры сомнительными.

• Большой кэш в 44 МБ указывает на то, что узким местом теперь является не вычислительная мощность, а задержка доступа к памяти — это подтверждается несколькими участниками, ссылающимися на архитектурные ограничения.

• Разработчики отмечают, что реальный успех зависит не только от железа, но и от поддержки Linux-ядра, драйверов, инструментов и стабильности экосистемы — всё это пока неизвестно для Xiaomi Xring O3.

• Большинство считают, что Apple остаётся лидером в энергоэффективности и интеграции железа с ПО, и даже при высоких цифрах в бенчмарках Xiaomi не дотягивает до целостности ecosystem Apple.

• Несколько участников подчеркивают, что данные пока основаны на прототипе, а не на финальном продукте в телефоне — это делает любые выводы преждевременными.

• Совет: Стоит ждать независимых тестов и анализа тепловых кривых, а не полагаться на анонсы — как отмечает @StrLght, третьих сторонных данных пока нет, и это критично для оценки.

• Совет: Сравнивать только с Apple не имеет смысла — экосистема iOS/macOS и управление ресурсами важнее, чем цифры в Geekbench, как пишет @bee_rider — переключение ОС не основывается на бенчмарках.

• Совет: Интересно, что производительность GPU близка к M5, но в Android-устройствах она будет сильно ограничена драйверами и термическим лимитом — как отмечает @simjnd, это снижает практическую ценность.

• Спор: Некоторые считают, что Xiaomi не может использовать TSMC и вынуждена использовать китайские литографические процессы с низким выходом годных кристаллов — что объясняет редкость таких чипов, как пишет @hn_submit.

• Китайский прогресс в полупроводниках — это реальность, но его масштабирование и надёжность остаются под вопросом, особенно в контексте безопасности и архитектурных уязвимостей, как в случае Loongson, упомянутых @angry_octet.

• Потребительский опыт с Xiaomi — хороший, особенно по соотношению цены и производительности, как отмечают @rawoke083600 и @otterley, но это не означает технологическое превосходство над Apple.

• Совет: Стоит смотреть на видео с анализом кристалла и кривыми производительности-потребления, как предлагает @picture — там можно увидеть реальные термические характеристики, а не только цифры бенчмарков.

Missing the most important metric: processing power per watt.I have some server CPUs laying around that can also beat Apple CPUs. But putting them in a compact, densely packed, sealed box (aka a phone) would result in a fireball and almost no battery life. — @strictnein

Go 1.27 выводит язык на новый уровень: впервые поддерживаются generic-методы, позволяющие писать универсальные функции для всех числовых типов без дублирования кода. Например, Rand.N[Int intType](n Int) Int заменяет три отдельных метода для int32, int64 и int. Также теперь можно напрямую инициализировать вложенные поля через ключи — например, Burrow: "Burrow #42" в embedded-структурах. Функции высшего порядка стали ещё гибче: их можно использовать в литералах, конвертациях и каналах без явного указания типов.

Новые инструменты ускоряют разработку: go fix автоматизирует переход на современные практики (например, замену устаревших вызовов на slicesbackward), а go mod tidy упрощает управление зависимостями, группируя их в два блока. В стандартной библиотеке появилось native UUID, SIMD-ускорение для вычислений и новый JSON-парсер с улучшенной производительностью. Особенно важно, что размерно-специализированное выделение памяти сокращает затраты на мелкие объекты на 30%, а профиль goroutineleak теперь доступен по умолчанию — это революция для отладки утечек корутин. Эти изменения делают Go не просто быстрым, но и умным: меньше кода, меньше ошибок, больше производительности.

Generic-методы и инициализация вложенных полей снижают boilerplate, но вызывают риски: регрессии в gopls и linters, баги при перекрытии полей в embedded-структурах (по опыту @pjmlp, @sethops1). Алгоритм uscale для парсинга float не упомянут в релиз-нотах, несмотря на значимый прирост производительности (@e4m2, @dolmen). Стандартный пакет uuid спровоцировал запросы на замену github.com/google/uuid в крупных проектах, включая Kubernetes (@guessmyname, @patabyte). Улучшения SIMD и JSON-парсинга снизили потребление CPU и памяти (@tschellenbach, @todotask2). Споры: о темпах перехода на постквантовую криптографию — проактивность команды crypto (@teabee89) vs. замедление прогресса из-за конкурирующих приоритетов (@halJordan); о философии Go — усложнение и сходство с Java/C# (@pregnenolone, @freakynit) vs. эффективность и удобство многопоточности (@tonymet, @ejboy). LLM эффективны как транслираторы скалярного кода в SIMD-интринсики, но уступают ассемблерной оптимизации (@tyho). На go.dev отсутствует подсветка синтаксиса, затрудняя чтение документации (@xavdid, @pmkary).

RISC-V обещает захватить рынок недорогих микроконтроллеров, но не благодаря продуманному дизайну, а вопреки его недостаткам. Главная проблема — попытка универсального решения: одни требования предъявляются к суперкомпьютерам, другие — к дешёвым ядрам, где важны размер и задержка прерываний, а не производительность вычислений. Автор подчёркивает, что даже если RISC-V победит у 8051, это произойдёт лишь потому, что рынок микроконтроллеров требует простого, дешевого решения, а не потому что ISA идеально подходит.

В статье также критикуются «непрактичные» решения: излишняя сложность спецификации, отсутствие реального опыта разработчиков и «дизайн по комитету», где реальные пользователи остаются в стороне. Автор сравнивает это с ошибками ARM, где указание ядра недостаточно, а поставщикам операционных систем приходится адаптировать образы под бесчисленные платформы. Кроме того, упомянута неудача с векторным расширением — лучше использовать фиксированную ширину SIMD, как в традиционных решениях. Эти пункты подчеркивают, что RISC-V часто упускает из виду реальные инженерные ограничения в пользу теоретических возможностей.

RISC-V не идеален — у него есть недостатки, включая сложность из-за избыточности опций, что может вызывать проблемы с совместимостью и поддержкой. Однако его открытость и гибкость делают его привлекательным для разработчиков. Опыт @jacksons5f подтверждает: RISC-V можно успешно применять в продакшене. Несмотря на критику, экосистема активно развивается, а архитектура доказывает работоспособность в разных средах.

Go 1.27 вводит возможность объявлять типы параметров в методах, что позволяет размещать обобщённые операции непосредственно внутри типов, а не только как функции верхнего уровня. Например, метод Map[U any](f func(T) U) можно добавить к структуре Box[T], позволяя преобразовывать элементы одного типа в другой через цепочку вызовов Map. Это упрощает код и делает его более интуитивным, но интерфейсы по-прежнему не поддерживают обобщённые методы.

Новые возможности включают более гибкую работу со структурами: в литералах теперь можно использовать любые селекторы полей, включая те, что наследуются от встроенных структур, что удобно для работы с промотированными полями. Также добавлены улучшения в обработке ошибок, производительности (специализированные аллокации и экспериментальный simd), а также обновления в криптографии и удобстве разработки, такие как стандартный пакет uuid и выпуск json/v2. Эти изменения делают Go 1.27 значимым шагом в развитии экосистемы, особенно для тех, кто активно использует обобщения и структурированные данные.

В обсуждении введения generics в Go 1.27 участники расходятся: одни считают, что они упрощают и делают код более интуитивным, другие — что усложняют и снижают читаемость. Некоторые видят в этом естественное развитие языка, другие — его сближение с Java или C++. По опыту @fauigerzigerk, generics полезны, но требуют осторожного применения.

SIMD — это возможность выполнять одну операцию над несколькими элементами данных одновременно: вместо сравнения одного байта процессор может сравнить четыре, восемь или даже более за один такт. Это особенно выгодно, когда в коде встречаются «тяжёлые» циклы, сканирующие массивы, строки или байтовые последовательности, а обработка происходит сотни‑миллионов раз. В таком случае локальное ускорение пропорционально ширине вектора, а писать такой код можно без прибегания к ассемблеру. Таким образом, даже простая замена обычного for‑цикла на обработку блоками по 4‑8 элементов даёт ощутимый прирост, и эту идею может понять любой разработчик.

В большинстве случаев SIMD‑код строится по одной схеме: сначала широковещательно задают константы, затем перебирают данные порциями вектора, выполняют над ними одну инструкцию, после чего сводят векторный результат в скаляр и завершают обработку оставшихся элементов. Эта пятишаговая последовательность повторяется в разных задачах — от подсчёта совпадений до трансформации изображений — и позволяет писать код так же просто, как обычный цикл, лишь добавляя несколько специфичных функций. Поэтому любой разработчик, увиделший «тяжёлый» проход по массиву, может сразу представить, как заменить его на обработку вектором, не углубляясь в ассемблер и получая ускорение.

Современные компиляторы часто автоматически векторизуют код, поэтому ручная оптимизация SIMD не всегда необходима. Тем не менее, понимание ограничений и возможностей SIMD важно для оценки производительности. Рекомендуется сначала оптимизировать структуры данных и шаблоны доступа — это может дать больший эффект, чем SIMD. Для упрощения использования SIMD предпочтительны высокоуровневые библиотеки, такие как pandas или polars. SIMD оправдывает себя при обработке больших объёмов данных, но не всегда приносит выигрыш, особенно при автоматической векторизации.

В 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 всё ещё молодой язык и что сообщество может в конце концов решить эту проблему, как это было с другими функциями в прошлом.

FFmpeg/asm-lessons — репозиторий с уроками по ассемблеру для FFmpeg.
Цель: научиться писать высокопроизводительные рутины на x86-64, ARM и других архитектурах, ориентированные на мультимедиа-задачи.

Содержание (кратко):

• Уроки: от базовых инструкций до векторных расширений (SSE/AVX, NEON).
• Примеры: реализация IDCT, фильтров, цветового преобразования.
• Тесты: юнит-тесты и бенчмарки для сравнения C vs asm.
• CI: автоматическая проверка на x86-64 и ARM через GitHub Actions.

Как начать:

1. Клонируйте репо.
2. Установите nasm, yasm или llvm-mingw.
3. Соберите пример: make lesson01.

Полезные ссылки:

• Документация FFmpeg
• x86 SIMD
• ARM NEON

• Пользователи восхищаются масштабом FFmpeg и экономией вычислений даже при небольших улучшениях.
• Обсуждаются случаи, когда ручная сборка быстрее intrinsic’ов, и инструменты для поиска «горячих точек».
• Некоторые ждали более глубокой связи с FFmpeg, а не общее введение в ассемблер.
• Поднимаются вопросы портативности (пока только x86-64), необходимости математических подготовок и перегруженности NASM-макросами.
• Большинство соглашается: писать LLVM IR вручную нет смысла, проще использовать inline-assembly или векторные инструкции.