Недавно мне сообщили о потенциальных проблемах выравнивания памяти для векторизуемых собственных объектов фиксированного размера.
Правильный код, указанный в документе:
class Foo
{
...
Eigen::Vector2d v;
...
public:
EIGEN_MAKE_ALIGNED_OPERATOR_NEW
};
...
Foo *foo = new Foo;
< /code>
Я хотел бы знать, в порядке ли этот код или нет? < /p>
class Foo2
{
...
Foo foo;
...
};
...
Foo2 *foo = new Foo2; //?
< /code>
или должно быть добавлено eigen_make_aligned_operator_new < /code> снова добавить в класс foo2 < /code>? Пользователи библиотеки также должны были бы добавить eigen_make_aligned_operator_new к классам, содержащим векторизованные классы картографа. Это звучит как кошмар обслуживания. Я думаю, что вопрос более общий и будет каким -то образом связан с тем, как работает новый оператор в C ++. Например, является ли перегруженным новым оператором в Foo
новым оператором по умолчанию в Foo2 ? Как насчет наследства? If Foo2 inherits from Foo, should we put also EIGEN_MAKE_ALIGNED_OPERATOR_NEW in Foo2?
Since I was only aware of this topic recently, I did many research and found the following:
default alignment on x86-64 -это 16 байтов, поэтому нельзя иметь eigen_make_aligned_operator_new (если включен только SSE) Eigen_make_aligned_operator_new теперь необходимо
А как насчет другой архитектуры? Например, для ARM, любая проблема, если мы не объявляем eigen_make_aligned_operator_new и Neon включено? Eigen :: Dontalign> вместо изометрии
Все еще нужно подумать о том, как иметь возможность легко использовать тип собственного значения (например, isometry3d ) в коде без проблемы выравнивания. Так что добавьте новый тип myisometry3d , который наследует от Eigen :: Transform Например? /> И не беспокоиться о проблеме выравнивания при использовании isometry3d в классе или при использовании std :: vector
что -то, что можно сказать, что всегда использует безотверженную загрузку/хранилище (например, _loadu _ /
для встроенных функций x86-64, а как насчет другой архитектуры, существует ли эквивалент?) для всех типов Eigen фиксированного размера?
иначе просто отключите векторизацию для типа Eigen фиксированного размера, поскольку я считаю, что штраф должен быть (почти) нулевым между использованием векторизованных инструкций и просто кода C++ для этих типов
поэтому я думаю, что решение состоит в том, чтобы использовать #define EIGEN_UNALIGNED_VECTORIZE 0, это правильно? Значит, мне нужно помещать этот #define везде перед включением Eigen/Dense?
Я не хочу везде заменять что-то вроде Matrix или новый класс
Наконец, глядя на страницу векторизуемых собственных объектов фиксированного размера, я думаю, что некоторые типы отсутствуют. Для типов, которые я использую:
Недавно мне сообщили о потенциальных проблемах выравнивания памяти для векторизуемых собственных объектов фиксированного размера. Правильный код, указанный в документе: [code]class Foo { ... Eigen::Vector2d v; ... public: EIGEN_MAKE_ALIGNED_OPERATOR_NEW };
...
Foo *foo = new Foo; < /code> Я хотел бы знать, в порядке ли этот код или нет? < /p> class Foo2 { ... Foo foo; ... };
...
Foo2 *foo = new Foo2; //? < /code> или должно быть добавлено eigen_make_aligned_operator_new < /code> снова добавить в класс foo2 < /code>? Пользователи библиотеки также должны были бы добавить eigen_make_aligned_operator_new к классам, содержащим векторизованные классы картографа. Это звучит как кошмар обслуживания. Я думаю, что вопрос более общий и будет каким -то образом связан с тем, как работает новый оператор в C ++. Например, является ли перегруженным новым оператором в Foo [/code] новым оператором по умолчанию в Foo2 ? Как насчет наследства? If Foo2 inherits from Foo, should we put also EIGEN_MAKE_ALIGNED_OPERATOR_NEW in Foo2?
Since I was only aware of this topic recently, I did many research and found the following: [list] [*]default alignment on x86-64 -это 16 байтов, поэтому нельзя иметь eigen_make_aligned_operator_new (если включен только SSE) Eigen_make_aligned_operator_new теперь необходимо [*] А как насчет другой архитектуры? Например, для ARM, любая проблема, если мы не объявляем eigen_make_aligned_operator_new и Neon включено? Eigen :: Dontalign> вместо изометрии [*] Все еще нужно подумать о том, как иметь возможность легко использовать тип собственного значения (например, isometry3d ) в коде без проблемы выравнивания. Так что добавьте новый тип myisometry3d , который наследует от Eigen :: Transform Например? /> И не беспокоиться о проблеме выравнивания при использовании isometry3d в классе или при использовании std :: vector [*] что -то, что можно сказать, что всегда использует безотверженную загрузку/хранилище (например, _loadu _ /[code]_storeu_[/code] для встроенных функций x86-64, а как насчет другой архитектуры, существует ли эквивалент?) для всех типов Eigen фиксированного размера? [*]иначе просто отключите векторизацию для типа Eigen фиксированного размера, поскольку я считаю, что штраф должен быть (почти) нулевым между использованием векторизованных инструкций и просто кода C++ для этих типов [*]поэтому я думаю, что решение состоит в том, чтобы использовать #define EIGEN_UNALIGNED_VECTORIZE 0, это правильно? Значит, мне нужно помещать этот #define везде перед включением Eigen/Dense? [*]Я не хочу везде заменять что-то вроде Matrix или новый класс [/list] Наконец, глядя на страницу векторизуемых собственных объектов фиксированного размера, я думаю, что некоторые типы отсутствуют. Для типов, которые я использую: [list] [*][code]Eigen::Isometry3d[/code], Eigen::Isometry3f? [*][code]Eigen::AngleAxisd[/code], собственное :: angleaxisf ? [/list]