Почему (x / y)[i] быстрее, чем x[i] / y[i]?

Я новичок в CuPy и вычислениях с использованием CUDA/GPU. Можете объяснить, почему (x / y)[i] быстрее, чем x[i] / y[i]?

При использовании ускоренных вычислений на GPU существуют ли какие-либо рекомендации, которые позволят мне быстро определить, какая операция быстрее? Как избежать необходимости тестировать каждую операцию.

# В Jupyter Notebook на VSCode

import cupy as cp
from cupyx.profiler import benchmark

x = cp.arange(1_000_000)
y = (cp.arange(1_000_000) + 1) / 2
i = cp.random.randint(2, size=1_000_000) == 0
x, y, i

# Результат:
(array([     0,      1,      2, ..., 999997, 999998, 999999], shape=(1000000,), dtype=int32),
 array([5.000000e-01, 1.000000e+00, 1.500000e+00, ..., 4.999990e+05,
        4.999995e+05, 5.000000e+05], shape=(1000000,), dtype=float64),
 array([ True, False,  True, ...,  True, False,  True], shape=(1000000,), dtype=bool))

def test1(x, y, i):
    return (x / y)[i]

def test2(x, y, i):
    return x[i] / y[i]

print(benchmark(test1, (x, y, i)))
print(benchmark(test2, (x, y, i)))

# Результат:
test1: CPU: 175.164 us +/- 61.250 (min: 125.200 / max: 765.100) us  GPU-0: 186.001 us +/- 67.314 (min: 134.144 / max: 837.568) us
test2: CPU: 342.364 us +/- 130.840 (min: 223.000 / max: 1277.600) us  GPU-0: 368.133 us +/- 136.911 (min: 225.504 / max: 1297.408) us

Соотношение арифметических возможностей и возможностей извлечения байтов на GPU (по крайней мере, возможно, и на CPU) обычно несбалансировано в пользу арифметических возможностей. Поэтому производительность алгоритмов часто можно предсказать по количеству требуемых операций памяти. Первый шаг в реализации x[i]/y[i] – создание x[i] и y[i], что является чисто операциями с памятью – компактизация потока. Затем происходит уменьшение уровня арифметики. В другой реализации сначала происходит более высокий уровень арифметики, за которым следует сокращение операций памяти на 50%.

Современный графический процессор для дата-центров, например, A100, может иметь ~10 ТФ производительности FP64 и ~2 ТБ/с полосы пропускания памяти, так что это соотношение составляет 5 FP64 FLOP на байт данных, прочитанных или записанных. Для 8-байтового FP64 значения это 40 FLOP на каждый FP64 значение, прочитанное или записанное. (Деление требует множества FLOP.)

Предположим, что массив i состоит на 50% из True и на 50% из False. Теперь давайте посчитаем все необходимые шаги.

В реализации x[i]/y[i] мы должны:

• прочитать весь массив i – 1,000,000 чтений.
• использовать его для чтения части массивов x и y, но на GPU вы не можете читать отдельные элементы. Вы читаете память порциями по 32 байта за раз, поэтому, если распределение True/False равномерное, вам может потребоваться прочитать весь массив x и y – 2,000,000 чтений
• сделать компактизацию потока для x, y в соответствии с i
• выполнить арифметическое деление – 500,000 операций деления.
• записать результаты – 500,000 записей

В реализации (x/y)[i]:

• прочитать весь массив i – 1,000,000 чтений.
• прочитать весь массив x и y – 2,000,000 чтений.
• выполнить арифметическое деление – 1,000,000 операций деления.
• сделать компактизацию потока для результата деления в соответствии с i
• записать результаты – 500,000 записей

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

На GPU, по крайней мере, FLOP часто значительно “дешевле”, чем чтение/запись данных.

Соотношение True/False в i не влияет на этот анализ для A100. Другие GPU, такие как T4, имеют относительно низкую производительность для FP64 по сравнению с FP32. T4 имеет соотношение 320 ГБ/с полосы пропускания памяти к ~8 ТФ производительности FP32, но только 1/8 ТФ или 125 ГФ производительности FP64. При высоком соотношении True к False это не будет иметь значения, но при низком соотношении True к False для T4 возможно, что стоимость деления становится фактором. Эта разница, вероятно, исчезнет при переходе к типу данных FP32. Другими словами, для FP64 операций T4 не обязательно удовлетворяет начальной предпосылке моего ответа: “Соотношение арифметической способности к возможности извлечения байтов на GPU (по крайней мере, возможно, и на CPU) обычно несбалансировано в пользу арифметической способности.”