Уменьшить косвенность в коде OCL

Что ж, если a и b статичны во время цикла, выполните:

kernel void krnl(global X* restrict x){ 
    const float* fast_l = x[a].y[b].z;
    const Y*     fast_r = x[a].y;
    for(int i = 0; i < 100; i++){
        fast_l[i] * fast_r[i].n;
    }
}

Для компилятора довольно типично не кэшировать глобальные операции чтения и записи, поскольку глобальные данные считаются очень изменчивыми (доступными для всех рабочих элементов). Ручное кэширование обычно помогает решить эти проблемы.

Однако умный компилятор должен догадаться, что вся эта косвенность — просто смещение указателя. Я не думаю, что в этом случае у вас будет какая-то выгода. Пример:

kernel void krnl(global X* restrict x){ 
    const float* off_l = ((float *)x)+sizeof(X)*a+sizeof(Y)*b+sizeof(int);
    const float* off_r = ((float *)x)+sizeof(X)*a;
    for(int i = 0; i < 100; i++){
        *(off_l+i)  *  *(off_r+sizeof(Y)*i);
    }
}

Вам нужно меньше косвенности, чтобы иметь меньше операций с памятью?

Это должно быть лучше для GPU:

typedef struct X
{
    Y y[MAXSIZE];
    int i;
} X;

скорее, чем

typedef struct X
{
    int i;
    Y y[MAXSIZE];
} X;

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

Если это работает, это:

typedef struct Y
{
    float z[MAXSIZE];
    float n;
} Y;

должно быть быстрее, особенно когда MAXSIZE является четным числом.

Разделение Y от i как двух отдельных массивов вместо массива объектов Y+i будет быстрее для GPU. То же самое для z и n в Y. Чистые массивы собственных элементов быстрее, особенно только тогда, когда одно из полей необходимо, а другое не нужно.

Добавление фиктивных чисел с плавающей запятой/целых в конце каждой структуры также может повлиять на производительность.

Наилучшая производительность требует параллелизма на уровне потоков и непрерывного чтения из памяти, в то время как объектно-ориентированный подход обеспечивает удобочитаемость, устойчивость и возможность обновления, но не переносимость, поскольку у некоторых аппаратных средств есть проблемы с выравниванием. Зачем загружать целое число с плавающей запятой z[MAXSIZE] из памяти, если вам нужно только z[i]? Потому что он находится в объекте. Если бы это был чистый массив, для получения z[i] потребовалась бы только 1 операция индексации. Загрузка поля объектов требует шага MAXSIZE в памяти, даже если он загружает только одно число с плавающей запятой, но версия чистого массива по вашему выбору заставит его шагать с размером 1 и достичь, возможно, оптимальной скорости.

Пример массива для z:

z[0]:  1st thread's z[0]
z[1]:  2nd thread's z[0]
z[2]:  3rd thread's z[0]
....
z[n]:  1st thread's z[1]
z[n+1]:  2nd thread's z[1]
z[n+3]:  3rd thread's z[1]
....

поэтому на каждом этапе

for(int i = 0; i < 100; i++)

gpu обращается к памяти без отверстий для всех z, что было бы намного быстрее, чем объектно-ориентированная версия imho.