Стало интересно, насколько он всё же быстрее в реальных задачах. Нашел статью с бенчмарком — сложение чисел в массиве. https://dournac.org/info/gpu_sum_reduction
Видеокарта (не из дешевых, на момент написания статьи) с трудом обгоняет однопоточную реализацию для процессора.
Кто-нибудь объясните, чего я не понимаю?
Здравствуйте, Codealot, Вы писали:
C>Стало интересно, насколько он всё же быстрее в реальных задачах. Нашел статью с бенчмарком — сложение чисел в массиве. https://dournac.org/info/gpu_sum_reduction C>Видеокарта (не из дешевых, на момент написания статьи) с трудом обгоняет однопоточную реализацию для процессора. C>Кто-нибудь объясните, чего я не понимаю?
Я когда делал что-то такое, у меня получалось, что передача в память GPU дорого стоит.
Если уж ты туда засунул массив, то и крути его там внутри GPU. Тогда получается гораздо мощнее.
Ну то есть, поиск максимума по массиву ограничен пропускной способностью памяти, а не процессора/процессоров. GPU не позволяет избавиться от этой зависимости. Всё равно тебе нужно прочитать все байты в массиве — ну и считай сразу минимум тогда, один шут минимум и счётчик цикла в регистрах. Вместо того, чтобы читать все байты только ради того, чтобы сунуть их в GPU, а потом внутри GPU ещё раз читать.
C>Стало интересно, насколько он всё же быстрее в реальных задачах.
Зависит от задачи.
C>Нашел статью с бенчмарком — сложение чисел в массиве. https://dournac.org/info/gpu_sum_reduction
Между замерами времени он запускает вычисления на GPU, копирует буфер (<= 2048 байт) назад на CPU через PCI шину, досчитывает сумму.
Такая задача не будет сильно быстрее.
К тому же кернел он запустил всего один раз, а первый запуск содержит некоторый объем ленивой инициализации. В таких тестах я обычно первым делом запускаю пустой кернел в холостую.
Ну, и использование gettimeofday как вишенка.
Слава:
C>>Кто-нибудь объясните, чего я не понимаю? С>А вы лучше сложите два массива чисел на GPU и CPU. Этак на гигабайт размером, результат складывайте в третий массив.
Сложение всё равно тривиальная операция. На MMX-ах выйдет в разы быстрее.
Менее тривиальные алгоритмы, если хорошо параллелятся, могут дать выигрыш на GPU.
Модератор-националист Kerk преследует оппонентов по политическим мотивам.
Здравствуйте, Codealot, Вы писали:
C>Стало интересно, насколько он всё же быстрее в реальных задачах. Нашел статью с бенчмарком — сложение чисел в массиве. https://dournac.org/info/gpu_sum_reduction C>Видеокарта (не из дешевых, на момент написания статьи) с трудом обгоняет однопоточную реализацию для процессора. C>Кто-нибудь объясните, чего я не понимаю?
На задачах, где отсутствует дивергенция исполнения, и хорошо укладывающихся в парадигму-утрамбовали побольше данных в shared memory и параллельно рассчитали кучей тредов-прирост выходит в районе 700 раз GPU vs однопоточного CPU. Как пример-умножение матриц, использующее заточенный на GPU алгоритм.
На реальных сложных задачах, где никак целиком не отказаться от дивергенции исполнения и при этом задачи большой размерности (вроде Эквилибриума Нэша на вероятностном дереве решений большой глубины)-выходит в ~50 раз быстрее на GPU, чем на однопоточном CPU.
При этом тот же Эквилибриум Нэша в некоторых ситуациях может считаться многопоточно и на CPU, что делает прирост GPU относительно CPU сильно меньше, но железо для рассчета на CPU стоит сильно дороже(вроде цена двухпроцессорного сервака с 64 HT ядрами vs RTX 2080)
Отдельно стоит упомянуть сложность кода для вычислений на CPU и на GPU.
На GPU прилично сложнее. Тот же Эквилибриум Нэша пришлось делать через автоматическую кодогенерацию CUDA Kernel's под каждую конфигурацию дерева, в том числе и для уменьшения траффика памяти между CPU и GPU(ну и по ряду других причин).
Codealot:
C>Стало интересно, насколько он всё же быстрее в реальных задачах. Нашел статью с бенчмарком — сложение чисел в массиве. https://dournac.org/info/gpu_sum_reduction C>Видеокарта (не из дешевых, на момент написания статьи) с трудом обгоняет однопоточную реализацию для процессора. C>Кто-нибудь объясните, чего я не понимаю?
Тонкости реализации могут тоже дать выигрыш в разы. Чем мешьше обращаться к глобальной памяти GPU тем лучше.
Бывают конфликты обращения к другим видам памяти — их нужно выявлять и обходить...
Когда регистров не хватает — компилятор размещает часть переменных в глобальной памяти — начинается резкая просадка производительности
(это я про общий случай. при параллельном суммировании такого нет).
Как-то так...
Модератор-националист Kerk преследует оппонентов по политическим мотивам.
Здравствуйте, Hardballer, Вы писали: H>Отдельно стоит упомянуть сложность кода для вычислений на CPU и на GPU. H>На GPU прилично сложнее. Тот же Эквилибриум Нэша пришлось делать через автоматическую кодогенерацию CUDA Kernel's под каждую конфигурацию дерева, в том числе и для уменьшения траффика памяти между CPU и GPU(ну и по ряду других причин).
А есть какие-то приличные среды/библиотеки, которые бы взяли на себя вот эту вот автоматическую кодогенерацию?
Ну, вот скажем, на C# нам невыносимо легко получать expression trees; есть ли работы по таким оптимизациям исполнения expression trees на GPGPU?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Hardballer, Вы писали: H>>Отдельно стоит упомянуть сложность кода для вычислений на CPU и на GPU. H>>На GPU прилично сложнее. Тот же Эквилибриум Нэша пришлось делать через автоматическую кодогенерацию CUDA Kernel's под каждую конфигурацию дерева, в том числе и для уменьшения траффика памяти между CPU и GPU(ну и по ряду других причин). S>А есть какие-то приличные среды/библиотеки, которые бы взяли на себя вот эту вот автоматическую кодогенерацию? S>Ну, вот скажем, на C# нам невыносимо легко получать expression trees; есть ли работы по таким оптимизациям исполнения expression trees на GPGPU?
Все что плотно щупал(Alea GPU, Altimesh Hybridizer), хорошо работают только в простых сценариях(несмотря на рекламные декларации), в наших сценариях массивных вычислений на графах все сильно плохо. Надо пробовать, возможно их возможностей именно для ваших задач будет с головой.
Alea GPU, правда-уже как минимум пару лет почти не развивается. Altimesh Hybridizer развивается и сейчас, лицензия платная.
Если речь идет о сложных алгоритмах на графах, то только собственный кодогенератор , заточенный на работу с определенным множеством шаблонов CUDA кода, вылизанных до предела, из которых и генерируется исчерпывающая программа вычисления под конкретную конфигурацию дерева-дает нужный мультипликатор прироста производительности к CPU.
Но графовые алгоритмы на CUDA стоят особняком. В 10 CUDA появились CUDA Graphs, которые я пока отложил в сторону по ряду причин.
Здравствуйте, Codealot, Вы писали:
C>Стало интересно, насколько он всё же быстрее в реальных задачах. Нашел статью с бенчмарком — сложение чисел в массиве. https://dournac.org/info/gpu_sum_reduction C>Видеокарта (не из дешевых, на момент написания статьи) с трудом обгоняет однопоточную реализацию для процессора. C>Кто-нибудь объясните, чего я не понимаю?
Здравствуйте, Hardballer, Вы писали:
H>На GPU прилично сложнее. Тот же Эквилибриум Нэша пришлось делать через автоматическую кодогенерацию CUDA Kernel's под каждую конфигурацию дерева, в том числе и для уменьшения траффика памяти между CPU и GPU(ну и по ряду других причин).
А вообще на GPU есть официально поддерживаемый ассемблер? Т.е. на x64 я легко могу писать код на ассемблере, есть и документация и ассемблер и отладчик и профайлер. Я когда смотрел немного, мне показалось, что там всё на ихнем C-подобном языке, а машинный код это уже их проприетарное и там с разумными усилиями не разберёшься.
