Тихий враг или молчаливый союзник: коротко о выравнивании в C++

• Введение
• Естественное выравнивание и паддинги
• Выравнивание в структурах
• Влияние порядка полей в структурах
• Битовые поля
• Директива '#pragma pack'
• __declspec(align), __attribute__((aligned(N))), alignas и alignof
• Статические анализаторы и выравнивание
• Заключение

Представьте, ваша программа — образец чистого кода, прошедший ревью и покрытый тестами. Казалось бы, всё идеально. Но производительность не такая, на какую рассчитывали. Вы проверили всё, что знали. А что, если проблема в том, о чём вы могли не знать? Все может упираться выравнивание данных в памяти. Для многих этот механизм так и остаётся загадкой. Предлагаю вам вместе попробовать разобраться в такой непростой теме.

Введение

Вы когда-нибудь задумывались, как на самом деле хранятся данные в памяти компьютера? Каждая переменная в программе занимает определённое место в памяти — последовательность байт по конкретному адресу, и к любому из этих байтов можно обратиться индивидуально. Но физический доступ к этим данным происходит не так просто, как может показаться.

Из-за разницы скорости между процессором и оперативной памятью данные сначала попадают в быстрый кэш. При этом кэш обменивается с RAM не теми отдельными байтами, которые нужны программе сиюминутно, а целыми выровненными блоками, в которые эти байты входят.

Давайте представим такую ситуацию: есть 4-байтное число типа int, которое расположено в памяти так, что его начало попадает на конец одного 4-байтного блока, а продолжение — на начало следующего. Чтобы прочитать это число, процессору придётся выполнить две операции чтения вместо одной, затем извлечь нужные части из разных блоков и объединить их. Проблема становится ещё серьёзнее, если эти блоки лежат в разных страницах виртуальной памяти. Это не только замедляет работу, но и усложняет обработку данных для процессора. Чтобы избежать таких сложностей, используется выравнивание.

Что же такое выравнивание? Это способ организации данных и доступа к ним в памяти в соответствии с заданными границами. Тип данных "выровнен", когда его адрес кратен степени двойки, как правило, равной размеру типа. Пока что запомним это ключевое определение.

Как же этот принцип применяется в коде? Будем последовательно погружаться в кроличью нору, изучая всё на примерах.

Естественное выравнивание и паддинги

Чтобы разобраться в таком непростом механизме, начнём с базовых принципов размещения примитивных типов данных в памяти. Для этого рассмотрим простой пример:

#include <iostream>
#include <format>

int main()
{
  char ch;
  char* pCh;
  int i;

  std::cout << std::format("Alignment of ch: {} byte(s)",
                           alignof(decltype(ch)))
            << std::endl
            << std::format("Alignment of pCh: {} byte(s)",
                           alignof(decltype(pCh)))
            << std::endl
            << std::format("Alignment of i: {} byte(s)",
                           alignof(decltype(i)))
            << std::endl;
}

Мы объявили три переменные разных типов. Давайте представим, что компилятор будет располагать их строго друг за другом в порядке их объявления (хотя, на самом деле, это не всегда так, и чуть далее я расскажу почему).

При размещении данных компилятор подчиняется строгим правилам выравнивания данных. Сам факт размещения объекта в памяти гарантируется языком на фундаментальном уровне (пункты 6.7.1.1 и 6.7.2.1 C++23). Конкретные значения выравнивания типов зависят от реализации (implementation-defined behavior), или, другими словами, зависят от конкретного компилятора. Чаще всего они определяются моделью данных.

Примечание: далее примеры будут рассматриваться в рамках модели LP64 (short — 2 байта, int — 4 байта, а long, long long и указатели — 8 байт).

Переменная ch типа char имеет выравнивание 1 байт и может находиться в любом месте адресного пространства. Указатель pCh с выравниванием 8 байт будет размещён только по адресу, кратному 8. Переменная in типа int с выравниванием 4 байта займёт позицию, кратную 4.

Но что это значит на практике? Давайте представим, как эти переменные могут быть расположены в памяти, если бы компилятор размещал их последовательно без оптимизации:

Компилятор разместил переменные практически подряд, однако между переменными ch и pCh добавилось 7 неиспользуемых байт. Кто нам помог? Компилятор. Он автоматически вставил неиспользуемые байты между переменными. Это пространство между данными называется байтами выравнивания (паддинг, padding). Его цель — выровнять каждый элемент по его размеру, предотвращая несоответствия, которые могут негативно повлиять на производительность. Поскольку заполнение этих байтов определяется реализацией, это создаёт ряд практических проблем. В частности, при использовании функций вроде memcmp для сравнения структур. Так оно будет анализировать все байты памяти объекта целиком, включая неинициализированный паддинг, что может привести к ложноотрицательному результату даже для структур с одинаковыми данными в полях.

