Comments 9
Хорошо бы добавить в тест производительности вариант с #pragma pack(1)
Да, было бы интересно. Подозреваю, что результат будет сильно варьироваться для разных платформ. И скорее всего будет проигрывать подходу с SoA (Structure of Arrays)
Спасибо! Не слишком пока опытен в тестах, в следующий раз обязательно учту
pack(1) падает на ARM, если при компиляции не разрешить чтение невыровненых данных, что замедлит весь код
Добавлю, что при невыровненном чтении современные процессоры выбрасывают исключение 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 находится на уровне погрешности.
Принципы DOD в C++: Часть 1. Оптимизация структур