Два вопроса здесь:
- Оптимизация и сохранение определенных полей вместе.
- Как это сделать на самом деле.
Причина, по которой это может помочь, заключается в том, что память загружается в кэш ЦП частями, называемыми «строками кеша». Это занимает время, и, вообще говоря, чем больше строк кэша загружено для вашего объекта, тем дольше это занимает. Кроме того, чем больше других вещей выбрасывается из кэша для освобождения места, тем самым непредсказуемым образом замедляется другой код.
Размер строки кэша зависит от процессора. Если он велик по сравнению с размером ваших объектов, то очень немногие объекты пересекают границу строки кэша, поэтому вся оптимизация не имеет значения. В противном случае, вы можете избежать необходимости иметь только часть вашего объекта в кеше, а остальное в основной памяти (или, возможно, в кеше L2). Хорошо, если ваши самые распространенные операции (те, которые обращаются к часто используемым полям) используют как можно меньше кеша для объекта, поэтому группировка этих полей вместе дает вам больше шансов на это.
Общий принцип называется "локальность ссылок". Чем ближе друг к другу различные адреса памяти, к которым обращается ваша программа, тем больше у вас шансов получить хорошее поведение в кеше. Зачастую сложно предсказать производительность заранее: разные модели процессоров одной и той же архитектуры могут вести себя по-разному, многопоточность означает, что вы часто не знаете, что будет в кеше и т. Д. Но можно говорить о том, что скорее всего, случится, большую часть времени. Если вы хотите знать что-либо, вам обычно нужно это измерить.
Обратите внимание, что здесь есть некоторые ошибки. Если вы используете основанные на CPU атомарные операции (которые обычно используются атомарные типы в C ++ 0x), то вы можете обнаружить, что CPU блокирует всю строку кэша, чтобы заблокировать поле. Затем, если у вас есть несколько атомных полей близко друг к другу, с разными потоками, работающими на разных ядрах и работающими в разных полях одновременно, вы обнаружите, что все эти атомарные операции сериализуются, потому что все они блокируют одну и ту же область памяти, даже если работаем на разных полях. Если бы они работали на разных строках кеша, они работали бы параллельно и работали быстрее. Фактически, как указывает Глен (через Херба Саттера) в своем ответе, на архитектуре связного кэша это происходит даже без атомарных операций и может полностью испортить ваш день. Таким образом, местность ссылок не обязательно должна быть обязательно , когда задействованы несколько ядер, даже если они совместно используют кеш. Вы можете ожидать, что это происходит на том основании, что ошибки в кеше обычно являются источником потери скорости, но в вашем конкретном случае это будет ужасно неправильно.
Теперь, если не считать различия между обычно используемыми и менее используемыми полями, чем меньше объект, тем меньше памяти (и, следовательно, меньше кеша) он занимает. Это очень хорошая новость, по крайней мере, там, где у вас нет серьезных разногласий. Размер объекта зависит от полей в нем и от любого заполнения, которое должно быть вставлено между полями, чтобы гарантировать их правильное выравнивание для архитектуры. C ++ (иногда) накладывает ограничения на порядок, в котором поля должны появляться в объекте, в зависимости от порядка их объявления. Это облегчает программирование на низком уровне. Итак, если ваш объект содержит:
- int (4 байта, 4 с выравниванием)
- с последующим символом (1 байт, любое выравнивание)
- , за которым следует int (4 байта, 4 с выравниванием)
- с последующим символом (1 байт, любое выравнивание)
тогда, скорее всего, это займет 16 байт в памяти. Кстати, размер и выравнивание int не одинаковы на всех платформах, но 4 очень распространено, и это только пример.
В этом случае компилятор вставит 3 байта заполнения перед вторым int, чтобы правильно выровнять его, и 3 байта заполнения в конце. Размер объекта должен быть кратным его выравниванию, чтобы объекты одного типа могли быть размещены рядом в памяти. Это все, что массив находится в C / C ++, смежные объекты в памяти. Если бы структура была int, int, char, char, то один и тот же объект мог бы быть 12 байтами, потому что у char нет требования выравнивания.
Я сказал, что то, является ли int 4-выровненным, зависит от платформы: в ARM это обязательно должно быть, так как доступ без выравнивания вызывает аппаратное исключение. На x86 вы можете получить доступ к целым числам без выравнивания, но обычно он медленнее, а IIRC не атомарен. Так что компиляторы обычно (всегда?) 4-строчные целые на x86.
Основное правило при написании кода, если вы заботитесь об упаковке, - смотреть на требование выравнивания каждого члена структуры. Затем сначала упорядочите поля с наиболее выровненными типами, затем - наименьшими и т. Д. - до элементов без требования для выравнивания. Например, если я пытаюсь написать переносимый код, я мог бы придумать это:
struct some_stuff {
double d; // I expect double is 64bit IEEE, it might not be
uint64_t l; // 8 bytes, could be 8-aligned or 4-aligned, I don't know
uint32_t i; // 4 bytes, usually 4-aligned
int32_t j; // same
short s; // usually 2 bytes, could be 2-aligned or unaligned, I don't know
char c[4]; // array 4 chars, 4 bytes big but "never" needs 4-alignment
char d; // 1 byte, any alignment
};
Если вы не знаете выравнивания поля или пишете переносимый код, но хотите сделать все возможное, не прибегая к серьезным уловкам, тогда вы предполагаете, что требование выравнивания является самым большим требованием любого фундаментального типа в структура, и что требование выравнивания основных типов является их размер. Итак, если ваша структура содержит uint64_t или long long, то лучше всего предположить, что она выровнена по 8. Иногда вы ошибаетесь, но часто будете правы.
Обратите внимание, что программисты игр, такие как ваш блогер, часто знают все о своих процессорах и оборудовании, и поэтому им не приходится догадываться. Они знают размер строки кэша, они знают размер и выравнивание каждого типа, и они знают правила структурирования структуры, используемые их компилятором (для типов POD и не POD). Если они поддерживают несколько платформ, то они могут в особых случаях для каждой из них при необходимости. Они также проводят много времени, размышляя о том, какие объекты в их игре выиграют от повышения производительности, и используя профилировщики, чтобы выяснить, где на самом деле существуют узкие места. Но даже в этом случае неплохо иметь несколько практических правил, которые вы применяете независимо от того, нужен ли объект этому или нет. Пока это не сделает код неясным, «положите часто используемые поля в начало объекта» и «требование сортировки по выравниванию» - это два хороших правила.