Общий размер переменных составляет 1 + 8 + 4 = 13 байт, однако в памяти они занимают больше места из-за требований выравнивания. Стоит также отметить, что полагаться на конкретное расположение этих данных в стеке функции не стоит. Компилятор вправе применять различные оптимизации, которые не меняют наблюдаемого поведения программы, но при этом могут нарушить "очевидный" порядок. Например, он может как удалить неиспользуемые переменные, так и поместить используемые на регистры процессора.

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

Выравнивание в структурах

Как я и сказала ранее, механизм работы выравнивания может преподнести сюрпризы: один и тот же код, в зависимости от компилятора, может по-разному расположиться в памяти. Чтобы увидеть это на практике, мы будем изучать выводы программ на основе следующих окружений:

• ОС Windows, архитектура x86_64, компилятор MSVC;
• ОС Linux, архитектура x86_64, компилятор Clang.

Итак, перед вами небольшая структура. Каким будет её размер в каждом компиляторе?

struct Example
{
  short int sh;
  char* ptr;
  char symbol;
  long ln;
};

Если вы начали вычислять размер структуры Example, просто суммируя размеры полей, то поздравляю, вы ошиблись :)

В прошлой главе мы говорили о паддингах при работе с переменными на стеке. Собственно, для структур компилятор проделывает всё то же самое. Но в отличие от функций, для структур со стандартным размещением в памяти поля размещаются строго в порядке их объявления — именно в той последовательности, в которой они перечислены в коде.

Теперь попробуйте самостоятельно выстроить размещение данных структуры Example для Clang и MSVC.

Влияние порядка полей в структурах

Пытливый ум мог догадаться, что если переупорядочить поля в порядке убывания выравниваний, то мы сможем уменьшить влияние паддингов на финальный размер структуры.

Зная это, переделаем структуру (поменяем поля местами):

struct Example
{
  char* ptr;
  long ln;
  short int sh;
  char symbol;
};

И получим уже такие результаты:

В таком порядке компилятору не нужно добавлять лишние байты паддинга между полями, так как каждое следующее поле уже выровнено по адресу, кратному его выравниванию. Например, после 8-байтового указателя ptr идёт 4-байтовое поле ln, которое автоматически выравнивается по 4 байтам. Далее следуют 2-байтовое поле sh и 1-байтовое поле symbol. В результате общий размер структур будет на MSVC — 16 байт, на Clang — 24 байта.

Получается, стоит всегда располагать поля в таком порядке? Ответ зависит от того, как много порождается объектов таких структур:

• когда создаётся буквально несколько экземпляров структуры, то оптимизацией можно пренебречь, если она ломает некоторый логичный для разработчика порядок полей;
• если порядок создаваемых экземпляров высок (миллионы и более), то оптимизация может быть оправдана.

Также нужно помнить про ABI: если порядок полей важен для вашего приложения, то менять его вы не сможете, т. к. это приведёт к слому обратной совместимости.

Пустая структура

Итак, в С++ класс/структура считается пустой, если не содержит ни одного нестатического поля. У таких структур просто нет членов, которые могли бы занять память. Однако мы знаем, что каждый объект должен иметь свой адрес в памяти, поэтому даже под пустые структуры компилятор обязан выделить 1 байт.

Когда пустая структура становится членом другой структуры, она также занимает как минимум 1 байт. Однако из-за требований выравнивания компилятор часто вынужден добавлять дополнительные байты заполнения. К чему это приводит? К тому, что пустая структура, которая технически могла бы не занимать места, фактически увеличивает размер структуры-владельца значительно больше, чем на свой собственный байт.

Для решения этой проблемы в C++20 был введён атрибут [[no_unique_address]]. Он говорит компилятору, что поле не обязательно должно иметь уникальный адрес. Если поле является пустым, компилятор может оптимизировать его размещение и не выделять для него отдельную память.

При применении этого атрибута к пустому полю мы даём разрешение компилятору разместить его в тех же байтах, которые обычно используются для заполнения выравнивания других полей структуры. Рассмотрим пример:

struct Empty {};

struct Normal
{
  Empty e;
  int x;
};

struct Optimized
{
  [[no_unique_address]] Empty e;
  int x;
};

Интересный факт: в компиляторе MSVC эта оптимизация по умолчанию не сработает, и размер структуры будет 8 байт. Microsoft пока решила не ломать свой ABI, однако при большом желании оптимизацию можно осуществить посредством атрибута [[msvc::no_unique_address]].

Битовые поля

Битовые поля позволяют упаковывать несколько полей интегрального типа в один или несколько байтов, экономя память. Например, так можно оптимизировать расположение совокупности булевых флагов, когда их количество в структуре начинает расти (более 8 штук).

