OpenCL: long, long4, long16 ... когда использовать? - PullRequest
Новая
       14

OpenCL: long, long4, long16 ... когда использовать?

1 голос
/ 07 февраля 2012

Я пытаюсь понять разницу между работой с long, long2, long3, long4, long8, long16. Давайте предположим, что мой CL_DEVICE_PREFERRED_VECTOR_WIDTH_LONG равен 2.

Когда мне следует работать с long, long2, long3, long4, long8, long16? Предположим, что я хочу, чтобы мое ядро ​​XOR связало битовые векторы, скажем, длины 500.

  • Если используется long, мне нужно XOR ceil (500/64) = 8. long.
  • Если используется long2, мне нужно XOR ceil (500/128) = 4 long2.
  • Если используется long8, мне нужно XOR ceil (500/512) = 1 long8.

Так в чем же разница между xorring long [8], long2 [4] или long8? Есть ли какое-либо преимущество, выходящее за рамки CL_DEVICE_PREFERRED_VECTOR_WIDTH_LONG вообще?

Редактировать: я добавил небольшой пример сценария, чтобы сделать его более понятным: for (int j=0; j<8; j++) зацикливается на векторе длины 8, и я подумал, лучше ли мне сделать это для одного long8, четырех long2 с или восемь long с. 

while (i < to) {
    ui64[] row = rows[rowIndex];
    ui64 bitchange = i++;
    bitchange ^= i;
    rowIndex = 63-__builtin_clzll(bitchange);
    ui64 cardinality = 0;
    for (int j=0; j<8; j++) {
        curr[j] ^= row[j];
        cardinality += __builtin_popcountll(curr[j]);
    }
    popcountpolynomial[cardinality]++;
}

Ответы [ 2 ]

1 голос
/ 14 марта 2012

mfa корректно по всей предпочтительной ширине, но использование более широких векторов обычно хорошо. Устройство будет последовательно выдавать инструкции для обработки в самых широких форматах, которые оно поддерживает, что хорошо, поскольку помогает скрыть задержку операции. Это гораздо более верно для графических процессоров и гораздо менее верно для процессоров: графические процессоры обычно имеют много регистров (> 1000).

Думайте о предпочтительной ширине как о ширине, которая гарантирует, что вы не будете "тратить" векторные полосы на процессорах векторной архитектуры - если у графического процессора есть векторные ALU, выдает инструкции, которые не используют всю ширину (скажем, используйте только первый элемент в векторе), затем другие строки могут остаться неиспользованными в этой инструкции, что приведет к потере потенциальной вычислительной мощности. Подумайте о SSE, где он может делать 4 добавления с одной инструкцией, но в результате вы получите только одно число, потому что вы не используете 3 из 4 частей вектора.

Компиляторы OpenCL (на векторном оборудовании ALU) пытаются реструктурировать ваш код для «векторизации», если вы не используете полную векторную ширину, но, очевидно, существуют ограничения для этого.

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

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

Использование векторов может фактически уменьшить давление в регистре, если авто-векторизатору не удается найти векторизованное решение в скалярном коде, в случае, если аппаратное обеспечение использует вектор ALU - вы «потеряете» меньше векторных линий, потому что больше подойдет в каждом регистре.

1 голос
/ 07 февраля 2012

CL_DEVICE_PREFERRED_VECTOR_WIDTH_ (тип) для любого типа данных обычно является наиболее эффективным размером для доступа к памяти.Многие современные устройства с графическим процессором используют 128-битную структуру строки кэша, поэтому CL_DEVICE_PREFERRED_VECTOR_WIDTH_LONG часто оценивается как 2. Если вы используете long4, операция с памятью может быть разбита на две меньшие операции чтения / записи на устройстве - эффективно блокируя выполнение некоторых потоков,Я не думаю, что есть преимущество в использовании векторов больше, чем предпочтительный размер, но я могу представить себе недостаток.Вы должны сравнить его на своем устройстве, чтобы увидеть, верно ли это для вас.

Если единственная операция, которую вы выполняете, это XOR, я предлагаю использовать longN (N = предпочтительный размер) и 64-битную атомику, чтобы сделатьработа.Я надеюсь, что ваше устройство поддерживает 64-битную расширенную атомарность. (cl_khr_int64_extended_atomics)

...