Поиск различий между победителями и победителями AVX2

Я до сих пор не нашел проблему, но я видел некоторые вещи, которые вы могли бы изменить. Вы не проверяете возвращаемое значение _mm_malloc, хоть. Если это терпит неудачу, это объяснило бы это. (Может быть, он не любит выделять 32-байтовую выровненную память?)

Если вы выполняете свой код под проверкой памяти или чем-то еще, то, возможно, ему не нравится чтение из неинициализированной памяти для dispVals, (_mm256_maskstore_epi32 может считаться как чтение-изменение-запись, даже если маска является единичной.)

Запустите ваш код в отладчике и выясните, что происходит не так. «Ошибка времени выполнения» не очень значима.

_mm_set1* функции медленные. VPBROADCASTD нужен его источник в памяти или векторный регистр, а не регистр GP, поэтому компилятор может movd из GP reg в векторное reg и затем транслировать, или сохранить в памяти и затем транслировать. Во всяком случае, это было бы быстрее сделать

const __m256i add1 = _mm256_set1_epi32( 1 );
__m256i dvec = _mm256_setzero_si256();
for (d;d...;d++) {
dvec = _mm256_add_epi32(dvec, add1);
}

Другие вещи:
Это, вероятно, будет работать быстрее, если вы не сохраняете в памяти каждую итерацию внутреннего цикла. Используйте инструкцию смешивания (_mm256_blendv_epi8) или что-то в этом роде, чтобы обновить вектор (ы) смещений, которые соответствуют минимальным затратам. Смешать = замаскированное перемещение с регистром назначения.

Кроме того, ваши значения смещения должны соответствовать 16b целым числам, поэтому не расширяйте их до 32b, пока ПОСЛЕ того, как вы их не найдете. Процессоры Intel могут «на лету» расширять область памяти 16 байт в регистр gp без потери скорости (movsz так быстро, как mov), так проб. просто объявите свой dRPtr массив как uint16_t, Тогда вам вообще не понадобятся элементы расширения знака в вашем векторном коде (не говоря уже о вашем внутреннем цикле!). С надеждой _mm256_extracti128_si256( mask, 0 ) ничего не компилируется, поскольку желаемое 128 — это уже low128, так что просто используйте reg в качестве src для vmovsx, но до сих пор.

Вы также можете сохранить инструкцию (и uop для слитного домена), не загрузив сначала. (если компилятор не достаточно умен, чтобы не vmovdqu и использовать vpminuw с операндом памяти, даже если вы использовали встроенную нагрузку).

Вот я и думаю что-то вроде этого:

// totally untested, didn't even check that this compiles.
for(i) { for(j) {
// inner loop, compiler can hoist these constants.
const __m256i add1 = _mm256_set1_epi16( 1 );
__m256i dvec = _mm256_setzero_si256();
__m256i minCosts = _mm256_set1_epi16( MAXCOST );
__m256i minDisps = _mm256_setzero_si256();

for (int d=0 ; d < numDisp && j+d < cstep ;
d++, dvec = _mm256_add_epi16(dvec, add1))
{
__m256i newMinCosts = _mm256_min_epu16( minCosts, asPtr[(i*numDisp*cstep)+(d*cstep)+j]) );
__m256i mask   = _mm256_cmpgt_epi16( minCosts, newMinCosts );
minDisps = _mm256_blendv_epi8(minDisps, dvec, mask); // 2 uops, latency=2
minCosts = newMinCosts;
}

// put sign extension here if making dRPtr uint16_t isn't an option.
int index = (i*cstep)+j;
_mm256_storeu_si256 (dRPtr + index, __m256i minDisps);
}}

Вы можете получить лучшую производительность, имея две параллельные цепочки зависимостей: minCosts0 / minDisps0, а также minCosts1 / minDisps1и затем объединяя их в конце. minDisps является зависимостью, переносимой циклом, но цикл содержит только 5 инструкций (включая vpadd, который выглядит как накладные расходы цикла, но не может быть уменьшен при развертывании). Они декодируют до 6 мопов (blendv равно 2), плюс накладные расходы цикла. Он должен работать в 1,5 циклах / итерация (не считая накладных расходов цикла) на haswell, но цепочка dep будет ограничивать его одной итерацией на 2 цикла. (Предполагая развертывание, чтобы избавиться от накладных расходов цикла). Параллельное выполнение двух цепочек dep исправляет это и имеет тот же эффект, что и развертывание цикла: меньше накладных расходов цикла.

Хм, на самом деле на Haswell,

• pminuw может работать на p1 / p5. (и нагрузочная часть на p2 / p3)
• pcmpgtw может работать на p1 / p5
• vpblendvb 2 мопа для р5.
• padduw может работать на p1 / p5
• movdqa reg,reg может работать на p0 / p1 / p5 (и может вообще не нуждаться в исполнительном модуле). Развертывание должно избавить от любых накладных расходов для minCosts = newMinCosts, так как компилятор может просто в конечном итоге newMinCosts из последнего развернутого тела цикла в правом регистре для первого тела цикла следующей итерации.
• плавленый sub / jge (счетчик петель) может работать на p6. (с помощью PTEST + jcc на двек бы помедленнее). add/sub может работать на p0 / p1 / p5 / p6, если не соединен с jcc,

Итак, на самом деле цикл займет 2,5 цикла на итерацию, ограниченный инструкциями, которые могут выполняться только на p1 / p5. Развертывание на 2 или 4 уменьшит цикл / movdqa накладные расходы. Поскольку Haswell может выдавать 4 мопа за такт, он может более эффективно ставить в очередь мопы для выполнения не по порядку, поскольку цикл не будет иметь слишком большого числа итераций. (Ваш пример был 48.) Наличие большого количества мопов в очереди даст ЦП что-то делать после выхода из цикла, и сократит любые задержки из-за промахов в кеше и т. Д.

_mm256_min_epu16 (PMINUW) — еще одна цепочка зависимостей, переносимая циклами. Использование его с операндом памяти приводит к задержке в 3 или 4 цикла. Тем не менее, загрузочная часть инструкции может начаться, как только будет известен адрес, поэтому сложение нагрузки в модифицированном операторе, чтобы воспользоваться преимуществами микро-слияния, не делает депозвуковые цепочки длиннее или короче, чем при использовании отдельной загрузки.

Иногда вам нужно использовать отдельную загрузку для невыровненных данных (AVX убрал требование выравнивания для операндов памяти). Мы ограничены в большей степени единицами выполнения, чем лимит выдачи 4 мегапикселя / такт, поэтому, вероятно, хорошо использовать специальную инструкцию загрузки.

источник для портов / задержек insn.