Попался мне на глаза студенческий курсач, в котором нужно было перемалывать числа. Чтобы работало быстрее — на GPGPU.
Что-то показалось мне в коде подозрительным, я немного его поковырял, и выяснилось, что эта "оптимизированная" версия работает в 10 (!) раз медленнее, чем самая примитивная однопоточная версия на CPU практически без оптимизаций.

А потом эти студенты идут интернами в Майкрософт и Гугл...

Здравствуйте, Codealot, Вы писали:

C>Попался мне на глаза студенческий курсач, в котором нужно было перемалывать числа...

Пруфы?

Здравствуйте, Nuzhny, Вы писали:

N>Пруфы?

В смысле, хочешь на код посмотреть?

Курсовые не для того пишутся, чтобы прямо сразу пользу человечеству принести, а для того, чтобы студент знания приобрел.
Так и иные проектики мутятся не для того, чтобы пользу работодателю принести...

Здравствуйте, yenik, Вы писали:

Y>а для того, чтобы студент знания приобрел.

Ага. Вот такие и знания.

Здравствуйте, Codealot, Вы писали:

N>>Пруфы?
C>В смысле, хочешь на код посмотреть?

Да

Здравствуйте, Nuzhny, Вы писали:

N>Да

Ты разбираешься в OpenCL?

Здравствуйте, Codealot, Вы писали:

N>>Да
C>Ты разбираешься в OpenCL?

Да, я даже работал когда-то программистом на OpenCL

Здравствуйте, Nuzhny, Вы писали:

N>Да, я даже работал когда-то программистом на OpenCL

Ну тогда жду твоего веского мнения. Видеокарта — RX 580, если от этого что-то зависит.

http://files.rsdn.org/138247/mult.c

Y>>а для того, чтобы студент знания приобрел.

C>Ага. Вот такие и знания.

Настоящее знание не сразу приходит. Был бы ум пытливый.

Здравствуйте, Codealot, Вы писали:

C>Попался мне на глаза студенческий курсач, в котором нужно было перемалывать числа. Чтобы работало быстрее — на GPGPU.
C>Что-то показалось мне в коде подозрительным, я немного его поковырял, и выяснилось, что эта "оптимизированная" версия работает в 10 (!) раз медленнее, чем самая примитивная однопоточная версия на CPU практически без оптимизаций.

Интересно, читают ли сейчас студенты книги вроде Б.Керниган, Р.Пайк. Практика программирования. Там немало времени уделено показу того, как можно оптимизацией алгоритма ускорить работу программы в десятки и более раз.

Здравствуйте, Codealot, Вы писали:

C>Попался мне на глаза студенческий курсач, в котором нужно было перемалывать числа. Чтобы работало быстрее — на GPGPU.
C>Что-то показалось мне в коде подозрительным, я немного его поковырял, и выяснилось, что эта "оптимизированная" версия работает в 10 (!) раз медленнее, чем самая примитивная однопоточная версия на CPU практически без оптимизаций.

C>А потом эти студенты идут интернами в Майкрософт и Гугл...


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

Здравствуйте, Codealot, Вы писали:

N>>Да, я даже работал когда-то программистом на OpenCL

C>Ну тогда жду твоего веского мнения. Видеокарта — RX 580, если от этого что-то зависит.

C>http://files.rsdn.org/138247/mult.c

MAX_BATCH_SIZE слишком маленький, должен быть в данном конкретном случае равен DATA_SIZE .. (т.е. за один проход видяха должна вычислять, ибо в данном случае 4 GB VRAM — для этого более, чем достаточно — массивы займут 768 MB VRAM)

да и возможно с учётом перегонки туда сюда (RAM->VRAM->RAM) вообще на таких простейших вычислениях особо и не ускоришь — по сравнению с CPU .. (т.е. даже для оптимального GPGPU варианта)

N>>Да, я даже работал когда-то программистом на OpenCL
C>Ну тогда жду твоего веского мнения. Видеокарта — RX 580, если от этого что-то зависит.
C>http://files.rsdn.org/138247/mult.c

Я за него:
1.

#define DATA_SIZE (64 * 1024 * 1024)
#define MAX_BATCH_SIZE (16 * 1024)

не нужно в данном случае — тормоза на ровном месте

2. в замер времени также попало
а. выделение памяти на GPU (неявно)
б. копирование массивов туда-сюда (явно)
в. отложенная инициализация кернела (неявно)

а так — да, ради одного поэлементного перемножения двух массивов использовать GPU явно перебор.

