https://www.securitylab.ru/news/564421.php

Компилятор иногда разбивал корректировку стэкпоинтера в эпилоге функции на две инструкции. Поскольку долгоиграющие функции с 1.14 прерывались насильно сигналом SIGURG, иногда они заставали исполнение как раз между ними двумя, таким образом ломая стэк. Иногда - сегфолт, иногда - само неконсистентность стэка замечало. В 1.25, вроде как, исправили, выполняя операции сначала на временном регистре.

Вроде слабо, а вроде и у чуваков по 30 раз на дню падало. Вот уж соболезную)

https://en.wikipedia.org/wiki/Pentium_FDIV_bug

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

Случайности не случайны!

В Zen5, тобишь. У них инструкция RDRAND сильно предвзята по отношению к нулю - возвращается в более 10% вызовах, при том с флагом успеха (регистр CF=1). Подозревают, что сам регистр некорректно определяет успешность операции, вот и помечает успешным то, что таковым не является.

При том это их не первый раз. На Zen2 уже было такое 6 лет назад, что после сна/гибернации инструкция начинала возвращать все включённые биты. Там аж системд стартовать отказывалось (поттеринг в ишшуе отослал автора к ядрописцам, конечно же).

Кстати, сам рандом они генерируют из тепловых шумов. Интересно, а они тоже просто взяли ринг буфер как пул энтропии?


Актуальный багрепорт + фикс ядра: https://lore.kernel.org/lkml/20251016182107.3496116-1-gourry@gourry.net/
Как это было когда-то: https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd-microcode-bug-destroyed-my-weekend/

Кстати, у интела оно интересно устроено. Исходя из вики, они сначала берут сырой поток данных с тепловых датчиков, формируют из них пары по 256 бит и прогоняют через AES. В итоге имеем один монолитный кирпичик 256 бит отменной энтропии, что используется в качестве сида для ГПСЧ (NIST-certified, вся хуйня; правда, называют они его DRNG - digital random number generator). Каждые ~64 килобайта генератор ресидится.

Рядом ещё есть RDSEED, оно использует всё те же тепловые флуктуации, только работает асинхронно (отдельно от основного чипа) с собственной фиксированной тактовой частотой 3ГГц. Медленнее, чем RDRAND, предназначен так же, как и назван - чтобы софтварные ГПСЧ сидить случайными числами произвольной ширины. Что, по всей видимости, и есть ключевая разница от RDRAND, который годится приложениям, которым нужен просто качественный рандом фиксированной ширины.

Правда, состояние генератора они держут общим между всеми ядрами. Ну, то есть, лежит общий некий стейджинг буфер, из которого любой может спокойно читать. И в 2020 году мужики из амстердамского университета показали, что с первой попытки можно целый ECDSA ключ сразу после подписи извлечь, если с соседнего ядра вовремя тот самый буфер почитать. А это - классическая проблема с исполнением недоверенного кода, когда он может что-то пиздить у доверенного соседа. Выпустили заплатку микрокодом, теперь RDRAND, RDSEED, EGETKEY (кто?) выполняются исключительно одним ядром за раз, остальные ждут. Просто по завершению тот стейджинг буфер перезаписывается. Задели целый ряд процов с 2012 по 2019 годы, а фикс, по классике, вкурвил и без того низкий перф (софтварные ГПСЧ кратно быстрее, что удивительно; Mersenne-Twister так и вовсе во все 20 раз).

А ещё Теодор Тсо (тот, который умнее тебя и всей твоей семьи вместе взятой) высказывал сомнения по поводу этой штуки. Мол, интеловцы хотели в ядре продавить свой RDRAND как единственный источник для /dev/random. Что, естественно, а) небезопасно (в том числе благодаря прецедентам с AMD выше) и б) просто стрёмно. Ну, то есть, мы сейчас возьмём и пересадим почти весь серверный сегмент на рандом из впаянного чипа, который никто не знает, как работает, никто не может провести аудит, так он сам ещё и от около-государственной корпорации? Звучит надёжно, наливайте!

Ну, то есть, он используется, как один из источников. Но в 2013 оказалось, что всё сыпется, если туда оказывается посажен бэкдор, нацеленный на конкретный код (маловероятная ситуация, не так ли?). Проблему смягчили (вероятно, снизили общую долю в пуле или подкрутили ϵ, чтобы оттуда более униформные значения лезли; позже и об этом пост будет). Во FreeBSD инструкцию вообще от греха подальше вырезали.


В общем, очередное напоминание, что рандом - это сложно и ответственно, а блэкбоксы - плохо. AMD не хватает побольше тестирования.

