Hacker News Digest

• Структура Strip занимает 8 байт, но автор утверждает, что 259×64+7296 ≈ 24 КБ, что вызывает сомнения в правильности подсчёта памяти.
• Участники обсуждения предполагают, что речь идёт о кэш-линии в 64 байта и false-sharing, а не о фактическом размере структуры.
• Появился вопрос о том, какие именно бенчмарки корректности используются, и как можно было бы проверить корректность рендеров.
• Также обсуждалось, что вывод рендерера является растровое изображение, что требует копирования на GPU, что может быть не нужно на UMA-системах.

Инженер с опытом работы в Intel и Sun развенчивает популярные мифы о CPU-кэшах. Многие разработчики ошибочно полагают, что разные ядра могут иметь устаревшие значения в своих кэшах, а ключевое слово volatile в Java заставляет читать/писать данные напрямую в оперативную память. На самом деле, даже одноядерные системы подвержены проблемам конкурентности без правильных синхронизационных конструкций, а volatile-операции могут быть такими же быстрыми, как доступ к L1-кэшу (в 200 раз быстрее, чем к оперативной памяти), а не к основной памяти.

Современные CPU x86 поддерживают когерентность кэшей на аппаратном уровне через сложные протоколы, такие как MESI. Каждая строка данных в кэше помечается одним из состояний: Modified (измененные данные, источник правды), Exclusive (синхронизированные данные, нет копий в других кэшах) или Shared (синхронизированные данные, присутствуют в других кэшах). Понимание этих механизмов помогает лучше проектировать распределенные системы и избегать ложных представлений о производительности и конкурентности.

Here's my favorite practically applicable cache-related fact: even on x86 on recent server CPUs, cache-coherency protocols may be operating at a different granularity than the cache line size. A typical case with new Intel server CPUs is operating at the granularity of 2 consecut

• Современные компиляторы умеют как микро-, так и макро-оптимизации, но между ними остаётся «запретная зона», где оптимизация неэффективна из-за сложной модели стоимости операций в памяти и ветвлениях.
• Пример: вместо векторизации циклов компилятор может вставить rep movsb, что на старом CPU быстрее, но на новом медленнее.
• Практический вывод: измеряйте, прежде чем оптимизировать; не верьте мифам о «магии» компилятора.

Мне нужна сама статья или новость для пересказа. Вы предоставили только нижний колонтитул сайта YouTube, а не контент статьи, которую нужно обработать. Пожалуйста, предоставьте текст новости или статьи с Hacker News, связанной с YouTube, и я составлю для вас точный и ёмкий пересказ на русском языке в формате Markdown, как вы просили.

• Пользователи обсуждают, что такие проекты как 8-битный компьютер Ben Eater и подобные серии открывают уникальные возможности для обучения, но при этом остаются уязвимы к исчезновению из-за политики частной компании, что вызывает тревогу.
• Участники обмениваются мыслями о том, что не хватает независимой платформы для такого рода контента, и что в идеале должен существовать способ для людей поддерживать авторов напрямую, не полагаясь на рекламу и не подвергая их произволу корпоративных интересов.
• Сообщество отмечает, что такие проекты как Ben Eater и James Sharman демонстрируют высокое качество и влияние, и что они заслуживают поддержки, но в то же время подчеркивают, что важно сохранять исходные материалы и обеспечить их доступность для будущих поколений.
• Участники обсуждают, что в идеале должен существовать способ для людей делиться знаниями и быть в вознаграждении за это, не опасаясь что их труд может быть удален или монетизирован без их согласия, и что в конце концов, такие ресурсы как серия открытых лекций или репозиторий с исходным кодом должен быть доступны для всех и служить общему благу.

Ryan Fleury в своём блоге Digital Grove рассуждает о том, что современные процессоры уже давно многоядерны, но большинство программистов всё ещё пишут однопоточный код, упуская до 90% вычислительной мощности. Он приводит пример: сумма элементов массива может быть распараллелена на 4 ядра, но в итоге выигрыш в 3.2 раза превращается в проигрыш в 1.3 раза из-за накладных расходов на синхронизацию и кэш-коэффициенты. Автор приходит к выводу, что надо не "добавлять" многопоточность в специфические случаи, а с самого начала писать весь код как будто он многопоточен, и тогда не будет никаких "особых случаев".

