Pull to refresh

Comments 9

Хорошо бы добавить в тест производительности вариант с #pragma pack(1)

Да, было бы интересно. Подозреваю, что результат будет сильно варьироваться для разных платформ. И скорее всего будет проигрывать подходу с SoA (Structure of Arrays)

Спасибо! Не слишком пока опытен в тестах, в следующий раз обязательно учту

pack(1) падает на ARM, если при компиляции не разрешить чтение невыровненых данных, что замедлит весь код

Может не стоит обобщать? ARM v8 поддерживает невыравненный доступ к данным.

AArch64 provides support for 16, 32, 64 and 128-bit data unaligned accesses.

Добавлю, что при невыровненном чтении современные процессоры выбрасывают исключение alignment fault. В x86 для совместимости с 8088 есть аппаратный обработчик этого исключения, но его услуги стоят 3-5 тактов, и его можно отключить флагом AF (потому что как правило это указывает на мусор в памяти).

В arm этот обработчик является опциональным: в микроконтроллерах его обычно нет. Кроме того, когда я последний раз смотрел спеку, он не обрабатывал случай, когда данные пересекают границу страницы dram (8k).

В risc-v и sparc его в принципе нет, процессор выбросит af и отправит чинить компилятор

До 262144 итераций разница во времени минимальна, но на 1000000 итераций она уже составляет 38%!

А то что в таблице результатов все что меньше 1000000 выигрывает BadStruct как-то объясняется или мы просто считаем, что это равный результат, отличающийся не более чем на погрешность измерений?

В тексте написано объяснение этому явлению:

Массив плохих структур из 10000 и 32768 элементов с размерами спокойно влезает в кэш, 312.5Кб и 1024Кб соответственно.

То есть пока массивы структур влезают в кэш, разница в производительности между BadStruct и GoodStruct находится на уровне погрешности.

не сказано, что это погрешность. По графику не видно, а в таблице видно, что BadStruct стабильно выигрывает до 1000000.

Sign up to leave a comment.

Articles