Чем дольше всматриваешься в бездну, тем больше Тьюринг-полноты вокруг замечаешь. JustWiFi7 - в свой большой компьютер ты втыкаешь маленький компьютер под линуксом, который крутится на кастомной фирмвари. Теперь линукс запускается ещё и на формфакторе ноутбучной оперативки. Зато блютуз-адаптер на моём линуксе — нет. Этот маленький пидорский кусочек пластика рандомно отъебнул и теперь заводится где угодно, кроме моей машины. Я его матушку.

Калькуляторы - это сложно.

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

Но всё всегда начинается с азов. Ещё 7 лет назад я начинал писать калькулятор, и всё ещё не кончил. Первый раз всегда плох.

Сперва идут три инпута - левый операнд, оператор, правый операнд. Если появится мысль считать многочлены в одной строке - ты попался.
Сначала ты как-то умудряешься доставать одночлены из входной строки с наибольшим приоритетом - и подставлять вместо них результат. Скорее всего - прям в строку.
Происходит эпоха Просвящения - ты узнал про обратную польскую нотацию. Но парсишь всё так же плохо.
Если умный, то быстро узнаешь про алгоритм сортировочной станции, чтобы твои выражения парсить. Вкратце - алгоритм с вхардкоженной грамматикой, зато и вызовы функций умеет, и приоритеты правильно распределяет, да и выхлоп сразу в ОПН. Блажь.
Добавляешь переменные и объявления функций. Простенькая стэковая машинка начинает разлагаться на плесень и на липовый мёд.
Открываешь для себя полноценные парсеры с настоящим AST, как у взрослых дядь. Теперь считать чуть сложнее, но ты справляешься - достаточно тот AST рекурсивно сколлапсировать до единственного узла - результата. Появляются неймспейсы.
На этом моменте, твой калькулятор уже практически полный по Тьюрингу, остаётся только добавить ветвления и векторы. Появление нового типа заставляет тебя задуматься, как складывать векторы с функциями. Это чеховское ружьё.
Рано или поздно, ты всё-таки внимаешь драгонбуку, основе основ всея разработки компиляторов. Узнаёшь про лексический анализ, грамматики, виды парсеров и прочие приятные штуки. Но всё равно ещё долго будешь держаться за привычный recursive top-down, потому что он словно подол материнской юбки посреди толкущейся толпы.

Дальнейшая история здесь расходится на два возможных пути (отступничество не рассматривается):

1. Твой интерпретатор постепенно становится всё более серьёзной штукой с более внятной системой типов (тут-то ружьё и стреляет), со своим байткодом и потенциально IR, и вероятно - со временем даже превратится в компилятор. Тогда у тебя не остаётся вариантов, как вводить строгую типизацию, потому что так банально проще. Ты теперь разрабатываешь полномасштабный императивный язык.

2. Случайно решаешь посмотреть, кто такие лямбда исчисления и кого они считают. Оказалось, твои извилины. Потом будет логика, теория типов и неизбежный пиздинг из Хаскелла, как наиболее продвинутого прикладного типизированного лямбда-калькулюса. Ты теперь разрабатываешь функциональный язык, соболезную.

То есть, из абсолютно тривиальной задачи можно прийти к поистине монструозным результатам. Я себе как-то раз хотел научный калькулятор заделать, чтобы вместо питона его использовать, так столкнулся с контекстно-зависимой грамматикой - в зависимости от типа переменной, одно и то же выражение могло бы означать как применение функции, так и обычное неявное умножение (у которого, фанфакт, приоритет выше обычного умножения и даже деления). Забросил:(

А ведь это всё ещё (практически буквально) детские игрушки. Google в 2014 нанял Hans-J. Boehm, тот, который свой эффективный сборщик мусора написал. И поручили они ему калькулятор для Андроида сделать. И это оказалось настолько сложным, что он попросил помощи у своих коллег. Если вкратце, то от представления рациональных парой числителя и знаменателя он дошёл до представления полиномами, а для трансцедентных (как вот e и pi) использовал Real Recursive Arithmetic; но только там, где нельзя применить обычные символьные вычисления, потому что RRA - на то и рекурсивная, что никогда не остановится даже для абсолютного нуля. А это не очень прикольно для той же тригонометрии с её sin(pi).

Крайне рекомендую почитать полную статью, она довольно короткая, но исключительно занимательная: https://chadnauseam.com/coding/random/calculator-app

Считаем такты, или почему иногда стоит задумываться при переносе выражений в код.

Конкретнее, интересна строчка с объявлением combinedInvMass. В ней мы складываем два обёрнутых значения. 1 операция сложения и 2 операции деления. Если немного переписать выражение, то получим a+b / ab (где a, b - массы). 1 сложение, 1 умножение и 1 деление - в сумме операций остаётся всё так же три, но теперь на одно деление меньше. И в горячем пути (а он прям раскалённый) это даст нихуя себе выигрыш!

Стоимость деления в процессорах традиционно кратно выше стоимости умножения, в масштабах примерно 20-40 против 1-7 тактов соответственно (ну примерно). Просто потому, что умножать и само по себе проще, так ещё и легче по АЛУ раскидать, чтобы за такт несколько штук параллельно молотить - это, кстати, и есть то самое спекулятивное выполнение, о котором все говорят. Однопоточный код всё ещё прекрасно параллелится в транзисторах:)

