Мне интересно узнать, были ли портированы какие-либо общие алгоритмы (сортировка, поиск, графики и т.д.) на OpenCL (или на любой язык графического процессора) и как производительность сравнивается с тем же самым алгоритмом, который выполняется ЦП. Меня особенно интересуют результаты (числа).
Спасибо!
На веб-сайте NVidia есть несколько примеров такого рода вещей. Имейте в виду, что некоторые вещи, такие как сортировка, нуждаются в специальных алгоритмах для эффективного parallelism и могут быть не столь эффективными, как не-поточный алгоритм на одном ядре.
Графические процессоры - это высокоспециализированное оборудование, предназначенное для небольшого набора задач очень хорошо и сильно распараллеливается. Это в основном арифметика (особенно математика с плавающей запятой с одинарной точностью, хотя новые графические процессоры хорошо справляются с двойной точностью). Таким образом, они подходят только для конкретных алгоритмов. Я не уверен, что сортировка соответствует этой категории (в общем случае, по крайней мере).
Более распространенными примерами являются ценообразование финансовых инструментов, большое количество матричных вычислений и даже преодоление шифрования (путем грубой силы). При этом я нашел Быстрое параллельное GPU-сортировку с использованием гибридного алгоритма.
Другим часто цитируемым примером является запуск SETI @HOME на графическом процессоре Nvidia, но сравнение яблок с апельсинами. Единицы работы для графических процессоров отличаются (и очень ограничены) по сравнению с тем, что обычно делают процессоры.
Посмотрите тяга:
Thrust - это параллельная библиотека CUDA алгоритмы с интерфейсом похожий на стандартный шаблон С++ Библиотека (STL). Thrust обеспечивает гибкий высокоуровневый интерфейс для GPU программирование, которое значительно улучшает производительность разработчиков.
БУДЬТЕ ОЧЕНЬ, ОЧЕНЬ ОЧЕНЬ любого числа производительности, указанного для GPGPU. Многим людям нравится публиковать действительно впечатляющие цифры, которые не учитывают время передачи, необходимое для получения входных данных от CPU к графическому процессору и выходных данных назад, оба переходят через узкое место PCIe.
Изменение размера изображения должно распространяться на многих веб-сайтах, которые принимают загрузки изображений.
Изменение размера изображения jpeg размером 2600ish x 2000ish (до 512x512) заняло 23,5 миллисекунды в С# с параметрами самого низкого качества и выборкой ближайших соседей. Используемая функция была graphics.DrawImage() на основе. Использование процессора также составляло% 21,5.
Получение "массива байтов rgba" на стороне С# и отправка его на GPU и изменение размера в графическом процессоре и получение результатов обратно в изображение занимали 6,3 миллисекунды, а загрузка процессора составляла% 12,7. Это было сделано с более дешевым gpu% 55 с 320 ядрами.
Только множитель умножения 3.73X.
Ограничивающим фактором здесь было, посылая извлеченные 20MB данные rgb (jpeg только 2MB!) в GPU. Эта часть времени составляла почти 90% общего времени, включая извлечение боковых байтов на С#! Таким образом, я думаю, что будет примерно 30-кратное ускорение, по крайней мере, если часть извлечения также может быть выполнена на GPU.
30X неплохо.
Затем вы можете выполнить конвейерный слой с уровнем изменения размера, чтобы скрыть латентность памяти, чтобы получить еще большую скорость! Это может быть 40X-50X.
Затем увеличьте качество выборки (например, бикубический, а не ближайший сосед), у вас есть еще больше преимуществ на стороне GPU. Добавление 5x5 гауссовского фильтра добавило всего 0,77 миллисекунды. CPU будет получать более высокое время, особенно если требуемые параметры Гаусса отличаются от реализации С#.Net.
Даже если вас не устраивает коэффициент ускорения, разгрузка на GPU и наличие "свободного ядра" на процессоре по-прежнему выгодно для того, чтобы направить больше работы на этот сервер.
Теперь добавьте факт уровней энергопотребления GPU (30 Вт против 125 Вт в этом примере), это намного выгоднее.
CPU вряд ли выиграет в
C[i]=A[i]+B[i]
когда обе стороны работают на оптимизированных кодах, и вы все равно можете разгрузить половину массивов на GPU и быстрее завершить работу с CPU + GPU.
GPU не создан для неравномерных работ. Графические процессоры имеют глубокие трубопроводы, поэтому встать после стойла из-за разветвления занимает слишком много времени. Также аппаратное обеспечение SIMD заставляет его делать то же самое на всех рабочих элементах на нем. Когда workitem делает что-то другое, чем группа, он теряет трек и добавляет пузыри во весь протокол SIMD, или просто другие ждут точки синхронизации. Таким образом, брандинг влияет как на глубокие, так и на широкие области трубопроводов и делает его еще медленнее, чем процессор, в абсолютно хаотичных условиях.