GPGPU

Подскажите какую из существующих вариантов реализации стоит изучать?

Мне нужны только сложение, вычитание, умножение и (к сожалению) условия.

Кстати, будет ли прирост скорости и значительный ли при расчётах на GPU, если вместо условных переходов использовать что-то такое:

вместо
это
Ясно, что нахождение числа по модулю - простой пример, который ЦП выполнит быстрее в первом случае, а вот когда это вычисляется миллионами на архитектуре, которая не очень дружит с ветвлениями?

0

общим стандартом для всех gpu является opencl. Но также есть и более специфичные библиотеки, разрабатываемые для конкретных gpu: для nvidia это cuda, для amd - bolt. Есть альтернатива и от microsoft - amp. Так что выбор зависит от конкретных целей и то, на чём будет применяться приложение.

1

На всякий случай. Семантика второго выражения точно так же имеет ветвление

1

Сообщение от Evg На всякий случай. Семантика второго выражения точно так же имеет ветвление

Согласен.
cmp reg,0 или test reg? Или в граф. процессорах нет аналогов?

Добавлено через 17 минут
Битовые сдвиги и OR XOR END-ы в GPU есть?

Добавлено через 15 минут

Сообщение от _lunar_ общим стандартом для всех gpu является opencl

Где-то читал, что пока производители карт тянут одеяло на себя и что "стандартный" openCL пока не особо поддерживается...не знаю на сколько это правда.

Сообщение от _lunar_ выбор зависит от конкретных целей и то, на чём будет применяться приложение

хочу перенести игровой движок на GPU. Там не стандартный подход к представлению 3-d мира, так что обычные OpenGL, DX не подходят. Мне нужна простейшая математика(+,-,*), считающая массив rgba и его отображение на экран. У меня nVidia GeForce 8...но, пожалуй, от того, что моя игра будет работать и на других видеокартах я плакать не буду =)

0

Сообщение от Evg Семантика второго выражения точно так же имеет ветвление.

Проверяли или предполагаете? А то хорошо бы проверить оба, мало ли что там компилятор наоптимизирует.

Добавлено через 5 минут

Сообщение от Retyrn0 if(x<0)x*=(-1);

Конкретно в этом случае лучше всё же использовать специализированную функцию графического процессора abs. Уж её-то точно реализовывали "в железе" так, чтобы она работала с наибольшей скоростью.

1

Сообщение от Nick Alte в этом случае лучше всё же использовать специализированную функцию графического процессора abs

Спасибо, буду знать. На CPU, например, abs() работает медленнее(у меня). Вероятно из-за времени на вызов функции. Но это просто пример, который мне пришёл в голову. Уверен, Вы правильно поняли что я имею ввиду. Будет ли ускорение, если ветвления преобразовать в математику?

0

Сообщение от Retyrn0 Будет ли ускорение, если ветвления преобразовать в математику?

Вот это, кстати, надо измерять. У графических процессоров архитектура кардинально отличается от сложной и универсальной архитектуры процессоров общего назначения. Там может просто не оказаться хитрых "приспособ" вроде предсказателей ветвления и прочего. И многие советы и рекомендации по увеличению производительности, работающие на центральном процессоре, могут оказаться бесполезными или даже вредными на процессоре графическом.
Так что любую оптимизацию лучше измерять, это самый надёжный способ. А ещё лучше оставить при себе "измерялку" и при обновлении аппаратной части перемерить. Результаты могут оказаться весьма любопытными.

0

Сообщение от Nick Alte Проверяли или предполагаете?

"Семантика" - это смысл, который вкладывается в язык программирования (а не в процессор), тут не надо ничего предполагать, всё написано в стандарте языка. Для компилятора нет принципиальной разницы между первым и вторым. Если компилятор умеет должным образом оптимизировать второй исходник, то он соптимизирует и первый.

Сообщение от Nick Alte А то хорошо бы проверить оба, мало ли что там компилятор наоптимизирует.