Меньше делите — меньше энтропия расти будет. Ощасливьте котят!

Деление можно делать по Евклиду. Итеративно вычитаем, пока есть что (или не надоест). Но получается дороговато для больших чисел, да и за такт всего один бит считается. Неприятно.

В 1957-58 сразу трое додумались, как делить лучше. SRT алгоритм, который де-факто стандарт в процессорах, устроен интереснее: берём два самых значимых бита делителя и делимого и используем, как ключи для лукап-таблицы, в которой лежат коэффициенты (5 чисел {-2, -1, 0, 1, 2}). На полученный "угаданный"* коэффициент умножается делитель, результат произведения вычитается из делимого. Это наш остаток. Коэффициент сохраняем в регистр, сдвигаем его на 2, как и остаток на 2 влево. Повторяем цикл, только теперь используя в качестве индекса для таблицы два наиболее значимых бита у нашего остатка. Графически - берём по 2 бита с числителя и знаменателя, делим с остатком, результат переносим вниз и к нему дописываем следующие два бита числителя, остаток сохраняем.

*угаданный - он может подобраться и неправильно. Просто тогда ошибка скорректируется на последующих шагах, в чём и заключается вся прелесть метода.

Объяснение очень грубое (не потому, что для хорошего нужен интеллект, а потому, что я вас не люблю), но можете почитать от непосредственно интела, что это за вещь такая. Неплохо графически показывают шаги тут. А здесь фундаментально рассказывают, как оное в железо засовывать.

С SRT теперь можно делить не по одному, а по двум битам за такт, что дало очень ощутимый буст в производительности. Но как раз из-за этого и случился фокус жопы у интела с делением. Тогда проблема была в этой самой лукап-таблице - из 1066 вхождений, 5 забыли заполнить, имея в итоге 0 там, где должен был бы быть +2 — а всё потому, что паттерн для принтера херово скомпилировали.

Статистически, ошибка должна была бы всплывать лишь раз в 27000 лет. Но обнаружили её спустя всего 5 лет после релиза. День новый, а статистика брешет, словно в первый.

https://www.bitflux.ai/blog/memory-is-slow-part2/

TL;DR и IO тоже делать надо грамотно. А ещё mmap() ощущается неправильным, и файлы им читать не очень круто - даже если уже в кэше лежит, всё равно на каждую страницу придётся прерываться.

По традиции приебусь к мелочам.

Там в бенчмарке десятки считают, и считалку эту заоптимизировали в вот это. В скрин не влезло, но там выше ещё убедили компилятор, что данные в памяти выровнены по 4096 байтам, так что обращения за границы не вылезут. Это важно, потому что теперь компилятор может со спокойной совестью векторизировать это всё.

Выглядит страшно. Но идея здесь в том, чтобы показать компилятору, что все 16 путей в теле цикла - независимы, включая персональные счётчики (чтобы всё в один регистр не нести). Теперь, если не векторизирует, то хоть камушек по всем доступным АЛУ раскидает, больше операций за такт перемолет.

Сложения ниже отыгрывают ту же роль. Хоть в gcc это практически ничего и не даст (с -O2 вырезаны подчистую), другим компиляторам это может очень даже помочь. Clang вот выдал лесенку сложений, которые уже процессор сам дальше переварит.

В общем, оптимизации - дело тонкое. Не менее тонкое, чем бенчмарки:)

xor eax, eax?

Мэтту Годболту яйца зачесались выпустить свой Advent of, но только про компиляторные ну немного анальные, да эквилибристики.

Ровно эта штука, о которой он в первом дне у себя рассказывает, мне попадалась вот здесь. Как оказалось, фокус xor'ить регистр с самим собой - имеет как практичный, так и побочный эффекты:
а) инструкция xor на х86 занимает 2 байта, когда как обычный mov eax, 0 пирует на все 5. Потому что надо ж ещё саму константу операндом хранить. Это практичная часть.
б) во всё том же х86, процессор прекрасно знает, зачем оно такое. И сама инструкция фактически даже не выполняется - просто подкапотное причёсывание с переименованием регистров. Это камню удобнее. А нам - приятнее.

