Поддерживают ли нынешние архитектуры x86 невременные нагрузки (из «обычной» памяти)?

Мне известно о множестве вопросов по этой теме, однако я не видел ни четких ответов, ни каких-либо контрольных измерений. Таким образом, я создал простую программу, которая работает с двумя массивами целых чисел. Первый массив a очень большой (64 МБ) и второй массив b мал, чтобы поместиться в кэш L1. Программа перебирает a и добавляет свои элементы к соответствующим элементам b в модульном смысле (когда конец b программа запускается с начала снова). Измеренное количество пропусков кэша L1 для разных размеров b как следует:

Измерения проводились на процессоре типа Xeon E5 2680v3 Haswell с кэшем данных L1 32 КБ. Поэтому во всех случаях b встроен в кэш L1. Тем не менее, количество промахов значительно выросло примерно на 16 КБ b след памяти. Этого можно ожидать, так как нагрузки обоих a а также b вызывает аннулирование строк кэша с начала b с этой точки зрения.

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

Мой контрольный код выглядит следующим образом (показан вариант без временной выборки):

int main(int argc, char* argv[])
{
uint64_t* a;
const uint64_t a_bytes = 64 * 1024 * 1024;
const uint64_t a_count = a_bytes / sizeof(uint64_t);
posix_memalign((void**)(&a), 64, a_bytes);

uint64_t* b;
const uint64_t b_bytes = atol(argv[1]) * 1024;
const uint64_t b_count = b_bytes / sizeof(uint64_t);
posix_memalign((void**)(&b), 64, b_bytes);

__m256i ones = _mm256_set1_epi64x(1UL);
for (long i = 0; i < a_count; i += 4)
_mm256_stream_si256((__m256i*)(a + i), ones);

// load b into L1 cache
for (long i = 0; i < b_count; i++)
b[i] = 0;

int papi_events[1] = { PAPI_L1_DCM };
long long papi_values[1];
PAPI_start_counters(papi_events, 1);

uint64_t* a_ptr = a;
const uint64_t* a_ptr_end = a + a_count;
uint64_t* b_ptr = b;
const uint64_t* b_ptr_end = b + b_count;

while (a_ptr < a_ptr_end) {
#ifndef NTLOAD
__m256i aa = _mm256_load_si256((__m256i*)a_ptr);
#else
__m256i aa = _mm256_stream_load_si256((__m256i*)a_ptr);
#endif
__m256i bb = _mm256_load_si256((__m256i*)b_ptr);
bb = _mm256_add_epi64(aa, bb);
_mm256_store_si256((__m256i*)b_ptr, bb);

a_ptr += 4;
b_ptr += 4;
if (b_ptr >= b_ptr_end)
b_ptr = b;
}

PAPI_stop_counters(papi_values, 1);
std::cout << "L1 cache misses: " << papi_values[0] << std::endl;

free(a);
free(b);
}

Что меня интересует, так это то, поддерживают ли производители процессоров поддержку или не поддерживают временную загрузку / предварительную выборку, или каким-либо другим способом пометить некоторые данные как не удерживаемые в кеше (например, пометить их как LRU). Существуют ситуации, например, в HPC, где подобные сценарии распространены на практике. Например, в разреженных итерационных линейных решателях / собственных решениях матричные данные обычно очень велики (больше, чем объемы кэша), но векторы иногда достаточно малы, чтобы поместиться в кэш L3 или даже L2. Затем мы хотели бы сохранить их там любой ценой. К сожалению, загрузка матричных данных может привести к аннулированию особенно строк x-векторного кэша, хотя в каждой итерации решателя матричные элементы используются только один раз, и нет никакой причины сохранять их в кэше после их обработки.

ОБНОВИТЬ

Я только что провел аналогичный эксперимент на Intel Xeon Phi KNC, пока измерял время выполнения вместо пропусков L1 (я не нашел способа, как надежно их измерять; PAPI и VTune дали странные метрики.) Результаты здесь:

Оранжевая кривая представляет обычные нагрузки и имеет ожидаемую форму. Синяя кривая представляет нагрузки с так называемой подсказкой о выселении (EH), установленной в префиксе инструкции, а серая кривая представляет случай, когда каждая строка кэша a был вручную выселен; оба эти трюка, включенные KNC, очевидно, работали так, как мы хотели для b более 16 КБ. Код измеряемой петли следующий:

while (a_ptr < a_ptr_end) {
#ifdef NTLOAD
__m512i aa = _mm512_extload_epi64((__m512i*)a_ptr,
_MM_UPCONV_EPI64_NONE, _MM_BROADCAST64_NONE, _MM_HINT_NT);
#else
__m512i aa = _mm512_load_epi64((__m512i*)a_ptr);
#endif
__m512i bb = _mm512_load_epi64((__m512i*)b_ptr);
bb = _mm512_or_epi64(aa, bb);
_mm512_store_epi64((__m512i*)b_ptr, bb);

#ifdef EVICT
_mm_clevict(a_ptr, _MM_HINT_T0);
#endif

a_ptr += 8;
b_ptr += 8;
if (b_ptr >= b_ptr_end)
b_ptr = b;
}

ОБНОВЛЕНИЕ 2

На Xeon Phi, icpc генерируется для варианта с нормальной нагрузкой (оранжевая кривая) для предварительной выборки для a_ptr:

400e93:       62 d1 78 08 18 4c 24    vprefetch0 [r12+0x80]

Когда я вручную (путем шестнадцатеричного редактирования исполняемого файла) изменил это так:

400e93:       62 d1 78 08 18 44 24    vprefetchnta [r12+0x80]

Я получил желаемые результаты, даже лучше, чем сине-серые кривые. Тем не менее, я не смог заставить компилятор генерировать невременные prefetchnig для меня, даже используя #pragma prefetch a_ptr:_MM_HINT_NTA до цикла 🙁