Можем ли мы измерить скорость CUDA или OpenCL по сравнению с производительностью процессора?

Question

Насколько быстрее может работать алгоритм в коде CUDA или OpenCL по сравнению с обычным одноядерным ядром? (учитывая, что алгоритм написан и оптимизирован для целевого процессора и графического процессора).

Я знаю, что это зависит как от видеокарты, так и от процессора, но, скажем, один из самых быстрых графических процессоров NVIDIA и (одноядерный) процессор Intel i7?

И я знаю, что это также зависит от типа алгоритма.

Мне не нужен строгий ответ, но опытные примеры, такие как: для алгоритма манипулирования изображениями с использованием плавающей запятой двойной точности и 10 операций на пиксель, заняли первые 5 минут и теперь выполняются за x секунд с использованием этого оборудования.

Answer 1

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

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

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

Я видел, как это превращало заявленный плюс в отрицательный, потому что время загрузки / выгрузки было больше, чем требовалось основному ЦП для вычисления.

Практически то же самое относится и к объединению результатов разных видеокарт.

Обновление Новые графические процессоры, по-видимому, могут одновременно загружать / скачивать и вычислять, используя буферы для пинг-понга.Но совет, чтобы проверить условия границы тщательно все еще остается в силе.Там много спина.

Answer 2

Это очень сильно зависит от алгоритма и того, насколько эффективной может быть реализация.

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

Например, 1581,1 GFlops для GTX580 против 107,55 GFLOPS для i7 980XE. Обратите внимание, что рейтинг для GTX580 предназначен для одинарной точности. Я считаю, что вам нужно сократить это в 4 раза, чтобы класс Ферми, не являющийся Теслой, смог получить рейтинг с двойной точностью. Так что в этом случае вы можете ожидать примерно 4x.

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

1. GPU имеет лучшую пропускную способность памяти, чем CPU, когда данные находятся на карте. Иногда алгоритмы, связанные с памятью, могут хорошо работать на GPU.

2. Умное использование кэшей (память текстур и т. Д.), Которые позволяют вам работать лучше, чем заявленная пропускная способность.

3. Как говорит Марко, время перевода не учитывается. Я лично всегда включаю такое время в свою работу и, таким образом, обнаружил, что наибольшее ускорение, которое я видел, было в итеративных алгоритмах, где все данные помещаются на GPU (я получил более 300x на CPU среднего и среднего уровня здесь лично ).

4. яблоки для сравнения апельсинов. Сравнение высокопроизводительного GPU с низкоуровневым CPU по своей сути несправедливо. Опровержение состоит в том, что высокопроизводительный процессор стоит намного дороже, чем высокопроизводительный GPU. Когда вы перейдете к сравнению GFlops / $ или GFlops / Watt, оно может выглядеть гораздо более выгодным для GPU.

Answer 3

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

В частности, вы сравниваете оба: 1) выбор алгоритма 2) относительную производительность аппаратного обеспечения 3) возможность оптимизации компилятора 4) выбор языков реализации и 5) эффективность реализации алгоритма, все одновременно ...

Обратите внимание, что, например, разные алгоритмы могут быть предпочтительнее на GPU по сравнению с CPU; и передачи данных в и из GPU также должны учитываться в сроки.

У AMD есть конкретный пример (на самом деле, несколько) производительности OpenCL для кода OpenCL, выполняемого на процессоре и на графическом процессоре. Здесь - это результат производительности для умножения вектора с разреженной матрицей.

Answer 4

Я думаю, что это видео введение в OpenCL дает хороший ответ на ваш вопрос в первом или втором эпизоде ​​(я не помню).Я думаю, что это было в конце первого эпизода ...

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

Answer 5

__kernel void vecAdd(__global float* results )
{
   int id = get_global_id(0);
}

этот код ядра может порождать 16M потоков на новом 60 $ R7-240 GPU за 10 миллисекунд.

Это эквивалентно 16 созданиям потока или переключению контекста за 10 наносекунд. Что такое синхронизация с 8-ядерным процессором FX-8150 за 140 $? Это 1 поток в 50 наносекунд на ядро.

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

Answer 6

Новый набор тестов под названием SHOC (Scalable Heterogene Computing) от Oak Ridge National Lab и Georgia Tech имеет реализации OpenCL и CUDA многих важных ядер. Вы можете скачать комплект с http://bit.ly/shocmarx. Наслаждайтесь.

Answer 7

Я видел цифры от 2х до 400х. Я также знаю, что средние графические процессоры не могут конкурировать с высокопроизводительными процессорами в вычислениях двойной точности - MKL на 8-ядерном Xeon будет быстрее, чем CULA или CUBLAS на GPU за 300 долларов.

OpenCL анекдотически намного медленнее, чем CUDA.