Numba и guvectorize для цели CUDA: код работает медленнее, чем ожидалось

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

Возможно, будет реализована реализация ядра numba/cuda guvectorize (или cuda.jit kernel), которая может работать быстрее, чем наивная последовательная реализация на основе python, но я сомневаюсь, что можно будет превысить производительность хорошо написанного кода хоста (например, используя некоторый метод распараллеливания, такой как guvectorize), чтобы сделать то же самое. Это связано с тем, что интенсивность арифметики на один байт, передаваемый между хостом и устройством, слишком низка. Эта операция слишком проста.

Во- вторых, это важно, я считаю, чтобы начать с понимания того, что Numba vectorize и guvectorize предназначены сделать. Основной принцип состоит в том, чтобы написать определение ufunc с точки зрения "что сделает работник?" а затем разрешить numba откручивать от этого несколько сотрудников. Способ, которым вы даете указание numba разворачивать нескольких сотрудников, - это передать набор данных, который больше, чем подписи, которые вы указали. Следует отметить, что numba не знает, как распараллеливать цикл for внутри определения ufunc. Он получает параллельную "силу", принимая определение ufunc и запуская его между параллельными рабочими, где каждый рабочий обрабатывает "срез" данных, но выполняет все определение ufunc на этом фрагменте. В некоторых дополнительных чтения, я покрыл часть этой земли здесь также.

Поэтому проблема, которую мы имеем в вашей реализации, заключается в том, что вы написали подпись (и ufunc), которая отображает все входные данные, установленные для одного рабочего. Как показало @talonmies, ваше основное ядро развертывается в общей сложности с 64 потоками/рабочими (что очень мало для того, чтобы быть интересным на графическом процессоре, даже если не считать вышеупомянутых утверждений об интенсивности арифметики), но я подозреваю, 64 на самом деле всего лишь минимальный размер блокировки numba, и на самом деле только 1 поток в этом поточном блоке выполняет любую полезную работу вычисления. Этот поток выполняет весь ваш ufunc, включая все for-loops, в серийном режиме.

Это, очевидно, не то, что кто-либо намерен для рационального использования vectorize или guvectorize.

Поэтому позвольте вернуться к тому, что вы пытаетесь сделать. В конечном итоге ваш ufunc хочет умножить входное значение из одного массива на входное значение из другого массива и сохранить результат в третьем массиве. Мы хотим повторить этот процесс много раз. Если бы все 3 массива были одинаковыми, мы могли бы реализовать это с помощью vectorize и даже не прибегать к более сложному guvectorize. Давайте сравним этот подход с вашим оригиналом, сосредоточив внимание на выполнении ядра CUDA. Здесь обработанный пример, где t14.py ваш исходный код, работать с профилировщиком и t15.py является vectorize версию этого, признавая, что мы изменили размер вашего multBy массива, чтобы соответствовать cv и discount:

$ nvprof --print-gpu-trace python t14.py
==4145== NVPROF is profiling process 4145, command: python t14.py
Function: discount factor cumVest duration (seconds):1.24354910851
==4145== Profiling application: python t14.py
==4145== Profiling result:
   Start  Duration            Grid Size      Block Size     Regs*    SSMem*    DSMem*      Size  Throughput  SrcMemType  DstMemType           Device   Context    Stream  Name
