Насколько ускорились преобразования 3D-математики в SSE или другие SIMD?

Question

Я широко использую 3D математику в своем приложении. Насколько можно ускорить преобразование моей векторной / матричной библиотеки в SSE, AltiVec или аналогичный код SIMD?

Answer 1

По своему опыту я обычно вижу, что при переходе на алгоритм x87 к SSE улучшение в 3 раза лучше, а при переходе на VMX / Altivec * лучше , чем в 5 раз (из-за сложных проблем, связанных с конвейером глубина, планирование и т. д.). Но я обычно делаю это только в тех случаях, когда мне нужно оперировать сотнями или тысячами чисел, а не в тех случаях, когда я делаю один вектор за раз.

Answer 2

Это не вся история, но с помощью SIMD можно получить дальнейшую оптимизацию, взгляните на презентацию Мигеля о том, как он реализовал инструкции SIMD с MONO, которые он держал на PDC 2008 ,

_{(источник: tirania.org )}

Изображение из записи в блоге Мигеля.

Answer 3

При работе с 3D остерегайтесь неинициализированных данных в вашем W-компоненте. Я видел случаи, когда операции SSE (_mm_add_ps) занимали 10-кратное нормальное время из-за неверных данных в W.

Answer 4

Для некоторых очень грубых чисел: я слышал, что некоторые люди на ompf.org утверждают, что 10-кратное увеличение скорости для некоторых ручных оптимизированных процедур трассировки лучей. У меня также были хорошие ускорения. По моим оценкам, в зависимости от проблемы я получал где-то между 2x и 6x, и у многих из них было несколько ненужных магазинов и загрузок. Если в вашем коде имеется большое количество ветвлений, забудьте об этом, но для задач, которые, естественно, параллельны данным, вы можете справиться довольно хорошо.

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

например. Что-то вроде

namespace SIMD {
class PackedVec4d
{
  __m128 x;
  __m128 y;
  __m128 z;
  __m128 w;

  //...
};
}

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

Answer 5

Ответ во многом зависит от того, что делает библиотека и как она используется.

Коэффициент усиления может увеличиваться с нескольких процентов до «в несколько раз быстрее». Наиболее восприимчивыми к коэффициентам усиления являются области, в которых вы имеете дело не с изолированными векторами или значениями, а с несколькими векторами или значениями, которые должны быть обрабатываются таким же образом.

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

Доменами, где усиление может быть наиболее значительным, являются, вероятно, области обработки изображений и сигналов, вычислительного моделирования, а также общей математической 3D-операции над сетками (а не изолированными векторами).

Answer 6

В наши дни все хорошие компиляторы для x86 по умолчанию генерируют инструкции SSE для плавающей математики SP и DP. Эти инструкции почти всегда быстрее, чем стандартные, даже для скалярных операций, если вы правильно их запланировали. Это станет неожиданностью для многих, которые в прошлом находили SSE «медленным», и считали, что компиляторы не могут генерировать быстрые скалярные инструкции SSE. Но теперь вам нужно использовать переключатель, чтобы отключить генерацию SSE и использовать x87. Обратите внимание, что на этом этапе x87 фактически устарела и может быть полностью удалена из будущих процессоров. Единственным недостатком этого является то, что мы можем потерять способность делать 80-битные плавающие DP в регистре. Но консенсус, по-видимому, заключается в том, что если вам нужна точность 80 бит вместо 64-битных плавающих DP, вам следует искать более точный алгоритм, допускающий потери.

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

Answer 7

Скорее всего, вы увидите только очень небольшое ускорение, если оно есть, и процесс будет более сложным, чем ожидалось. Более подробную информацию см. В статье Вездесущий векторный класс SSE , автор - Фабиан Гизен.

Вездесущий векторный класс SSE: развенчание общего мифа

Не так важно

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

Не так жарко

Не просто

Не сейчас

Не всегда