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

В C++0x параметр шаблона Align для std::aligned_storage<Len, Align> имеет аргумент по умолчанию «выравнивание по умолчанию», который определяется как (N3225 §20.7.6.6, таблица 56):

Значение default-alignment должно быть самым строгим требованием выравнивания для любого типа объекта C++, размер которого не превышает Len.

Неясно, будут ли типы SSE считаться «типами объектов C++».

Аргумент по умолчанию не был частью TR1 aligned_storage; он был добавлен для C++0x.

В C++11 std::max_align_t, определенный в заголовке cstddef, представляет собой тип POD, требования к выравниванию которого не менее строгие (такие же большие), как и у любого скалярного типа.

Используя новый оператор alignof, это будет так же просто, как alignof(std::max_align_t)

К сожалению, обеспечение максимального выравнивания намного сложнее, чем должно быть, и нет никаких гарантированных решений, насколько я знаю. Из блога 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 с основными вкладчиками, находящимися в коде, который вы контролируете) , написание собственного распределителя действительно может иметь значение.

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

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

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

enum {
            max_alignment = boost::mpl::deref<
                boost::mpl::max_element<
                        boost::mpl::vector<
                            boost::mpl::int_<boost::alignment_of<signed char>::value>::type,
                            boost::mpl::int_<boost::alignment_of<short int>::value>::type,
                            boost::mpl::int_<boost::alignment_of<int>::value>::type,                                boost::mpl::int_<boost::alignment_of<long int>::value>::type,
                            boost::mpl::int_<boost::alignment_of<float>::value>::type,
                            boost::mpl::int_<boost::alignment_of<double>::value>::type,
                            boost::mpl::int_<boost::alignment_of<long double>::value>::type,
                            boost::mpl::int_<boost::alignment_of<void*>::value>::type
                        >::type
                    >::type
                >::type::value
            };
        }