Фанфакт - GCC применяет сию гимнастику, начиная лишь с -О2. А вот Clang не стесняется и тулит безусловно даже на -О0. Технически, шланг это даже за оптимизацию не воспринимает. Высокомерно!

Fast and Space Efficient Trie Searches

Деревья, безусловно, важны. Они из углекислого газа карбон выцепляют, а нам чистый кислород возвращают. Так они ещё и сами по себе красивые.

Но я всё же о тех, которые частный случай ацикличного направленного графа. Как только люди обманом заставили песок думать посредством нанесения наноскопических рун, появилась и нужда в массивах. Статические и динамические, конечно, хороши, но далеко не представляют такого же интереса, как ассоциативные. Когда как статический/динамический массив сопоставляет значения с их порядковым номером (индексом), ассоциативный инкапсулирует порядок и сопоставляет значения не индексу, а произвольному значению из фиксированного множества всех возможных ключей. Так мы, например, можем Хонде сопоставить Цивик, а von - Pavlo.

В общем случае, с этим прекрасно справляются хэшмапы. О которых я, к слову, писал здесь и здесь. А современный SwissMap ещё и показывает, как поиск может утилизировать SSE инструкции. Но не просто так существуют и древовидные структуры данных. Если в сердце хэшмап лежит проблема присвоения ключу его (желательно) уникального номера, то деревья - это скорее про уникальный путь ключа. Они как BlackRock: может, в повседневной разработке особо и незаметны, но неявно присутствуют вообще везде. Файловые системы - это практически всегда деревья. Базы данных - абсолютно RB Tree, как и Epoll в линуксе. Full text search (elastic и ему подобные) - сплошные префиксные деревья. Автокомплит, проверка правописания, IP routing, DNS, LZxx компрессоры - вообще всё на них основано. Даже мне для динамического роутинга в индиге пришлось имплементировать.

Основной принцип у деревьев виртуально прост: стоя у развилки, нам необходимо выбрать, по какому пути дальше идти. Функция выбора и определяет вид. Основных их есть несколько, и о них собственно речь и пойдёт.

Fast and Space Efficient Trie Searches

Решая задачу по физике, gpt-oss:20b допустил ровно ту же ошибку в вычислениях, что и я. Таким образом, эмпирически я пришёл к выводу, что интеллекта у меня с AMD RX9070XT.


Binary tree
Нормализированные данные в принципе вкусные, да и на ощупь приятные. Всегда, сужая общий случай до частного, в процессе у более ограниченного подмножества всплывает всё больше свойств и оголяется структура, из которой могут следовать интересные заключения.

Так и с упорядоченными массивами. Как только оная гарантируется, сложность поиска резко падает с линейной до логарифмической, за счёт возможности применения бинарного поиска вместо линейного. К сожалению, выигрыш в поиске за счёт вставки: теперь, для поддержания гарантии, вставка работает в среднем за линейную сложность. Всё-таки место в массиве само себя не освободит - все элементы правее нужного места должны быть смещены вправо на одну позицию, прямо как в отеле Гильберта. Представьте, какого это: участок на гигабайт переместить на 8 байт правее. Это ж блять чистая комедия.

Однако тривиальность переоценивать - обсёрами чревато. Как, например, в Java 9 лет таилось переполнение при взятии среднего арифметического. Rookie ass mistake. Зато в Go всё изначально в порядке - длина всегда представлена в int, а среднее арифметическое берётся в uint. Лишний бит гарантирует отсутствие переполнения.

А ещё не всегда учитывается субоптимальность обобщённого бинарного поиска по массиву строк. Имея L < key < R (где L, R - строки в массиве), беря их среднее арифметическое (строка в массиве между L и R), нам необязательно её сравнивать полностью с искомым ключом. Потому что ключ заведомо имеет общий префикс с L и R:

int prefix = lcp(L, R);
if (strcmp(key+prefix, mid+prefix) == 0)
  ...

(Где lcp(s1,s2) возвращает длину общего префикса двух строк, а key+prefix аналогичен key[prefix:] в других языках.)

То есть, мы можем опустить сравнение первых lcp(L, R) между искомым и средним арифметическим. А так можно чуть ли не пол строки скрутить. Правда, если строки в массиве всё-таки практически общих префиксов не имеют, то мы лишь расстратимся на лишнюю пару инструкций. Так что вслепую применять всё равно не стоит.

