Ваш PlayStation 5 умножает числа на три в два раза медленнее, чем ваш ноутбук
После релиза Arm машин я попал в дофаминовую яму из которой я стараюсь выходить всякой рутиной, где я помогал разным проектам (в том числе и всякими оптимизациями в Arm). За последнее время я решил перечитать много литературы, писал много документов и мало кода. It's fine, sometimes there are weeks when you understand completely nothing. Две истории, одна стратегическая, другая практическая, но они связаны.
Я понял, что когда делаю свою работу, я очень мало времени уделяю тулингу в перформансе. Скажем, я делаю процентов 20 анализа данных, что медленно, почему медленно, процентов 40 как это соптимизировать, остальные 40 на то, а как эту историю можно обобщить. Скажем, я недавно писал, как одна доп кешлиния в AMD не выучивается процессором, что она не так уж и важна, дальше вопрос, а в чем различия AMD и Intel, если уж посмотреть глобально. Бенчмарки делались на Intel долго, интересно, есть ли пробелы у AMD, можно ли унифицировать, чтобы всем было хорошо. Нашёл ещё одну историю, но она сильно другая:
На x86 умножение на 3 устроено через старую иструкцию LEA (Load Effective Address). Если коротко, эта иструкция умеет вычислять выражения REG1+X*REG2+Y, где X -- 0, 1, 2, 4, 8, а Y не очень большая константа. В итоге чтобы умножить на 3 надо взять REG1==REG2, X = 2. То есть это сумма X и (X << 1), вполне логично и legacy, которое мы за собой оставили. Инструкции mul/imul работают дольше.
Посмотрев на таблицу инструкций я нашёл, что AMD Zen 2 имеет latency 2, когда как абсолютно все Intel latency 1. Proof.
Нашёл пару мест в коде и поправил на что-то более унифицированное, выиграл немного.
Я назвал этот пост ваш PlayStation 5 умножает числа на 3 в два раза медленнее, чем ваш ноутбук для лайков и хайпа. Вопрос, который мне задали несколько раз:
$AUTHOR_NAME, как ты эту херню находишь?
Я скачал все таблицы инструкций и просто подиффал самую большую разницу. И просто сидел изучал, что из этого выходит. И да, что-то вышло. Есть ещё пару различий
* pclmuldqd -- Zen2-3 имеет latency 4, Intel 7. Это означает, что CRC чексуммы надо вычислять по-другому, Erasure кодеки работают медленнее, нашёл CRC вычисление, сравнил, действительно медленнее
* Ещё некоторый SIMD Memory load, но паттерн доступа к памяти проявился и тогда
OH MY GOD, ИСТОРИЯ ПРО КЕШЛИНИЮ MAKES SOME SENSE. Конечно, не сразу, конечно, чтобы её найти съесть много всего, внимательно смотреть. Главный вопрос, который я себе задаю -- а может ли это быть важно? И да, очень часто можно найти на скейле любую историю.
Но я понял, что тулингом/анализом надо заниматься плотно, может быть, даже 50%, ты открываешь интересные инсайты про те или иные истории.
Большой человек из Netflix (а сейчас из Intel) не зря занимался визуализацией через flame graphs, это тулинг, позволяющий что-то понять, мультипликативный фактор новых открытий и понимания. В Google мы семплируем весь прод каждый день, чтобы открыть понимание, происходит ли что-то (а что-то вообще происходит?).
В ближ время хочу заняться двумя вещами в тулинге: иллюстрация всех ассемблерных инструкций, а также хочу написать свой сжимающий кодек отсортированных с random access и поиском, работа Lemire про FastPFor мне кажется слишком простой, а я слишком много знаю про эту тему. Посмотрим, насколько я загорюсь. Сил не хватает, автор походу постарел, гореть чем-то почему-то стало тяжелее за последний год.
След статья про распределённые системы, обещаю :)
После релиза Arm машин я попал в дофаминовую яму из которой я стараюсь выходить всякой рутиной, где я помогал разным проектам (в том числе и всякими оптимизациями в Arm). За последнее время я решил перечитать много литературы, писал много документов и мало кода. It's fine, sometimes there are weeks when you understand completely nothing. Две истории, одна стратегическая, другая практическая, но они связаны.
Я понял, что когда делаю свою работу, я очень мало времени уделяю тулингу в перформансе. Скажем, я делаю процентов 20 анализа данных, что медленно, почему медленно, процентов 40 как это соптимизировать, остальные 40 на то, а как эту историю можно обобщить. Скажем, я недавно писал, как одна доп кешлиния в AMD не выучивается процессором, что она не так уж и важна, дальше вопрос, а в чем различия AMD и Intel, если уж посмотреть глобально. Бенчмарки делались на Intel долго, интересно, есть ли пробелы у AMD, можно ли унифицировать, чтобы всем было хорошо. Нашёл ещё одну историю, но она сильно другая:
На x86 умножение на 3 устроено через старую иструкцию LEA (Load Effective Address). Если коротко, эта иструкция умеет вычислять выражения REG1+X*REG2+Y, где X -- 0, 1, 2, 4, 8, а Y не очень большая константа. В итоге чтобы умножить на 3 надо взять REG1==REG2, X = 2. То есть это сумма X и (X << 1), вполне логично и legacy, которое мы за собой оставили. Инструкции mul/imul работают дольше.
Посмотрев на таблицу инструкций я нашёл, что AMD Zen 2 имеет latency 2, когда как абсолютно все Intel latency 1. Proof.
Нашёл пару мест в коде и поправил на что-то более унифицированное, выиграл немного.
Я назвал этот пост ваш PlayStation 5 умножает числа на 3 в два раза медленнее, чем ваш ноутбук для лайков и хайпа. Вопрос, который мне задали несколько раз:
$AUTHOR_NAME, как ты эту херню находишь?
Я скачал все таблицы инструкций и просто подиффал самую большую разницу. И просто сидел изучал, что из этого выходит. И да, что-то вышло. Есть ещё пару различий
* pclmuldqd -- Zen2-3 имеет latency 4, Intel 7. Это означает, что CRC чексуммы надо вычислять по-другому, Erasure кодеки работают медленнее, нашёл CRC вычисление, сравнил, действительно медленнее
* Ещё некоторый SIMD Memory load, но паттерн доступа к памяти проявился и тогда
OH MY GOD, ИСТОРИЯ ПРО КЕШЛИНИЮ MAKES SOME SENSE. Конечно, не сразу, конечно, чтобы её найти съесть много всего, внимательно смотреть. Главный вопрос, который я себе задаю -- а может ли это быть важно? И да, очень часто можно найти на скейле любую историю.
Но я понял, что тулингом/анализом надо заниматься плотно, может быть, даже 50%, ты открываешь интересные инсайты про те или иные истории.
Большой человек из Netflix (а сейчас из Intel) не зря занимался визуализацией через flame graphs, это тулинг, позволяющий что-то понять, мультипликативный фактор новых открытий и понимания. В Google мы семплируем весь прод каждый день, чтобы открыть понимание, происходит ли что-то (а что-то вообще происходит?).
В ближ время хочу заняться двумя вещами в тулинге: иллюстрация всех ассемблерных инструкций, а также хочу написать свой сжимающий кодек отсортированных с random access и поиском, работа Lemire про FastPFor мне кажется слишком простой, а я слишком много знаю про эту тему. Посмотрим, насколько я загорюсь. Сил не хватает, автор походу постарел, гореть чем-то почему-то стало тяжелее за последний год.
След статья про распределённые системы, обещаю :)