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

См. также:

для Microsoft Visual C:

http://msdn.microsoft.com/en-us/library/2e70t5y1%28v=vs. 80% 29.aspx

и GCC утверждают совместимость с компилятором Microsoft .:

http://gcc.gnu.org/onlinedocs/gcc/Structure_002dPacking -Pragmas.html

В дополнение к предыдущим ответам, обратите внимание, что независимо от упаковки в C ++ нет гарантий-распоряжений-членов. Компиляторы могут (и, конечно же, делать) добавлять в структуру элементов виртуальной таблицы и базовых структур. Даже существование виртуальной таблицы не обеспечивается стандартом (реализация виртуального механизма не указана), и поэтому можно сделать вывод, что такая гарантия просто невозможна.

Я вполне уверен, что порядок членов является гарантировано в C, но я не стал бы рассчитывать на это, когда писал кросс-платформенную или кросс-компиляторную программу.

10
задан Suma 22 September 2008 в 14:55
поделиться

6 ответов

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

.
7
ответ дан 4 December 2019 в 05:50
поделиться

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

SIMD beats doubles' ass in this particular configuration.
(источник: tirania.org)

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

3
ответ дан 4 December 2019 в 05:50
поделиться

Скорее всего, Вы будете видеть только очень маленькое ускорение, если таковые имеются, и процесс будет более сложным, чем ожидалось. Для получения дополнительной информации см. Повсеместную статью класса вектора SSE Fabian Giesen.

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

Не то, чтобы важный

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

Не настолько горячий

Не легкий

Не теперь

Не когда-либо

-19
ответ дан 4 December 2019 в 05:50
поделиться

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

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

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

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

1
ответ дан 4 December 2019 в 05:50
поделиться

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

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

0
ответ дан 4 December 2019 в 05:50
поделиться

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

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

Например, что-то вроде

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

  //...
};
}

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

2
ответ дан 4 December 2019 в 05:50
поделиться
Другие вопросы по тегам:

Похожие вопросы: