Является ли XMMATRIX эффективным для 2D-преобразований, или я должен сделать собственный набор матриц 3x3?

Question

Я создаю высокопроизводительный механизм компоновки пользовательского интерфейса поверх Direct3D 11. Приложение разрабатывается с использованием Visual Studio 2013 с таргетингом на x64 и предназначено для Windows 7 (с обновлением платформы) и выше.

Мне нужно сделать преобразования матрицы на 2D-элементах в визуальном дереве, и мне интересно, использует ли DirextXMath встроенный (оптимизированный по SIMD) XMMATRIX и связанные с ним функции, эффективные для использования в 2D (поскольку для этого требуется только матрица 3x3 в то время как XMMATRIX и др. - 4x4), или же я должен катить собственный матричный класс/функции (возможно, без какого-либо кода, специфичного для SIMD).

Мне кажется, что матрица размером 4 × 4 будет означать, что выполняется множество избыточных вычислений, но затем это может быть компенсировано инструкциями SIMD по сравнению с матричной работой без SIMD 3x3.

---

Edit: Комментарии о том, как «преждевременная оптимизация есть корень всех зол» (и их производные) являются лишними здесь (и иронически преждевременным, так как вы ничего не знаете о проекте - или меня). Вопрос подводит итог тому, что меня интересует в некоторых точках зрения о/знании больше.

Answer 1

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

Это говорит о том, что многие современные компиляторы авто-векторизуют сейчас, поэтому пользовательский класс, который вы пишете в ванильном C++, может в конечном итоге получить SSE-оптимизацию за кулисами.

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