Hacker News Digest

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 или векторные инструкции.