Вопрос

Мне интересно узнать, написал ли кто-нибудь приложение, использующее преимущества GPGPU используя, например,, nVidia CUDA.Если да, то какие проблемы вы обнаружили и какого прироста производительности вы добились по сравнению со стандартным процессором?

Это было полезно?

Решение

Я занимался разработкой gpgpu с помощью Stream SDK от ATI вместо Cuda.Какой прирост производительности вы получите, зависит от лот факторов, но наиболее важным является числовая интенсивность.(То есть отношение вычислительных операций к ссылкам на память.)

Функция BLAS уровня 1 или BLAS уровня 2, такая как добавление двух векторов, выполняет только 1 математическую операцию для каждых 3 ссылок на память, поэтому NI равен (1/3).Это всегда выполняется медленнее с CAL или Cuda, чем просто работать с процессором.Основная причина - это время, необходимое для передачи данных с центрального процессора на графический и обратно.

Для такой функции, как FFT, существует O (N log N) вычислений и O (N) ссылок на память, поэтому NI равен O (log N).Если N очень велико, скажем, 1 000 000, то, скорее всего, будет быстрее сделать это на графическом процессоре;Если N мало, скажем, 1000, это почти наверняка будет медленнее.

Для функции уровня BLAS 3 или LAPACK, такой как LU-разложение матрицы или нахождение ее собственных значений, существует O (N ^ 3) вычислений и O (N ^ 2) ссылок на память, поэтому NI равен O (N).Для очень маленьких массивов, скажем, N - это несколько баллов, это все равно будет быстрее выполняться на процессоре, но по мере увеличения N алгоритм очень быстро переходит от привязки к памяти к привязке к вычислениям, и увеличение производительности на графическом процессоре растет очень быстро.

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


(источник: earthlink.net)

Вот производительность CGEMM - сложной матрицы одинарной точности-умножение матриц выполняется на Radeon 4870.

Другие советы

Я написал тривиальные приложения, это действительно помогает, если вы можете распараллелить вычисления с плавающей запятой.

Когда я только начинал, мне показался очень полезным следующий курс, который преподавали профессор Университета Иллинойса Урбана Шампейн и инженер NVIDIA: http://courses.ece.illinois.edu/ece498/al/Archive/Spring2007/Syllabus.html (включает записи всех лекций).

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

ИМО, существует три типичных этапа переноса алгоритма на CUDA:

  1. Начальный перенос: Даже обладая очень базовыми знаниями CUDA, вы можете перенести простые алгоритмы в течение нескольких часов.Если вам повезет, вы увеличите производительность в 2-10 раз.
  2. Тривиальные оптимизации: Это включает в себя использование текстур для входных данных и заполнение многомерных массивов.Если у вас есть опыт, это можно сделать в течение дня и, возможно, повысить производительность еще в 10 раз.Полученный код по-прежнему доступен для чтения.
  3. Жесткая оптимизация: Это включает в себя копирование данных в общую память, чтобы избежать глобальной задержки памяти, выворачивание кода наизнанку, чтобы уменьшить количество используемых регистров, и т.д.Вы можете потратить на этот шаг несколько недель, но в большинстве случаев выигрыш в производительности того не стоит.После этого шага ваш код будет настолько запутан, что его никто не поймет (включая вас).

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

Я использую GPGPU для обнаружения движения (первоначально с использованием CG, а теперь CUDA) и стабилизации (с использованием CUDA) при обработке изображений.В таких ситуациях я получаю ускорение примерно в 10-20 раз.

Из того, что я прочитал, это довольно типично для алгоритмов, параллельных данным.

Хотя у меня пока нет никакого практического опыта работы с CUDA, я изучал этот предмет и нашел ряд статей, в которых документируются положительные результаты использования API GPGPU (все они включают CUDA).

Это бумага описывает, как соединения с базой данных могут быть парализованы путем создания ряда параллельных примитивов (map, scatter, gather и т.д.), Которые могут быть объединены в эффективный алгоритм.

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

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

Я реализовал расчет по методу Монте-Карло в CUDA для некоторых финансовых целей.Оптимизированный код CUDA работает примерно в 500 раз быстрее, чем многопоточная реализация процессора, которая "могла бы постараться сильнее, но не совсем".(Здесь сравнивается GeForce 8800GT с Q6600).Однако хорошо известно, что задачи Монте-Карло поразительно параллельны.

Основные возникающие проблемы связаны с потерей точности из-за ограничения чипов G8x и G9x числами с плавающей запятой одинарной точности IEEE.С выпуском чипов GT200 это можно было бы в некоторой степени смягчить за счет использования блока двойной точности, за счет некоторого снижения производительности.Я еще не пробовал это делать.

Кроме того, поскольку CUDA является расширением C, интеграция его в другое приложение может быть нетривиальной.

Я реализовал генетический алгоритм на графическом процессоре и получил ускорение примерно в 7 раз..Как отметил кто-то другой, больший выигрыш возможен при более высокой числовой интенсивности.Так что да, выигрыш есть, если приложение выбрано правильно

Я написал ядро сложнозначного матричного умножения, которое превосходило реализацию cuBLAS примерно на 30% для приложения, для которого я его использовал, и своего рода векторную функцию внешнего произведения, которая выполнялась на несколько порядков быстрее, чем решение с умножением трассировки для остальной части задачи.

Это был проект последнего года.На это у меня ушел целый год.

http://www.maths.tcd.ie /~oconbhup/Maths_Project.pdf

Я реализовал факторизацию Холецкого для решения больших линейных уравнений на графическом процессоре, используя ATI Stream SDK.Мои наблюдения были следующими

alt text

Производительность увеличена в 10 раз.

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

ДА.Я реализовал следующие Нелинейный Анизотропный Диффузионный фильтр используя CUDA api.

Это довольно просто, поскольку это фильтр, который должен запускаться параллельно с учетом входного изображения.Я не столкнулся с большими трудностями по этому поводу, так как для этого просто требовалось простое ядро.Ускорение было примерно в 300 раз.Это был мой последний проект по CS.Проект можно найти здесь (написано по-португальски "ты").

Я пробовал писать Мамфорд и Шах алгоритм сегментации тоже, но писать его было непросто, поскольку CUDA все еще находится в начале разработки, и поэтому происходит много странных вещей.Я даже заметил улучшение производительности за счет добавления if (false){} в коде O_O.

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top