312.36ms  1.2160us                    -               -         -         -         -        8B  6.2742MB/s    Pageable      Device  Quadro K2000 (0         1         7  [CUDA memcpy HtoD]
312.81ms  27.392us                    -               -         -         -         -  156.25KB  5.4400GB/s    Pageable      Device  Quadro K2000 (0         1         7  [CUDA memcpy HtoD]
313.52ms  5.8696ms                    -               -         -         -         -  15.259MB  2.5387GB/s    Pageable      Device  Quadro K2000 (0         1         7  [CUDA memcpy HtoD]
319.74ms  1.0880us                    -               -         -         -         -        8B  7.0123MB/s    Pageable      Device  Quadro K2000 (0         1         7  [CUDA memcpy HtoD]
319.93ms     896ns                    -               -         -         -         -        8B  8.5149MB/s    Pageable      Device  Quadro K2000 (0         1         7  [CUDA memcpy HtoD]
321.40ms  1.22538s              (1 1 1)        (64 1 1)        63        0B        0B         -           -           -           -  Quadro K2000 (0         1         7  cudapy::__main__::__gufunc_cVestDiscount$242(Array<__int64, int=1, A, mutable, aligned>, Array<double, int=3, A, mutable, aligned>, Array<double, int=4, A, mutable, aligned>, Array<__int64, int=1, A, mutable, aligned>, Array<__int64, int=1, A, mutable, aligned>, Array<double, int=4, A, mutable, aligned>) [37]
1.54678s  7.1816ms                    -               -         -         -         -  15.259MB  2.0749GB/s      Device    Pageable  Quadro K2000 (0         1         7  [CUDA memcpy DtoH]

Regs: Number of registers used per CUDA thread. This number includes registers used internally by the CUDA driver and/or tools and can be more than what the compiler shows.
SSMem: Static shared memory allocated per CUDA block.
DSMem: Dynamic shared memory allocated per CUDA block.
SrcMemType: The type of source memory accessed by memory operation/copy
DstMemType: The type of destination memory accessed by memory operation/copy
$ cat t15.py
import numpy as np
from numba import guvectorize,vectorize
import time
from timeit import default_timer as timer


@vectorize(['float64(float64, float64)'], target='cuda')
def cVestDiscount (a, b):
    return a * b

discount = np.float64(np.arange(2000000).reshape(100,4000,5))
multBy = np.full_like(discount, 1)
cv = np.empty_like(discount)
func_start = timer()
cv = cVestDiscount(multBy, discount)
timing=timer()-func_start
print("Function: discount factor cumVest duration (seconds):" + str(timing))
$ nvprof --print-gpu-trace python t15.py
==4167== NVPROF is profiling process 4167, command: python t15.py
Function: discount factor cumVest duration (seconds):0.37507891655
==4167== Profiling application: python t15.py
==4167== Profiling result:
   Start  Duration            Grid Size      Block Size     Regs*    SSMem*    DSMem*      Size  Throughput  SrcMemType  DstMemType           Device   Context    Stream  Name
193.92ms  6.2729ms                    -               -         -         -         -  15.259MB  2.3755GB/s    Pageable      Device  Quadro K2000 (0         1         7  [CUDA memcpy HtoD]
201.09ms  5.7101ms                    -               -         -         -         -  15.259MB  2.6096GB/s    Pageable      Device  Quadro K2000 (0         1         7  [CUDA memcpy HtoD]
364.92ms  842.49us          (15625 1 1)       (128 1 1)        13        0B        0B         -           -           -           -  Quadro K2000 (0         1         7  cudapy::__main__::__vectorized_cVestDiscount$242(Array<double, int=1, A, mutable, aligned>, Array<double, int=1, A, mutable, aligned>, Array<double, int=1, A, mutable, aligned>) [31]
365.77ms  7.1528ms                    -               -         -         -         -  15.259MB  2.0833GB/s      Device    Pageable  Quadro K2000 (0         1         7  [CUDA memcpy DtoH]

Regs: Number of registers used per CUDA thread. This number includes registers used internally by the CUDA driver and/or tools and can be more than what the compiler shows.
SSMem: Static shared memory allocated per CUDA block.
DSMem: Dynamic shared memory allocated per CUDA block.
SrcMemType: The type of source memory accessed by memory operation/copy
DstMemType: The type of destination memory accessed by memory operation/copy
$

Мы видим, что ваше приложение сообщило о времени выполнения около 1.244 секунд, тогда как версия векторизации сообщает о времени выполнения около 0,375 секунды. Но в обоих этих числах есть накладные расходы python. Если мы посмотрим на сгенерированную продолжительность ядра CUDA в профилировщике, разница будет еще более резкой. Мы видим, что исходное ядро занимало около 1.225 секунд, тогда как ядро векторизации выполняется примерно через 842 микросекунды (т.е. менее 1 миллисекунды). Мы также отмечаем, что время ядра вычислений намного больше, чем время, затрачиваемое на перенос 3 массивов в/из GPU (что составляет около 20 миллисекунд), и мы отмечаем, что размеры ядра теперь составляют 15625 блоков из 128 потоки каждый для общего количества потоков/работников 2000000, что точно соответствует суммарному количеству операций умножения, которые должны быть выполнены, и существенно больше, чем ничтожные 64 потока (и, возможно, действительно только 1 поток) в действии с вашим исходным кодом.

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

Но остается вопрос: как обрабатывать разнородные размеры входных массивов, как в исходной проблеме? Для этого я думаю, что нам нужно пойти на guvectorize (или, как указано в @talonmies, написать свое собственное ядро @cuda.jit, что, вероятно, лучший совет, несмотря на то, что ни один из этих подходов не сможет преодолеть накладные расходы на передачу данных в/с устройства, как уже упоминалось).

Чтобы решить эту проблему с помощью guvectorize, нам нужно более тщательно подумать о уже упомянутой концепции "срезания". Позвольте повторно написать ваше ядро guvectorize чтобы оно guvectorize только на "срезе" общих данных, а затем разрешало guvectorize запуска guvectorize нескольких работников для ее решения, один рабочий на срез.

В CUDA нам нравится иметь много рабочих; у вас действительно не может быть слишком много. Таким образом, это повлияет на то, как мы "нарезаем" наши массивы, чтобы дать возможность нескольким работникам действовать. Если бы мы срезали по 3-му (последнему, n) размеру, у нас было бы всего 5 срезов, поэтому максимум 5 работников. Точно так же, если мы countRow по первому или countRow размеру, у нас будет 100 ломтиков, поэтому максимум 100 рабочих. В идеале мы бы countCol по 2-му, или countCol размеру. Однако для простоты я буду countRow по первому или countRow размеру. Это явно неоптимально, но см. Ниже пример обработанного примера того, как вы могли бы приблизиться к проблеме нарезки на второй размер. Нарезка по первому измерению означает, что мы удалим первый цикл for из нашего ядра guvectorize и позволяем системе ufunc распараллеливаться вдоль этого измерения (в зависимости от размеров массивов, которые мы проходим). Код может выглядеть примерно так:

$ cat t16.py
import numpy as np
from numba import guvectorize
import time
from timeit import default_timer as timer


@guvectorize(['void(float64[:,:], float64[:,:], int64, int64, float64[:,:])'], '(m,o),(m,o),(),() -> (m,o)', target='cuda', nopython=True)
def cVestDiscount (multBy, discount, n, countCol, cv):
        for ID in range(0,countCol):
            for num in range(0,n):
                cv[ID][num] = multBy[ID][num] * discount[ID][num]

multBy = np.float64(np.arange(20000).reshape(4000,5))
discount = np.float64(np.arange(2000000).reshape(100,4000,5))
n = np.int64(5)
countCol = np.int64(4000)
cv = np.zeros(shape=(100,4000,5), dtype=np.float64)
func_start = timer()
cv = cVestDiscount(multBy, discount, n, countCol, cv)
timing=timer()-func_start
print("Function: discount factor cumVest duration (seconds):" + str(timing))
$ nvprof --print-gpu-trace python t16.py
==4275== NVPROF is profiling process 4275, command: python t16.py
Function: discount factor cumVest duration (seconds):0.0670170783997
==4275== Profiling application: python t16.py
==4275== Profiling result:
   Start  Duration            Grid Size      Block Size     Regs*    SSMem*    DSMem*      Size  Throughput  SrcMemType  DstMemType           Device   Context    Stream  Name
307.05ms  27.392us                    -               -         -         -         -  156.25KB  5.4400GB/s    Pageable      Device  Quadro K2000 (0         1         7  [CUDA memcpy HtoD]
307.79ms  5.9293ms                    -               -         -         -         -  15.259MB  2.5131GB/s    Pageable      Device  Quadro K2000 (0         1         7  [CUDA memcpy HtoD]
314.34ms  1.3440us                    -               -         -         -         -        8B  5.6766MB/s    Pageable      Device  Quadro K2000 (0         1         7  [CUDA memcpy HtoD]
314.54ms     896ns                    -               -         -         -         -        8B  8.5149MB/s    Pageable      Device  Quadro K2000 (0         1         7  [CUDA memcpy HtoD]
317.27ms  47.398ms              (2 1 1)        (64 1 1)        63        0B        0B         -           -           -           -  Quadro K2000 (0         1         7  cudapy::__main__::__gufunc_cVestDiscount$242(Array<double, int=3, A, mutable, aligned>, Array<double, int=3, A, mutable, aligned>, Array<__int64, int=1, A, mutable, aligned>, Array<__int64, int=1, A, mutable, aligned>, Array<double, int=3, A, mutable, aligned>) [35]
364.67ms  7.3799ms                    -               -         -         -         -  15.259MB  2.0192GB/s      Device    Pageable  Quadro K2000 (0         1         7  [CUDA memcpy DtoH]

Regs: Number of registers used per CUDA thread. This number includes registers used internally by the CUDA driver and/or tools and can be more than what the compiler shows.
SSMem: Static shared memory allocated per CUDA block.
DSMem: Dynamic shared memory allocated per CUDA block.
SrcMemType: The type of source memory accessed by memory operation/copy
DstMemType: The type of destination memory accessed by memory operation/copy
$

Замечания:

1. Изменения кода были связаны с удалением параметра countCol, удалением первого цикла for из ядра guvectorize и внесением соответствующих изменений в подпись функции, чтобы отразить это. Мы также изменили наши трехмерные функции в сигнатуре на двумерные. В конце концов, мы берем двумерный "срез" трехмерных данных и позволяем каждому работнику работать на срезе.

2. Размеры ядра, о которых сообщает профилировщик, теперь составляют 2 блока вместо 1. Это имеет смысл, потому что в оригинальной реализации действительно был представлен только один "срез", и поэтому нужен один рабочий и, следовательно, 1 поток (но numba spun up 1 threadblock из 64 потоков). В этой реализации есть 100 срезов, а numba выбрал 2 потока блоков из 64 рабочих/нитей для обеспечения 100 рабочих/потоков.

3. Производительность ядра, сообщенная профилировщиком 47,4 мс, теперь находится где-то между оригинальной версией (~ 1.224s) и массово-параллельной vectorize версией (в ~ 0,001 с). Таким образом, переход от 1 до 100 рабочих значительно ускорился, но есть больше возможностей для повышения производительности. Если вы countCol, как нарезать измерение countCol, вы, вероятно, можете приблизиться к версии vectorize, с точки зрения производительности (см. Ниже). Обратите внимание, что разница между тем, где мы находимся здесь (~ 47 мс) и версией векторизации (~ 1 мс), более чем достаточна, чтобы компенсировать дополнительную стоимость передачи (~ 5 мс или менее) передачи немного большей матрицы multBy в устройства, чтобы упростить простоту vectorize.

Некоторые дополнительные комментарии по времени python: я считаю, что точное поведение того, как python компилирует необходимые ядра для исходных, векторизованных и графических улучшенных версий, отличается. Если мы изменим код t15.py для запуска "разминки", то, по крайней мере, время синхронизации python будет согласованным, трендовым с общим временем стены и временем ядра:

$ cat t15.py
import numpy as np
from numba import guvectorize,vectorize
import time
from timeit import default_timer as timer


@vectorize(['float64(float64, float64)'], target='cuda')
def cVestDiscount (a, b):
    return a * b

multBy = np.float64(np.arange(20000).reshape(4000,5))
discount = np.float64(np.arange(2000000).reshape(100,4000,5))
multBy = np.full_like(discount, 1)
cv = np.empty_like(discount)
#warm-up run
cv = cVestDiscount(multBy, discount)
func_start = timer()
cv = cVestDiscount(multBy, discount)
timing=timer()-func_start
print("Function: discount factor cumVest duration (seconds):" + str(timing))
[bob@cluster2 python]$ time python t14.py
Function: discount factor cumVest duration (seconds):1.24376320839

real    0m2.522s
user    0m1.572s
sys     0m0.809s
$ time python t15.py
Function: discount factor cumVest duration (seconds):0.0228319168091

real    0m1.050s
user    0m0.473s
sys     0m0.445s
$ time python t16.py
Function: discount factor cumVest duration (seconds):0.0665760040283

real    0m1.252s
user    0m0.680s
sys     0m0.441s
$

Теперь, отвечая на вопрос в комментариях, эффективно: "Как бы я переделал проблему, чтобы отрезать по countCol 4000 (countCol или" средний ")?

Мы можем руководствоваться тем, что работало, чтобы срезать по первому измерению. Один из возможных подходов состоял бы в том, чтобы изменить форму массивов так, чтобы измерение 4000 было первым измерением, а затем удалило это, подобно тому, что мы делали в предыдущем обращении с guvectorize. Вот пример:

$ cat t17.py
import numpy as np
from numba import guvectorize
import time
from timeit import default_timer as timer


@guvectorize(['void(int64, float64[:], float64[:,:], int64, float64[:,:])'], '(),(o),(m,o),() -> (m,o)', target='cuda', nopython=True)
def cVestDiscount (countCol, multBy, discount, n, cv):
        for ID in range(0,countCol):
            for num in range(0,n):
                cv[ID][num] = multBy[num] * discount[ID][num]

countRow = np.int64(100)
multBy = np.float64(np.arange(20000).reshape(4000,5))
discount = np.float64(np.arange(2000000).reshape(4000,100,5))
n = np.int64(5)
countCol = np.int64(4000)
cv = np.zeros(shape=(4000,100,5), dtype=np.float64)
func_start = timer()
cv = cVestDiscount(countRow, multBy, discount, n, cv)
timing=timer()-func_start
print("Function: discount factor cumVest duration (seconds):" + str(timing))
[bob@cluster2 python]$ python t17.py
Function: discount factor cumVest duration (seconds):0.0266749858856
$ nvprof --print-gpu-trace python t17.py
==8544== NVPROF is profiling process 8544, command: python t17.py
Function: discount factor cumVest duration (seconds):0.0268459320068
==8544== Profiling application: python t17.py
==8544== Profiling result:
   Start  Duration            Grid Size      Block Size     Regs*    SSMem*    DSMem*      Size  Throughput  SrcMemType  DstMemType           Device   Context    Stream  Name
304.92ms  1.1840us                    -               -         -         -         -        8B  6.4437MB/s    Pageable      Device  Quadro K2000 (0         1         7  [CUDA memcpy HtoD]
305.36ms  27.392us                    -               -         -         -         -  156.25KB  5.4400GB/s    Pageable      Device  Quadro K2000 (0         1         7  [CUDA memcpy HtoD]
306.08ms  6.0208ms                    -               -         -         -         -  15.259MB  2.4749GB/s    Pageable      Device  Quadro K2000 (0         1         7  [CUDA memcpy HtoD]
312.44ms  1.0880us                    -               -         -         -         -        8B  7.0123MB/s    Pageable      Device  Quadro K2000 (0         1         7  [CUDA memcpy HtoD]
313.59ms  8.9961ms             (63 1 1)        (64 1 1)        63        0B        0B         -           -           -           -  Quadro K2000 (0         1         7  cudapy::__main__::__gufunc_cVestDiscount$242(Array<__int64, int=1, A, mutable, aligned>, Array<double, int=2, A, mutable, aligned>, Array<double, int=3, A, mutable, aligned>, Array<__int64, int=1, A, mutable, aligned>, Array<double, int=3, A, mutable, aligned>) [35]
322.59ms  7.2772ms                    -               -         -         -         -  15.259MB  2.0476GB/s      Device    Pageable  Quadro K2000 (0         1         7  [CUDA memcpy DtoH]

Regs: Number of registers used per CUDA thread. This number includes registers used internally by the CUDA driver and/or tools and can be more than what the compiler shows.
SSMem: Static shared memory allocated per CUDA block.
DSMem: Dynamic shared memory allocated per CUDA block.
SrcMemType: The type of source memory accessed by memory operation/copy
DstMemType: The type of destination memory accessed by memory operation/copy
$

Мы предсказуем, что время выполнения сократилось с ~ 47 мс, когда мы нарезали до 100 рабочих до ~ 9 мс, когда мы нарезаем 4000 рабочих. Аналогично, мы наблюдаем, что numba выбирает разворот 63 блоков из 64 потоков каждый для всего 4032 потоков, для обработки 4000 работников, необходимых для этой "нарезки".

Все еще не так быстро, как ядро vectorize 1 vectorize (которое имеет гораздо больше доступных параллельных "срезов" для рабочих), но довольно быстро, чем ядро 1.2s, предложенное в исходном вопросе. И общая настенная длина кода python примерно в 2 раза выше, даже при всех накладных расходах python.

В качестве окончательного замечания, повторите выражение, сделанное мной ранее (и похоже на заявления, сделанные в комментарии и в другом ответе):

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

Теперь у нас есть удобные тестовые примеры на t16.py или t17.py, с которыми мы могли бы работать, чтобы проверить это. Для простоты я выберу t16.py. Мы можем "преобразовать это обратно в код ЦП", просто удалив целевое обозначение из guvectorize ufunc:

$ cat t16a.py
import numpy as np
from numba import guvectorize
import time
from timeit import default_timer as timer


@guvectorize(['void(float64[:,:], float64[:,:], int64, int64, float64[:,:])'], '(m,o),(m,o),(),() -> (m,o)')
def cVestDiscount (multBy, discount, n, countCol, cv):
        for ID in range(0,countCol):
            for num in range(0,n):
                cv[ID][num] = multBy[ID][num] * discount[ID][num]

multBy = np.float64(np.arange(20000).reshape(4000,5))
discount = np.float64(np.arange(2000000).reshape(100,4000,5))
n = np.int64(5)
countCol = np.int64(4000)
cv = np.zeros(shape=(100,4000,5), dtype=np.float64)
func_start = timer()
cv = cVestDiscount(multBy, discount, n, countCol, cv)
timing=timer()-func_start
print("Function: discount factor cumVest duration (seconds):" + str(timing))
$ time python t16a.py
Function: discount factor cumVest duration (seconds):0.00657796859741

real    0m0.528s
user    0m0.474s
sys     0m0.047s
$

Таким образом, мы видим, что эта версия только для CPU запускает функцию примерно за 6 миллисекунд, и у нее нет "накладных расходов" на GPU, таких как инициализация CUDA и копирование данных в/из GPU. Общее время стены также является нашим лучшим измерением, примерно в 0,5 с по сравнению с примерно 1,0 с для нашего лучшего случая с графическим процессором. Таким образом, эта конкретная проблема из-за ее низкой арифметической интенсивности на один байт передачи данных, вероятно, не подходит для вычислений графических процессоров.