• Обсуждение показало, что современные языки и фреймворки всё ещё не решают фундаментальную проблему — как писать код, который по-настоящему использует многоядерные CPU.
• Участники подчеркнули, что большинство программистов не имеют ни инструментов, ни культуры для эффективного использования параллелизма.
• Были упомянуты такие концепции как "неявный параллелизм" и "автоматическое распараллеливание", но никто не смог привести примеры их практического применения.
• Обсуждение также затронуло вопрос о том, что большинство задач пользователя не требуют параллельного выполнения, и что производительность часто ограничена не столько CPU, сколько IO или GPU.

• Дискуссия разворачивается вокруг старых обвинений в адрес языка C и архитектуры x86, но участники быстро указывают, что стековые инструкции и концепция вызова функций существовали задолго до C и даже были запатентованы в 1957 году.
• Спор уходит в сторону от предмета: автор статьи не предлагает никакой альтернативы, кроме как упоминания о "сообщениях" без каких-либо деталей.
• Участники также отмечают, что статья игнорирует такие факторы как тепловой бюджет, параллелизм и стоимость транзисторов.
• В итоге обсуждение сводится к тому, что критика не предлагает никакой конструктивной альтернативы и что современные CPU не оптимизированы под конкретные задачи, но и под общий набор инструкций, что делает их универсальными.

Статья разбирает, как структуры данных влияют на производительность Go-программ под современными CPU. Автор подчеркивает, что чтение из оперативной памяти в 60 раз медленнее, чем из кэша L1, и что ложный обмен (false sharing) между ядрами может убить производительность. Показано, как добавление 56-байтовой прокладки между полями структуры устраняет проблему и ускоряет код в 6-10 раз. Другой совет — разделять «горячие» и «холодные» данные и использовать структуры, оптимизированные под кэш-линии. Показано, как профилировать кэш-промахи через perf и как тестировать эффективность структур данных.

• False sharing и cache-line padding в Go приводят к 10-кратному ускорению при использовании структур, разделённых на разные ядра, но требуют ручного управления выравниванием и размером кэш-линии.
• Компилятор Go не переупорядочивает поля структур и не вставляет паддинг, что делает невозможным автоматическое устранение false sharing без кода, что ограничивает оптимизации только ручными методами.
• Пользователи отмечают, что большинство описанных приёмов применимы к другим языкам и что современные компиляторы должны бы справляться с большинством этих проблем автоматически, но в то же время признают, что для низкоуровневой оптимизации лучше подойдут другие языки и инструменты.

Оптимизация ClickHouse для процессоров Intel с ультра-высоким числом ядер

Авторы: Цзебин Сань, Чжиго Чжоу, Ваньян Го, Тьянью Ли

Гостевой пост от инженеров по оптимизации производительности из Intel Shanghai.

Современные процессоры Intel достигают беспрецедентного числа ядер: до 128 P-ядер на сокет в Granite Rapids и 288 E-ядер в Sierra Forest. Многосокетные системы могут иметь более 400 ядер. Тенденция «больше ядер, а не выше тактовая частота» обусловлена физическими ограничениями и проблемами энергопотребления.

Для аналитических баз данных, таких как ClickHouse, большое количество ядер представляет как возможность, так и сложную задачу. Хотя теоретически больше ядер означают больше параллельной мощности, большинство СУБД не могут полностью использовать аппаратные ресурсы. Проблемы параллельной обработки, такие как конфликты блокировок, когерентность кэша, неоднородный доступ к памяти (NUMA), пропускная способность памяти и накладные расходы на координацию, усугубляются с ростом числа ядер.

Оптимизация для ультра-высокого числа ядер

За последние три года мы анализировали и оптимизировали масштабируемость ClickHouse на процессорах Intel Xeon с большим числом ядер. С помощью инструментов профилирования (perf, emon, Intel VTune) мы исследовали все 43 запроса ClickBench на серверах с ультра-высоким числом ядер, выявляли узкие места и оптимизировали ClickHouse.

Результаты впечатляют: отдельные оптимизации ускоряют выполнение запросов в несколько раз, в некоторых случаях до 10x. Среднее геометрическое время выполнения всех запросов стабильно улучшалось на 2–10% для каждой оптимизации. Это демонстрирует, что ClickHouse можно эффективно масштабировать на системах с ультра-высоким числом ядер.

Ключевые проблемы масштабирования

Помимо производительности одного ядра, необходимо решить несколько ключевых задач:

1. Накладные расходы когерентности кэша: Перемещение строк кэша между ядрами требует циклов CPU.
2. Конфликты блокировок: Даже небольшие последовательные участки кода (1%) сильно ограничивают параллелизм по закону Амдала.
3. Пропускная способность памяти: Эффективное использование памяти критично для систем с интенсивной работой с данными.
4. Координация потоков: Стоимость синхронизации потоков растет сверхлинейно с их количеством.
5. Эффекты NUMA: Задержки и пропускная способность памяти различаются для локальной и удаленной памяти в многосокетных системах.

В этом посте summarized наши оптимизации ClickHouse для серверов с ультра-высоким числом ядер.

• Исправление опечатки в заголовке: речь идёт о 288-ядерных серверных процессорах Intel Sierra Forest, а не о "Intel 280".
• Оптимизация ClickHouse под высокоядорные системы: улучшение аллокаторов памяти, борьба с конкуренцией, использование SIMD-фильтрации (ускорение запросов до 35%).
• Обсуждение технических деталей процессоров: отсутствие AVX-512 на E-ядрах Sierra Forest, наличие AVX2 VNNI, сравнение с AMD Zen 4c.
• Проблемы масштабирования: сложности NUMA, contention points на уровне аллокаторов, разделение полосы пропускания памяти.
• Практический опыт использования ClickHouse: высокая эффективность сжатия и скорость агрегации больших данных (миллиарды снэпшотов).
• Критика и предложения: переход с jemalloc на современные аллокаторы (TCMalloc, mimalloc), использование оптимистичного контроля параллелизма.
• Исторический и футуристический контекст: сравнение с устаревшими системами, шутки о запуске 1000 виртуальных машин и размещении целого стойка в одном процессоре.

Java 25: новый CPU-Profiler (1)

В JDK 25 появился экспериментальный CPU-Profiler — метод-сэмплер, который показывает, сколько процессорного времени тратит каждый метод, а не просто «время выполнения». Это важно: метод, ждущий I/O, занимает процессор лишь доли миллисекунды, и старый sampler не видит разницы между ним и вычислительно тяжёлым кодом.

Старый JFR-сэмплер каждые 10–20 мс выбирает 5 Java-потоков и 1 native, просто пробегая по списку. На 32-ядерной машине это превращает заявленный интервал 10 мс в фактические 53 мс, а при смеси Java и native потоков приоритет всегда получают Java. Результат — искажённая картина.

Новый профилировщик измеряет именно CPU-time, позволяя найти узкие места, которые реально жгут ядра, и повысить throughput без догадок.

• JVM за последние годы стал двигателем инноваций: виртуальные потоки, Loom и быстрый цикл релизов делают Java снова «весёлой».
• Большинство участников рады избавлению от реактивного async-кода: «пусть всё будет синхронно и просто».
• Скептики напоминают: виртуальные потоки всё-таки тратят CPU на GC и не решают проблемы доступа к ограниченным ресурсам.
• Кто-то жалуется на качество современных Java-разработчиков, другие отвечают: плохие devы есть везде, язык тут не при чём.
• Автор серии постов анонсировал три продолжения про новый CPU-Tracing в Java 25.

• Второй за год умер Intel Core Ultra 9 285K: после 4-часовой нагрузки (100 °C, 300 Вт) ПК не проснулся из suspend, кнопка питания мертва.
• Первый экземпляр сдох в марте; в отзывах магазина полно аналогичных случаев — больше не верю Intel.
• Комната была под кондиционером (25–28 °C), температура ядра 100 °C в пределе 110 °C, так что дело не в жаре.
• Взял Ryzen 9 9950X3D: быстрее 285K в многопотоке, ~100 Вт меньше под полной нагрузкой, температура 75 °C.
• Плата ASUS X670E-E, 96 ГБ DDR5-6000, остальное железо без изменений.
• Вывод: Intel пока ненадёжен, AMD даёт ту же скорость с меньшим нагревом и расходом.

• Пользователи жалуются на нестабильность современных Intel и AMD: «виснут» в idle, падают под нагрузкой, греются до 100 °C и выгорают.
• Виной всему: заводской разгон «на грани», плохое охлаждение, BIOS-«усилялки» и, возможно, софт-ошибки, проявляющиеся только на новых CPU.
• ECC-память помогает отлавливать тихие ошибки ОЗУ, но на десктопе почти не рекламируется, матплаты поддерживают её «тихо», а модули стоят в 2 раза дороже.
• AMD даёт больше ядер и AVX-512, Intel — стабильнее iGPU и меньше жрёт в простое; выбор чаще делается по цене, политике или просто «что есть в продаже».
• Общий вывод: современные настольные CPU превратились в «лотерею» — нужен тщательный подбор питания, охлаждения и BIOS, иначе рискуете получить дорогой нагреватель.