Проверь, кто ж тебе мешает

0

Сообщение от Nick Alte Вот это, кстати, надо измерять.

В том то и дело, что ГПУ для меня пока - только очень вкусная теоретическая возможность. Я ещё ни одной программы на ГПУ не написал потому что

Сообщение от Retyrn0 Подскажите какую из существующих вариантов реализации стоит изучать?

Думал, может кто уже нащупал подобную возможность.
По-сему я сделал вывод, что нужно учить OpenCL и самому отвечать на 2-й вопрос)

Добавлено через 7 минут

Сообщение от Evg смысл, который вкладывается в язык программирования

Вы бесконечно правы в плане программирования, как точной науки. Но Вы не читаете между строк. Фраза

Сообщение от Retyrn0 если вместо условных переходов использовать что-то такое:

подразумевала, не конкретную функцию, а идею избавиться от ветвлений. Но если Вы предпочитаете точный пример, то:

вместо:
это:
Семантика в порядке?

0

Сообщение от Retyrn0 Но Вы не читаете между строк

Я сразу написал "на всякий случай", ибо было подозрение, что ТС (т.е. ты) не видит разницы между операцией сравнения на позиции condition и rvalue. Моё замечание касалось только этого и больше ничего. Я в глаза не видел ни одного компилятора для GPU, а потому по конкретике я ничего не знаю

Сообщение от Retyrn0 Семантика в порядке?

Я не совсем понимаю, чего ты этим кодом хочешь показать. Значение выражения "x>>31" всегда равно нулю или единице, а потому выражение "x=x&1" является мёртвым кодом. Если это был намёк на то, что этим можно пользоваться вместо (x<0), то да, этим можно пользоваться. Будет ли это быстрее - скорее всего да. "Скорее всего", потому что я не знаю спецификации GPU, но из общих соображений небольшое количество лишних арифметических операций работают эффективнее, чем операция условного перехода

0

Сообщение от Evg Я в глаза не видел ни одного компилятора для GPU, а потому по конкретике я ничего не знаю

ааа.

Сообщение от Evg "x=x&1" является мёртвым кодом

Извините, тупанул. =/ Поспешил - людей насмешил.

Сообщение от Evg "Скорее всего", потому что я не знаю спецификации GPU

Я тоже её не знаю, именно поэтому обратился к людям, которые, возможно, с этим уже сталкивались вплотную. Если кто-то, кто с ГПУ "на ты" уже пользовался таким методом(или счёл его интересным), то мне было бы понятно, по контексту ответа, стоит преобразовывать свой код в математику или "ографичивать" алгоритм, с использованием лаконичных старых добрых if else.

По ответам понял, что люди с этим ещё не сталкивались или считают результат непредсказуемым(на разном железе - разным). По-сему буду юзать условия и не заморачиваться над математикой. Спасибо за ответы.

0

Скажем так, я сталкивался с этим на "обычных" процессорах. Там действительно заморачиваются и вместо if'ов строят арифметику. Мне кажется, что GPU мало чем отличается от "обычного" процессора с точки зрения организации конвейера - на большой частоте приходится делать длинный конвейер, а потому условный переход должен тормозить конвейер. Другое дело, что было бы логично делать условный переход с подсказкой (о том, каким будет наиболее вероятным результат сравнения), но при этом нужно и в язык некоторую конструкцию вносить. В языке GNU C для этих дел используют __builtin_expect, может быть и в языке для GPU есть нечто подобное

0

Сообщение от Evg было бы логично делать условный переход с подсказкой (о том, каким будет наиболее вероятным результат сравнения)

В моём случае это 50/50. signed int координаты могут равновероятно быть положительными и отрицательными.

Сообщение от Evg Мне кажется, что GPU мало чем отличается от "обычного" процессора с точки зрения организации конвейера

Хорошо. Буду тестировать, замерять, как только разжую GPGPU =)

0