В качестве примера рассмотрим такую структуру:

// since C++20
struct Example
{
  unsigned char dummy1;
  unsigned char flag1 : 1;
  unsigned char flag2 : 1;
  unsigned char flag3 : 1;
  unsigned char flag4 : 1;
  unsigned char dummy2;
};

Поля dummy1 и dummy2 нужны в служебных целях: для битовых полей невозможно применить операцию взятия адреса.

На первый взгляд, все битовые поля должны занять всего 4 бита. Однако же размер структуры без учёта наших служебных полей составляет 1 байт. Почему? Ответ очень прост: минимальной единицей хранения (storage unit) является байт, в котором хранится N бит информации (определяется имплементацией посредством макроса CHAR_BIT). На используемых для экспериментов платформах 1 байт хранит 8 бит. Мы воспользовались только четырьмя битами, поэтому компилятор также вставит ещё 4 бита паддинга для полного заполнения единицы хранения.

Строго говоря, стандарт языка полностью оставляет за реализацией (ABI конкретной платформы и компилятором) способ физического расположения битовых полей. Компилятор может как упаковывать ваши биты в одну единицу хранения, так и порождать для каждого битового поля свою собственную единицу хранения. Также компилятор сам выбирает, с какого конца единицы хранения (little/big endian) начинается размещение.

Однако в ряде компиляторов прослеживается некоторая схожесть: если все битовые поля в структуре объявлены с одним и тем же нижележащим типом (не учитывая знаковость), то компиляторы чаще всего упаковывают их последовательно, без лишних паддингов, в пределах единиц хранения этого типа.

При этом есть и некоторые отличия в реализациях компиляторов:

• при изменении нижележащего типа битового поля компилятор может как неявно завершить предыдущую единицу хранения (MSVC), так и продолжить наполнение дальше (GCC, Clang);
• при декларации битового поля, размер которого превышает ёмкость его нижележащего типа, все дополнительные биты считаются битами паддинга. Clang и GCC соблюдают это поведение, но выдают предупреждение. MSVC же в такой ситуации считает код ошибочным и отказывается компилировать его.

Директива '#pragma pack'

Иногда бывают случаи, когда нам надо самостоятельно контролировать выравнивания. Для этого существует директива #pragma pack, которая говорит компилятору, сколько байт использовать для выравнивания полей вместо стандартного. Рассмотрим пример:

struct NormalStruct
{
  char a;
  int b;
  double c;
};

#pragma pack(push, 1)
struct PackedStruct
{
  char a;
  int b;
  double c;
};
#pragma pack(pop)

Директива #pragma pack(1) кардинально меняет правила игры, заставляя компилятор упаковать данные максимально плотно. В структуре PackedStruct поля располагаются строго последовательно без какого-либо выравнивания. Такой подход экономит память (ровно 13 байт), но, как я и писала ранее, имеет серьёзную цену — невыровненный доступ к данным:

• Если архитектура процессора позволяет производить доступ к таким данным, то может происходить существенное замедление операций чтения и записи. Пример такой архитектуры — x86_64.
• Процессор может сделать аппаратное прерывание при доступе к невыровненным данным. Пример такой архитектуры — ARM.

__declspec(align), __attribute__((aligned(N))), alignas и alignof

Как мы уже знаем, порядок расположения достаточно важен в структурах/классах. Но если нам нужно самим задать выравнивание? Например, иногда такое требуется при работе с SIMD: данные должны быть выровнены по границе 32 байт.

Для этого компиляторы предоставляют специальные атрибуты и/или спецификаторы. Исторически начнём с __declspec(align(N)) в MSVC и __attribute__((aligned(N))) в Clang и GCC — это компиляторо-специфичные расширения, которые позволяют явно управлять требованиями к выравниванию данных в памяти:

// MSVC
__declspec(align(32)) struct SIMD_Data_MSVC
{
  double d1;
  double d2;
  double d3;
  double d4;
};

// Clang and GCC
struct SIMD_DATA_Clang_GCC
{
  double d1;
  double d2;
  double d3;
  double d4;
} __attribute__((aligned(32)));

Синтаксически эти атрибуты отличаются: в MSVC спецификатор __declspec(align(N)) ставится перед объявлением структуры или переменной, в Clang и GCC используется атрибут __attribute__((aligned(N))), который, как правило, следует после имени структуры или типа в объявлении. Атрибуты могут использоваться как для упаковки, так и для задания более строгих требований к выравниванию.

Разница в синтаксисе — частая причина ошибок при портировании кода между платформами. Эта проблема была решена в стандартах C11 и C++11. Появились новые средства для работы с выравниванием — оператор alignof и спецификатор alignas:

• оператор alignof возвращает выравнивание переданного типа во время компиляции. Например, alignof(char) всегда равен 1, поскольку байт можно разместить по любому адресу;
• спецификатор alignasпозволяет явно задавать требование к выравниванию для переменных, полей структур или самих типов. Может принимать как целочисленное значение, так и другой тип. Например, alignas(32) double value; гарантирует, что переменная value будет размещена по адресу, кратному 32 байтам. Важное отличие от компиляторо-специфичных атрибутов — оператор alignas не позволяет делать упаковку. При попытке уменьшить необходимое выравнивание будет выдана ошибка этапа компиляции.

Статические анализаторы и выравнивание

Зачастую самостоятельно контролировать все тонкости выравнивания достаточно сложно. Тут и приходит на помощь статический анализ, который может отлавливать различные аспекты при работе с выравниванием. Например, вот что может подсвечивать PVS-Studio:

• V802 из группы оптимизаций фокусируется на поиске структур, где размер можно уменьшить, просто изменив порядок объявления полей для более плотной упаковки данных;
• V1032 сигнализирует о ситуациях, когда приведения указателя может привести к обращению по невыровненному адресу;
• V1103 акцентирует внимание на ошибках побайтового сравнения структур, в которых присутствуют случайные значения в паддингах;
• V2666 из группы MISRA отслеживает согласованность спецификаторов выравнивания. Если вы где-то указали alignas для объекта, то все другие повторные объявления должны использовать такое же выравнивание.

Рассмотрим пару ошибок, связанных с выравниванием, которые мы нашли в реальных проектах.

Проект FreeCAD

template <int N>
void TRational<N>::ConvertTo (double& rdValue) const
{
  assert(m_kDenom != 0);
  if (m_kNumer == 0)
  {
    rdValue = 0.0;
    return;
  }

  unsigned int auiResult[2];
  ....
  rdValue = *(double*)auiResult;
  ....
}

Здесь строка rdValue = *(double*)auiResult; — это то самое коварное место. Тут автор пытается собрать значение типа double путём чтения двух последовательно расположенных unsigned int. Просто так такое чтение невозможно, поэтому автор прибегает к преобразованию указателей.

Вариант нерабочий и опасный. Проблема в нарушении требований к выравниванию. Адрес auiResult выровнен для типа unsigned int (4 байта), тогда как тип double (8 байт) требует более строгого выравнивания. Поведение при чтении переменной по адресу, не кратному его требованию типа, не определено.

И срабатывание PVS-Studio: V1032. The pointer 'auiResult' is cast to a more strictly aligned pointer type. Wm4TRational.inl

Проект TDengine

typedef struct STreeNode {
  int32_t index;
  void   *pData;  // TODO remove it?
} STreeNode;

int32_t tMergeTreeAdjust(SMultiwayMergeTreeInfo* pTree, int32_t idx) {
  ....
  STreeNode kLeaf = pTree->pNode[idx];
  ....
  if (memcmp(&kLeaf, &pTree->pNode[1], sizeof(kLeaf)) != 0) {
  ....
}

Здесь ошибка кроется в сравнении объектов структуры STreeNode. Поскольку структура содержит поля разного размера (int32_t и указатель void*), компилятор для обеспечения выравнивания указателя добавляет после index 4 байта паддинга. Для сравнения объектов используется функция memcmp, которая сравнивает всё байтовое представление, включая паддинг. А как мы помним, поведение того, как именно заполняются байты паддинга, зависит от реализации. Это может привести к неожиданным результатам. Например, даже если поля index и pData совпадают, объекты могут быть признаны неравными из-за случайных данных в пустых байтах, которые компилятор добавил для выравнивания.

И срабатывание PVS-Studio: V1103 The values of padding bytes are unspecified. Comparing objects with padding using 'memcmp' may lead to unexpected result. tlosertree.c 127

Заключение

Итак, тайна раскрыта. Выравнивание данных — это не враг, а союзник, чьи правила, будучи понятыми, позволяют писать по-настоящему быстрый и стабильный код. Вооружившись знаниями из этой статьи, вы с лёгкостью превратите загадочные падения и тормоза в решаемые задачи. Ваш код отныне готов ко встрече с любым "железом". Однако во всей этой большой статье несколько тем я заведомо опустила: наследование, POD-структуры, множественное наследование, виртуальные таблицы, виртуальные базовые классы, RTTI и т. д. Продолжение следует... :)

Чтобы на практике убедиться, что все тонкости выравнивания в вашем проекте учтены, вы можете воспользоваться статическим анализатором PVS-Studio. Он поможет проверить код на наличие неочевидных ошибок, связанных с организацией памяти, и станет вашим помощником в написании переносимого и надёжного кода.