%CPU — обманка
Система показывает 50 % загрузки, но реально сервер выполняет 60–100 % максимально возможной работы.

Эксперимент
Ryzen 9 5900X (12 ядер / 24 потока), Turbo включён.
Скрипт запускал stress-ng двумя способами:

• 24 потока по 1–100 % нагрузки;
• 1–24 потока по 100 %.

Результаты

• Общий CPU-тест: при 50 % «утилитой» реальная работа 60–65 %.
• 64-битная математика: 65–85 %.
• Умножение матриц: 80–100 %.

Почему так

1. Hyper-threading: после 12 потоков «ядра» делят ресурсы, прирост стремится к нулю.
2. Turbo: частота падает с 4.9 до 4.3 ГГц при росте загрузки, поэтому «утил» растёт быстрее реальной работы.

Вывод
Полагаться на линейный рост %CPU — ошибка. При эффективной загрузке (>50 %) показания занижены, и различия между процессорами могут быть огромными.

• Участники сходятся во мнении, что «%CPU» — это не ложь, а линейная мера нелинейной реальности: SMT, Turbo, общие ресурсы и ожидание памяти делают 60 % «загрузки» фактически пределом.
• Практики SRE подтверждают: модели очередей по CPU% работают лучше «старой мудрости», но только если понимать, что 50–60 % уже «почти всё».
• Несколько человек вспомнили, как менеджеры требовали «увеличить сервер», увидев 100 %, хотя процессор простаивал в busy-wait или ждал I/O.
• Подчёркивается, что IPC, latency, power-draw и прямое нагрузочное тестирование приложения дают более точную картину, чем сырые проценты.
• Утилита stress-ng удобна для синтетики, но не для production-бенчмарков; реальные приложения (Postgres, Memcached) ломаются раньше, чем показывает 100 % CPU.

• Зачем замедлять программу?
  Искать race-conditions, «виртуально» оценить выгоду оптимизации (как в Coz) и проверять точность профилировщиков. Для этого меняют расписание потоков или вставляют задержки.

• Как замедляют сейчас?
  Грубо: Thread.sleep, остановка потоков, вставка лишнего байт-кода. Это снижает точность.

• Наша идея
  Вставлять задержки внутри basic block на уровне x86. Нужны инструкции, которые:
  – надёжно тратят циклы;
  – не искажают семантику;
  – не оптимизируются CPU за счёт out-of-order.

• Проблема
  Современные процессоры выполняют независимые mov параллельно, поэтому просто добавить «тяжёлые» команды недостаточно — нужно учитывать зависимости и микроархитектуру.

• Используются разные способы замедления: от NOP-циклов и RDTSC до AVX-нагрузок и «тормозных» устройств вроде C64 Snail или Turbo-кнопки.
• Замедление помогает выявлять N+1-запросы, неработающие кеши и другие узкие места, которые на быстрых машинах незаметны.
• Современные CPU оптимизируют NOP/MOV на стадии переименования, поэтому они плохо подходят для точного контроля времени.
• Causal-profiling (Coz) и специальные прокси (Toxiproxy, dummynet) позволяют «ускорять» выбранный код, оставляя остальное медленным, чтобы заранее оценить выгоду оптимизации.

• Clearwater Forest — будущий Xeon 7 с энергоэффективными E-ядрами на техпроцессе Intel 18A (≈1,8 нм).
• Clearwater Rapids — параллельная версия с производительными P-ядрами.
• Процессоры полагаются на 2,5D EMIB и 3D Foveros, впервые опробованные в Ponte Vecchio.
• AMD уже контролирует >40 % выручки и >27 % поставок серверных CPU x86; Intel сохраняет 60 % выручки и 72 % поставок.
• Гиперскейлеры активно внедряют собственные Arm-чипы, поэтому каждый x86-сокет ценен.
• E-вариант поможет Intel отладить 18A и 3D-упаковку перед массовым запуском P-ядер.

• Clearwater Forest: 288 E-ядер Xeon 7 на 18A, преемник 144-ядерного Sierra Forest-SP.
• Производительность Darkmont-сore ≈ Neoverse V3/Cortex-X4, уступает Zen 5c.
• 12 каналов памяти вызывают опасения по пропускной способности; для LLM-задач может не хватить.
• Поддержка 2P-систем → до 576 физических ядер в одном сервере, цена vCPU резко падает.
• Пользователи скептичны: Intel «спала» десятилетие, не доверяют свежим заявлениям и микрокоду.

