Из всего что я нашёл - это "багу" в процессорах Intel, когда иструкция jmp попадает на границу двух "линий кеша". В этом случае она начинает тормозить.
Но для этого сделали "заплатку" - опция для компилятора, которая делает выравнивание всех jmp, что бы они не тормозили. Но видимо это не всегда помогает, что то там ещё не так может быть.

вспоминаю молодость и плюсы...
выравнивание переменных, использовать только 32 битные (доступ к восьмибитным сильно медленее), данные выравнивать по размеру кешлинии, особенно если разные треды активно используются. Еще какие то были приколы...

ну мне кажется, это слишком специфичная вещь

тюнить код настолько имеет смысл, если есть какой-то блок который очень CPU-bound и занимает много времени

пройтись по картинке например

ну кирилл этим и занимается...

Ладно бы оно всё стабильно было. Может даже тормозило, но стабильно и воспроизводимо.
А у меня получается так, что в прошлом релизе моей библиотеки, конкурент делал работу за 370мс. Я добавил в свою библиотеку новый функционал и конкурент стал делать ту же работу за 480мс.
Единственное что помогает - убрать из бенчмарка мою библиотеку и тестировать всё по отдельности.

https://lemire.me/blog/2012/05/31/data-alignment-for-speed-myth-or-reality/

> выравнивание переменных

оно кстати сейчас менее актуально уже

Да, я пишу ресайзер картинок 😊

брр

Жуть какая

мне лень проверять, но он сравнивает структуры int , long, и long long. В зависимости от компилятора и операционки они имеют разный размер.
Во вторых есть подозрение, что компилятор может сильно оптимизировать код и вообще не использовать память, а всё сделать в регистрах.  В третьих у него последовательный доступ к массиву в памяти, в этом случае очень эффективно работает предзагрузка памяти.
Нужно проверять рандомный доступ.
В общем у мну большие сомнения в правильности его теста. Но я не исключаю что не  которые производители, для некорых процессоров сделали оптимизацию. Но возникает вопрос зачем, если можно легко сказать компилятору чтобы выравнивал 4/8 байтные данные.

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

а в чем проблема?
Выделаешь памяти n+31.
Проверяешь адресс и добавляешь нужное смещение (скорее всего почти всегда будет 0) и дальше SSE и другие многобайтные инструкции

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

когда то я пытался демосценой заниматься. Мы тогда всегда 4байта использовали. Просто один байт всегда ноль. Оперативки немного лишнего используется, зато всё гораздо быстрее было

так ты же не построчно изображение обрабатываешь, а всё целиком

Ну вот Pillow так и делает - там RGB картинки всё равно занимают 4 байта. А вот в Rust есть библиотека Image, там пиксели в RGB картинках - это массивы из 3-ёх байт. Пришлось в своей либе делать поддержку такого формата.

Если всякие SIMD использую, то сразу обрабатываю по 4 или 2 строки на первом проходе (сжатие по горизонтали). А на втором проходе (сжатие по вертикали) приходится скакать именно по строкам, даже если не использую SIMD.

Хотя тут стоит сказать, что вероятно в статье есть доля правды. У меня примерно одинаковая скорость ресайза 4-ёх байтовой картинки и точно такой же 3-ёх байтовой (без использования SIMD). Около 10% разница (106мс и 117мс). Вроде как в статье у него такая же была.

Ща будет мясо

209? Негуманно