Код, оптимизированный для SSE, работает так же, как и обычная версия.

Я хотел сделать свои первые шаги с Intel SSE, поэтому я следовал руководству, опубликованному здесь, с той разницей, что вместо разработки для Windows и C++ я делаю это для Linux и C (поэтому я использую не _aligned_malloc, а posix_memalign).

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

Это нормально? Возможно ли, что GCC уже оптимизирует SSE (также используя опцию -O0)? Я тоже пробовал вариант -mfpmath=387, но никак, все так же.


gcc c x86 simd sse
person Genís    schedule 10.08.2011    source источник
comment
Какой процессор вы используете?   -  person Paul R    schedule 10.08.2011
comment
Я использую Intel Core i7 M640 2,80 ГГц.   -  person Genís    schedule 10.08.2011
comment
ОК - см. мой ответ ниже, и вы также можете опубликовать свой код и командную строку, которую вы используете для его создания.   -  person Paul R    schedule 10.08.2011

Ответы (2)


arrow_upward
2
arrow_downward

Для операций с плавающей запятой вы можете не увидеть огромного преимущества SSE. Большинство современных процессоров x86 имеют два FPU, поэтому двойная точность может быть примерно такой же скоростью для SIMD по сравнению со скалярной, а одинарная точность может дать вам 2x для SIMD по сравнению со скалярной в хороший день. Однако для целочисленных операций, например. обработка изображения или звука с разрядностью 8 или 16 бит, вы все равно можете получить существенные преимущества с помощью SSE.

person Paul R    schedule 10.08.2011
comment
Это может быть причиной. Я попробую версию с одинарной точностью. - person Genís; 10.08.2011
comment
ОК - добавьте код и командную строку тоже к своему вопросу - есть так много простых вещей, в которых вы можете ошибиться, начиная работать с SIMD. - person Paul R; 10.08.2011
comment
Вы были правы, Пол Р. Версия, использующая 32-битные целые числа, получает ускорение примерно в 2 раза быстрее. Я полагаю, что в 16- и 8-битных операциях преимущества были бы еще лучше. Кстати, я удалил эту операцию с квадратным корнем в целочисленной версии. Большое спасибо. - person Genís; 11.08.2011

arrow_upward
1
arrow_downward

GCC имеет очень хороший встроенный векторизатор кода (который iirc запускается при -00 и выше), поэтому это означает, что он будет использовать SIMD в любом месте, где это возможно, чтобы ускорить скалярный код (он также немного оптимизирует SIMD-код). тоже, если это возможно).

довольно легко убедиться, что это действительно то, что здесь происходит, просто разберите вывод (или попросите gcc выдать прокомментированные asm-файлы).

person Necrolis    schedule 10.08.2011
comment
Я проверил код на ассемблере и увидел только пару инструкций addps, которые я ожидал от куска кода с явным (как минимум) SSE. - person Genís; 10.08.2011
comment
Я сомневаюсь, что автоматическая векторизация вступает в игру при O0 (без оптимизации), поскольку это очень тяжелая оптимизация, которая должна срабатывать только при O2 или O3. - person Christian Rau; 10.11.2011
comment
Если вы посмотрите на справочную страницу gcc, там написано, что -ftree-vectorize устанавливается -O3. Это в Debian/Ubuntu, на других платформах может быть иначе. Осторожно, -O0 – это 0 оптимизация. Оптимизация начинается с -O1 - person Hans-Christoph Steiner; 21.12.2012