Как «специальные группы регистров» 50 лет жили в словарях

Фраза «special register groups» внезапно появилась в определении «CPU» в 1960-е и до сих пор мелькает в учебниках.

В старом глоссарии Минсельхоза США (1960) читаем:

«MAIN FRAME — центральный процессор; включает основную память, арифметическое устройство и special register groups».

Это описание относилось к мэйнфрейму Honeywell 800 (1959), где для многозадачности каждая из 8 программ получала собственный аппаратный набор из 32 регистров — именно их Honeywell назвала «special register groups».

Определение скопировали чиновники, оно попало в Automatic Data Processing Glossary, затем — в сотни книг и статей. Постепенно «main frame» стало синонимом «тип большого компьютера», а «special register groups» превратились в бессмысленную клишированную строчку, которую перепечатывали до 2017 года включительно.

• Участники обсудили странное определение «special register groups» в старых словарях: оно неясно и не упоминает обычные регистры.
• Упомянули, что IBM в 1954 году определяла CPU как совокупность арифметических и управляющих функций, без «специальных регистров».
• Появились примеры старых машин, например Honeywell 800, где у каждой программы был свой набор регистров — предшественник barrel- и multithread-процессоров.
• Отмечено, что терминология часто копировалась без проверки, создавая «человеческий слаг» вроде «tongue map» или «brushless DC».
• Участники сравнили путаницу в терминах с другими примерами, включая RAM, ROM, SMT и «micom» в японских рисоварках.

Купи быстрый процессор

Современные CPU стали шокирующе быстрыми, но большинство по-прежнему используют старые мобильные чипы, теряя продуктивность.

Подписка на AI-инструменты вроде Cursor стоит $480/год, а топовый Ryzen 9 9950X — всего $500. Амортизация за 3 года = $170/год: дешевле, чем AI, и выгода очевидна.

Бенчмарки

• Корпоративный ноутбук 2024 (i7-1165G7, 2020 г.)
• Лучший ThinkPad 2024 (Ryzen 7840U)
• Десктоп 2025 (Ryzen 9950X)

Разница — >10× на компиляции ядра Linux и TLS-операциях. 3 с против 30 с или 300 мс — это кардинально меняет опыт.

Правило:

• Десктоп ≈ 3× быстрее ноутбука
• Топ-CPU 2025 ≈ 3× быстрее топа 2022
• Новые облачные VM тоже 2-3× быстрее за ту же цену

Если вы оправдываете AI-подписку, оправдайте и лучший инструмент — быстрый CPU.

• Почти все согласны: «быстрый процессор = меньше ожидания компиляции → выше продуктивность», и ROI для старших разработчиков окупается за недели.
• Но выгода сильно зависит от задач: многие уже компилят в облаке/сервере, а фронтенд-сборки всё равно тормозят из-за однопоточных инструментов.
• Некоторые 10-летние CPU (i7-4770, Phenom II) всё ещё «достаточно быстры», если добавить RAM и SSD; апгрейд не всегда оправдан.
• Ноутбуки ограничены теплопакетом: «топ-чип в лэптопе ≠ тот же чип в десктопе».
• Итог: берите максимально быстрый десктоп, если компилируете локально; если работаете в облаке — экономьте деньги и нервы.

PCI-SIG анонсировала PCIe 8.0

• Пропускная способность вдвое выше PCIe 7.0: до 256 ГТ/с на линию.
• Технология: PAM4, 32 ГТ/с, 0,5 В амплитуда, < 1 Вт/лейн энергопотребление.
• Обратная совместимость с предыдущими поколениями.
• Спецификация выйдет в 2027 г., первые продукты — 2028–2029 гг.
• Цели: ИИ-акселераторы, HPC, NVMe-накопители, 800 Гбит/с сети.

• Кто-то предлагает «перевернуть» архитектуру: пусть GPU-PCB станет материнской платой, а CPU с памятью встаёт в PCIe-слот.
• Обсуждают, что PCIe-спецификация всегда на три поколения впереди реальных продуктов: сейчас в работе уже Gen 8.
• Пользователи жалуются на нехватку линий PCIe в десктопах и мечтают о GPU-сокете с собственными слотами RAM.
• EE и другие специалисты считают это скорее проблемой экосистемы и совместимости, чем чисто инженерной.
• Упоминают, что в дата-центрах (DGX, DPU, NVMe-«без-сервера») похожая идея уже реализована.