Здравствуйте, Muxa, Вы писали:

M>2. в замер времени также попало
M>а. выделение памяти на GPU (неявно)

выделение VRAM буфферов — до засечки таймера

M>б. копирование массивов туда-сюда (явно)

а без этого никак по сравнению с CPU — это время должно считаться, ибо на CPU — нет необходимости перекопировать массивы

M>в. отложенная инициализация кернела (неявно)

ну это да, опционально — хотя и вряд ли много жрёт, но по сравнению с батчем (MAX_BATCH_SIZE) и его тормозами, так и ваще ерунда

M>а так — да, ради одного поэлементного перемножения двух массивов использовать GPU явно перебор.

слыхал в AI матрицы много перемножпются, вот там да — прирост так прирост (особенно на тензорах) на новых видяшках

M>>2. в замер времени также попало
M>>а. выделение памяти на GPU (неявно)
I>выделение VRAM буфферов — до засечки таймера
До засечки создаются пустые объекты буферов, фактическое выделение откладывается к моменту первого использования.

M>>б. копирование массивов туда-сюда (явно)
I>а без этого никак по сравнению с CPU — это время должно считаться, ибо на CPU — нет необходимости перекопировать массивы
Зато на CPU есть необходимость, к примеру, прочитать входные данные с диска, а потом сохранить обратно. Не в этом случае, а вообще.
Тоже будем это время учитывать? И если нет, то почему?

Здравствуйте, Codealot, Вы писали:

N>>Да, я даже работал когда-то программистом на OpenCL
C>Ну тогда жду твоего веского мнения. Видеокарта — RX 580, если от этого что-то зависит.
C>http://files.rsdn.org/138247/mult.c

Ха-ха-ха!
Это даже на лабораторную не тянет, просто минимальный пример. В OpenCL надо писать кучу кода, чтобы его просто запустить. Но этот пример — пустышка, на его примере глупо делать какие-то выводы.

Здравствуйте, Codealot, Вы писали:

C>http://files.rsdn.org/138247/mult.c
Гы, классика! Там одна тока передача данных в видюху займёт больше чем всё на CPU посчитать.

Здравствуйте, Muxa, Вы писали:

I>>выделение VRAM буфферов — до засечки таймера
M>До засечки создаются пустые объекты буферов, фактическое выделение откладывается к моменту первого использования.

откуда инфа ? если что, не оспариваю — но не слыхал о таком ..

I>>а без этого никак по сравнению с CPU — это время должно считаться, ибо на CPU — нет необходимости перекопировать массивы
M>Зато на CPU есть необходимость, к примеру, прочитать входные данные с диска, а потом сохранить обратно. Не в этом случае, а вообще.

а в случае GPU — нет такой необходимости или что ?

M>Тоже будем это время учитывать? И если нет, то почему?

обычно GPGPU вычисления применяются к тем данным и вычислениям, где упора в диск нет ..

I>>>выделение VRAM буфферов — до засечки таймера
M>>До засечки создаются пустые объекты буферов, фактическое выделение откладывается к моменту первого использования.
I>откуда инфа ? если что, не оспариваю — но не слыхал о таком ..
Официально — ниоткуда.
Косвенно — из личного опыта и, например, отсюда https://www.khronos.org/registry/OpenCL/sdk/2.2/docs/man/html/clEnqueueNDRangeKernel.html

clEnqueueNDRangeKernel returns one of the following errors:
CL_​MEM_​OBJECT_​ALLOCATION_​FAILURE if there is a failure to allocate memory for data store associated with image or buffer objects specified as arguments to kernel.

тоже самое для

clEnqueueReadBuffer and clEnqueueWriteBuffer return one of the following errors:
CL_​MEM_​OBJECT_​ALLOCATION_​FAILURE if there is a failure to allocate memory for data store associated with buffer.

I>>>а без этого никак по сравнению с CPU — это время должно считаться, ибо на CPU — нет необходимости перекопировать массивы
M>>Зато на CPU есть необходимость, к примеру, прочитать входные данные с диска, а потом сохранить обратно. Не в этом случае, а вообще.
I>а в случае GPU — нет такой необходимости или что ?
Иногда есть. Учитывать или нет?

M>>Тоже будем это время учитывать? И если нет, то почему?
I>обычно GPGPU вычисления применяются к тем данным и вычислениям, где упора в диск нет ..
Часто просчитанные данные нужно просто отобразить на мониторе.
Учитывать ли в данном случае это копирование в расчетах на СPU?