Hacker News Digest

При оптимизации кастомной ограниченной приоритетной очереди автор столкнулся с парадоксальным случаем, когда уровень оптимизации O3 работал на 123% медленнее, чем O2. Этот результат был подтверждён на процессорах Intel Haswell и AMD Zen 3, что указывает на системную проблему, а не на специфичную для архитектуры. Бенчмарки проводились с использованием criterion, а результаты демонстрировали устойчивую регрессию производительности при повышении уровня оптимизации.

Реализация использует отсортированный Vec с бинарным поиском вместо бинарной кучи, что эффективнее для данного случая из-за требования уникальности id элементов. Ключевую роль играет функция сравнения, работающая с числами с плавающей запятой, которые известны своей сложностью в сравнении. Для анализа производительности автор использовал flamegraph, чтобы выявить разницу в поведении между уровнями оптимизации.

Nice read. Last week I wrote a blog post about two noteworthy cases of O3 being slower than O2 in C++: https://barish.me/blog/cpp-o3-slower/ In the branchy function, id is only compared if distance is equal, and since distance is a random float, this almost never happens and the

Матричные ядра AMD CDNA3 и CDNA4 архитектур ускоряют матричные операции FMA для AI и HPC, особенно эффективны в смешанной точности: входные матрицы используют FP16, FP8 или FP4, а аккумулятор остаётся в FP32 для сохранения точности. На CDNA4 (MI355X) FP8 даёт 32-кратный прирост против FP32, а FP4 и FP6 — до 64-кратного, благодаря новым инструкциям с масштабированием блоков экспонент.

Низкоточные форматы, такие как E4M3 (FP8) или E5M2 (BF8), оптимизируют компромисс между диапазоном значений и точностью за счёт битов экспоненты и мантиссы. Например, E4M3FN представляет числа до ±448 с 3-битной мантиссой, а E5M2 — до ±57344 с 2-битной. Важно учитывать зарезервированные значения для NaN и бесконечностей, которые ограничивают рабочий диапазон.

• Радость по поводу увеличения публикаций об использовании аппаратного ускорения AMD для матричных вычислений и приветствие большего разнообразия в этой области.
• Критическое мнение о том, что архитектура GPU плохо подходит для матричного умножения из-за особенностей работы потоков и мультипроцессоров.
• Указание на то, что публикация исходит от сообщества, а не напрямую от AMD, и положительная оценка этого факта.
• Контраргумент о том, что матричное умножение не должно вызывать неэффективность выполнения на SIMT-архитектуре из-за ветвления.

• half/bfloat/float/double – 4 формата: 16, 16-Trunc, 32, 64 бит
• 0 – единственное число с экспонентой 0
• 2⁵²–1 – максимум значащих бит у double
• 1 – первое число после нуля
• 30 – смещение экспоненты float (127–97)
• (−1)²×2^(e–bias)×1.m – двоичная запись
• ×2× – десятичная мантисса
• Exact – точное десятичное значение
• Δnext / Δprev – шаг к соседнему числу

• Пользователи делятся лучшими визуальными объяснениями IEEE-754: ссылки на статьи Фабьена Санглара и Джулии Эванс.
• Обсуждают «красивую» печать float: нужно 9 значащих цифр для однозначности, но тогда 0.1 → 0.100000001; существуют быстрые алгоритмы Dragon4, Grisu3, Ryu.
• Интересный факт: сравнение float почти работает как сравнение signed-integer битов, если учесть знак и NaN.
• Проблема удаления от начала координат в играх: дальше → хуже точность; Kerbal и Minecraft иллюстрируют «Far Lands».
• Просят добавить fp8/fp4, жалуются на отсутствие денормалей, NaN, ∞ в визуализации.
• Кто-то считает IEEE-754 «дьяволом», предпочитает posits или рациональные числа (Raku/FatRat).