Определение максимального возможного выравнивания в C++

Если не считать некоторого типа maximally_aligned_t , который все компиляторы добросовестно обещали поддерживать для всех архитектур во всем мире, я не понимаю, как это можно решить во время компиляции. Как вы говорите, набор потенциальных типов неограничен. Неужели дополнительная косвенность указателя так важна?

Выделение выровненной памяти сложнее, чем кажется - см., Например, Реализация распределения выровненной памяти

К сожалению, обеспечение максимального выравнивания намного сложнее, чем должно быть, и нет никаких гарантированных решений AFAIK. Из блога GotW ( статья Fast Pimpl ):

union max_align {
  short       dummy0;
  long        dummy1;
  double      dummy2;
  long double dummy3;
  void*       dummy4;
  /*...and pointers to functions, pointers to
       member functions, pointers to member data,
       pointers to classes, eye of newt, ...*/
};

union {
  max_align m;
  char x_[sizeofx];
};

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

Это самый близкий из известных мне «хакеров».

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

Я использую его, в частности, для Pimpls . Однако просто иметь распределитель недостаточно; чтобы такой распределитель работал, мы должны предположить, что память для класса Foo выделяется в конструкторе, та же самая память также освобождается только в деструкторе, и что сам Foo создается в стеке. Чтобы сделать это безопасным, мне нужна была функция, чтобы увидеть, находится ли указатель this класса в локальном стеке, чтобы определить, можем ли мы использовать наш сверхбыстрый распределитель стека на основе кучи. Для этого нам пришлось исследовать решения для ОС: я использовал TIB и TEB для Win32 / Win64, а мои коллеги нашли решения для Linux и Mac OS X.

Результатом после недели исследования специфичных для ОС методов определения диапазона стека, требований к выравниванию и выполнения большого количества тестов и профилирования, был распределитель, который мог выделять память за 4 тактовых цикла в соответствии с нашими тестами тикового счетчика, как в отличие от примерно 400 циклов для malloc / operator new (в нашем тесте участвовали конфликты потоков, поэтому malloc, вероятно, будет немного быстрее, чем это в однопоточных случаях, возможно, на пару сотен циклов). Мы добавили стек кучи для каждого потока и обнаружили, какой поток использовался, что увеличило время примерно до 12 циклов, хотя клиент может отслеживать распределитель потоков, чтобы получить 4 цикла распределения. Он стер с карты горячие точки, основанные на выделении памяти.

Несмотря на то, что вам не нужно преодолевать все эти проблемы, написание быстрого распределителя может быть проще и более применимо (например, позволяя определять объем памяти для выделения / освобождения во время выполнения), чем что-то вроде max_align здесь. max_align достаточно прост в использовании, но если вам нужна скорость выделения памяти (и при условии, что вы уже профилировали свой код и нашли горячие точки в malloc / free / operator new / delete, где основные участники код, который вы контролируете), написание собственного распределителя действительно может иметь значение.