А сейчас - самое интересное. Бинарный поиск по упорядоченному массиву - частный случай бинарного дерева, схлопнутого к одномерному массиву, логично. Но тут сразу вырисовывается неприятное заключение: если на нашем множестве ключей такая оптимизация с отсеканием префикса из сравнения действительно работает, то это означает лишь то, что мы тратим пространство неэффективно. Если столько байт пропускаются, то хули они там вообще забыли?

Fast and Space Efficient Trie Searches

"Сопротивление бесполезно!" Крикнули 40000 вольт. А теперь представьте, какие были остальные варианты вступления, если в конце я выбрал именно этот.


Radix trie, оно же префиксное дерево
Арность (несмешно) - в общем случае описывает количество аргументов либо операндов, принимаемых функцией или оператором. (Технически, ранг матрицы тоже сюда косвенно относится, да.)

В случае деревьев, арность сообщает число исходящих рёбер из узла (не забываем, что узел есть дерево, дерево есть узел; играет роль только тот узел, который мы прямо сейчас воспринимаем за корень). В случае бинарных, логично, это фиксировано два исходящих ребра. Тернарных - три. Можно произвольно много тоже, такое называется variable-arity, или же просто variadic (откуда оно и пошло в С). Но смысл здесь - с арностью можно весело играться. Например, взять дерево с арностью, равной размеру алфавита - и вот мы уже можем искать следующий узел, чей порядковый номер соответствует оному искомой литеры в алфавите. Такое дерево называется m-way trie.

Рассмотрим примитивный пример с деревом, определённом для английского алфавита в нижнем регистре:

struct Trie{
  char c;
  struct Trie* children[26];
}

bool search(struct Trie* trie, char* str) {
  for (; *str; str++)
    if ((trie = trie->children[*str-'a']) == NULL)
      return false;
  return trie->children[0] != NULL;
}

Поиск здесь отвечает лишь за существование строки в дереве и останавливается, либо когда у текущего узла нет наследников, соответствующих нужной букве в строке (вербозный иф), либо когда строка кончается (тогда у узла должен быть non-NULL наследник для 0, он же стандартный терминатор С-строки, он же в роли флага term). Чтобы ассоциировать значения, достаточно просто добавить атрибут с нужным типом, и возвращать его значение у терминальных узлов. Для обобщения поиска, дабы возвращать произвольное ассоциированное значение со строкой, а не просто проверять её вхождение - достаточно лишь добавить соответствующий атрибут к структуре, и возвращать в конце поиска именно его.

Вставка тривиальна: мы траверсим дерево до тех пор, пока в строке не встретится символ, для которого пути дальше уже нет, т.е. точку строки, в которой она отличается от всех остальных вхождений.

Но тут я бы остановился и сделал передышку. При такой вставке, я неявно предполагаю аллоцировать отдельно каждый отдельный узел. Если дерево динамическое (после построения ключи в него могут добавляться или удаляться), тогда такая вставка может быть крайне неприятной по производительности, особенно если нужно вставлять много новых символов. Тут сразу интуитивно приходит мысль аллоцировать сразу по 128-1024 узлов за раз, и потом их постепенно оттуда брать для вставки, коль уж дорог сам факт выделения памяти, а не её количество. Сразу развивая идею, приходим к тому, что дерево в принципе можно целиком всунуть в один большой массив. Всё, что изменится - это вместо struct Trie* у нас будет uint index, хранящий индекс на следующий узел в массиве. int/uint в С занимают фиксировано 32 бита что на х32, что на х64 архитектуре - а это значит, что с исчерпывающим потолком в 4.2млрд узлов в дереве, мы выигрываем лишние 4 байта. Размер структуры на х64 архитектуре, конечно, от этого не уменьшится, потому что выравнивание - но в них взамен можно хранить дополнительную информацию, которая в противном случае занимала бы дополнительное машинное слово. А для деревьев с бОльшим количеством ветвей, даже такая мелочь уже может срезать очень много потребления памяти.

Ещё из плюсов деревьев в массивах - узлы лежат в ОЗУ последовательно, благодаря чему они лучше умещаются в кэшлинии. Вот только, имея узел, в котором массив из 26 чисел - даже один такой в кэшлинию едва ли влезет. И тогда стоит задуматься о том, как хранить именно этот массив более эффективно, а не о том, как выиграть лишних 4-8 байт.

Имеем: статический массив, частично состоящий из нулей. Как потом окажется, очень многие будут состоять преимущественно из нулей. Это точно можно как-то соптимизировать.