Я пытаюсь понять производительность чтения / записи инструкции clwb и проверить, как она изменяется в случае записи в строку кеша по сравнению с тем, когда я ее только читаю. Я ожидаю, что для случая записи затраченное время должно быть больше, чем для случая чтения. Чтобы проверить то же самое, вот небольшой фрагмент кода, который я запускаю на процессоре Intel Xeon (skylake) и использую энергонезависимую память (NVM) для хранилища чтения и записи.
/* nvm_alloc allocates memory on NVM */
uint64_t *array = (uint64_t *) nvm_alloc(pool, 512);
uint64_t *p = &array[0];
/* separated p & q by the size of write unit in Optane (256B) */
uint64_t *q = &array[32];
uint64_t time_1 = 0;
uint64_t time_2 = 0;
uint64_t start;
volatile uint64_t x;
for(int i = 0; i < 1000000; i++)
{
/* issues an mfence instruction */
mfence();
/* this is for the read case, bring p into cache */
/* commented read case */
//x = *p;
/* this is for the write case, update cacheline containing p */
*p = *p + 1;
*q = *q + 1;
/* rdtscp here to flush instruction pipeline */
start = rdtscp();
/* issue clwb on cacheline containing p */
clwb(p);
time_1 += rdtsc() - start;
start = rdtsc();
clwb(q);
time_2 += rdtsc() - start;
}
Поскольку clwb явно не вытесняет строку кэша, следующие итерации чтения, возможно, будут обслуживаться из самого кеша. В случае записи строка кэша модифицируется на каждой итерации, а затем выдается clwb для ее обратной записи. Однако время, затрачиваемое на запись, почти равно времени чтения, которое я не могу понять. Если время записи не включает время обратной записи грязной строки кэша в память (или контроллер памяти)
rdtsc
не упорядочен сclwb
как во время компиляции, так и во время выполнения. - person Hadi Brais   schedule 10.03.2020rdtsc
прочитать TSC доclwb
завершения, это бессмысленно, и вы даже не рассчитываетеclwb
выход на пенсию, не говоря уже о завершении всего пути до DRAM или где бы то ни было. Все, что вы рассчитываете, - это выполнение вне очередиrdtsc
после выдачиclwb
. И даже не потому, чтоrdtscp
только следит за выполнением предыдущих инструкций; он также не останавливает выполнение более поздних инструкций до того, как закончит считывание времени. А добавленный вами бит еще хуже: и start, и stop - это неупорядоченныеrdtsc
инструкции. Кроме того, зачем использовать два подрядrdtsc
? Просто прочтите время один раз - person Peter Cordes   schedule 10.03.2020frontend_retired.latency_ge_64
иmem_trans_retired.load_latency_gt_64
, которые могут сказать вам что-то для каждой инструкции даже во время OoO exec, но это очень ограничено.) - person Peter Cordes   schedule 10.03.2020clwb
инструкции, скорее всего, упорядочены относительно друг друга. Я заметил, что Clwb упорядочен относительно следующей операции записи в ту же строку кэша, которая дает поведение, подобное clflush, поэтому было бы не совсем правильно предполагать, что вы можете чередовать два clwbs. - person Ana Khorguani   schedule 24.03.2020