Действительно ли выравнивание имеет значение для производительности в C++11?
В книге Страуструпа есть совет упорядочивать элементы в структуре, начиная с наибольшего и заканчивая наименьшим. Но мне интересно, проводил ли кто-нибудь измерения, чтобы увидеть, имеет ли это какое-то значение, и стоит ли об этом думать при написании кода.
Выравнивание имеет значение не только для производительности, но и для корректности. В некоторых архитектурах произойдет сбой из-за ловушки процессора, если данные не выровнены правильно или доступ к неправильному адресу памяти. В других случаях доступ к невыровненным переменным разбивается на множественные обращения и битовые сдвиги (часто внутри оборудования, иногда с помощью обработчика ловушек ОС), теряя атомарность.
Рекомендуется сортировать элементы в порядке убывания размера для оптимальной упаковки/минимального расхода пространства на отступы, а не для выравнивания или скорости. Элементы будут правильно выровнены независимо от того, в каком порядке вы их перечисляете, если вы не запросите несовместимый макет, используя специализированные прагмы (например, непереносимые #pragma pack) или ключевые слова. Хотя общий размер структуры зависит от заполнения, а также влияет на скорость, часто существует другой оптимальный порядок.
Для достижения наилучшей производительности вы должны попытаться поместить элементы, которые используются вместе, в одну строку кэша, а элементы, к которым обращаются разные потоки, — в разные строки кэша. Иногда это означает много заполнения, чтобы получить одну общую переменную между потоками в своей собственной строке кэша. Но это лучше, чем снижение производительности из-за ложного обмена.
char[53] должен идти последним)
- person MSalters; 28.12.2013
char[53] одним объектом размером 53 или 53 объектами размером 1 каждый. Но да, заполнение действительно сводится к минимуму за счет группировки объектов с одинаковым выравниванием вместе. И это все еще не самое лучшее для производительности.
- person Ben Voigt; 30.12.2013
sizeof каждый тип члена, который вы используете, и обновлять его на основе этого. Что еще более важно, в некоторых случаях это просто невозможно, поскольку члены могут зависеть от того, что другие члены будут инициализированы первыми, независимо от того, какие у них sizeof. Ничто из этого не приводит к красивому коду или опыту написания кода.
- person underscore_d; 13.08.2016
Просто чтобы добавить к отличному ответу Бена:
Определение элементов структуры в том же порядке, в котором они впоследствии будут доступны в вашем приложении, уменьшит промахи в кэше и, возможно, повысит производительность. Это будет работать при условии, что вся структура не помещается в кэш L1.
С другой стороны, упорядочивание членов от большего к меньшему может уменьшить общее использование памяти, что может быть важно при хранении массива небольших структур.
Предположим, что для архитектуры (я их не так хорошо знаю, думаю, что это было бы так для дефолтных настроек 32bit gcc, кто-то меня поправит в комментариях) такая структура:
struct MemoryUnused {
uint8_t val0;
uint16_t val1;
uint8_t val2;
uint16_t val3;
uint8_t val4;
uint32_t val5;
uint8_t val6;
}
занимает 20 байт в памяти, а это:
struct MemoryNotLost {
uint32_t val5;
uint16_t val1;
uint16_t val3;
uint8_t val0;
uint8_t val2;
uint8_t val4;
uint8_t val6;
}
Потребуется 12. Это 8 байтов, потерянных из-за заполнения, и это на 67% больше размера структуры меньшего размера. При большом массиве таких структур выигрыш будет значительным и, просто из-за объема используемой памяти, уменьшит количество промахов кеша.
struct всегда доступны в одном и том же порядке. Во-вторых, struct, который не помещается в кэш 1-го уровня, является настоящим монстром и никогда не должен производиться. В-третьих, у нас часто бывает много мелких объектов в больших массивах, и здесь для производительности имеет значение только одно: общий размер объектов. И в-четвертых, у нас в любом случае не должно быть несвязанных частей внутри одной структуры, что противоречит духу объектной ориентации.
- person cmaster - reinstate monica; 02.01.2014
int32_t (чье имя странным образом изменилось с val5 на val0) и элемент int8_t val6, то последний вариант размещения памяти вызовет в два раза больше промахов кеша, чем первый (дополненный ) один. Вероятно, существует упакованный макет, который не страдает от этой проблемы, но простая сортировка по размеру не такова.
- person Ben Voigt; 02.01.2014
val5 и val6 в памяти, поэтому загрузка одной строки кеша не будет содержать оба (ну, для достаточно большой строки кеша это может быть. Представьте, что структура больше, поэтому она не 'т). Если бы существовал цикл, который обращался только к этим двум элементам, то упакованная компоновка фактически работала бы медленнее, поскольку требовалось бы в два раза больше обращений к ОЗУ.
- person Ben Voigt; 02.01.2014
