Почему копия for-loop не достигает максимальной пропускной способности CPU-RAM на одном ядре?

Ваш тест является предвзятым и содержит неопределенное поведение (упомянутое Саймоном Гоатером в комментариях), не говоря уже о том, что он не освобождает память.

Прежде всего, такие компиляторы, как GCC (v13.2), могут заменить ваш цикл на memmove (и даже, возможно, на memcpy). Фактически, GCC так и делает. Хорошая реализация memmove будет использовать невременное хранилище, поэтому нет записи-распределения строк кэша (т. е. строки кэша не загружаются из ОЗУ). Это означает, что в данном случае расчет пропускной способности неверен. Это должно быть 2*n*..., а не 3*n*.... В настоящее время я ожидаю, что все реализации x86-64 будут использовать вневременное хранилище при копировании больших массивов в памяти. Вот что происходит на моей машине (тестирование Debian с процессором i5-9600KF). Это видно в профилировщиках: функция __memmove_avx_unaligned_erms вызывается во время бенчмарка и занимает значительную часть общего времени (~50%).

Более того, ваш тест включает в себя накладные расходы на ошибки страниц. Действительно, malloc не сопоставляет виртуальные страницы напрямую с физическими в оперативной памяти. Это сопоставление выполняется лениво во время выполнения во время первого касания, то есть в середине теста. Это особенно дорого. Это можно увидеть с помощью низкоуровневого профилировщика: функция ядра clear_page_erms вызывается во время теста и занимает значительную часть общего времени (~45%).

Вдобавок ко всему, одно ядро ​​часто не может насытить память. Это связано с тем, что скорость доступа к памяти ограничена формулой concurent_accesses / latency. В частности, задержка при доступе к ОЗУ довольно велика, а буферы для одновременного доступа AFAIK часто недостаточно велики, чтобы насытить ОЗУ на большинстве основных платформ. По этой причине для насыщения оперативной памяти нередко требуется несколько ядер (1-3 часто бывает достаточно на обычных ПК x86-64).

Наконец, вам нужно быть осторожным с тем, как страницы сопоставляются с каким узлом NUMA в архитектуре NUMA. Разделение — это ключ, позволяющий избежать скрытых эффектов NUMA. AFAIK, процессоры AMD являются NUMA (из-за CCX/CCD, хотя на практике я не проверял).

Простое решение — использовать лучший тест, такой как Stream Triad (разработанный несколько десятилетий назад и до сих пор неплохой, если его правильно настроить).

В качестве альтернативы вы можете использовать следующий лучший тест:

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <string.h>
#include <sys/time.h>
#include <omp.h>

void __attribute__ ((noinline)) init(double* target, double* source, size_t size)
{
    #pragma omp parallel
    {
        const size_t start = (size * omp_get_thread_num()) / omp_get_num_threads();
        const size_t stop = (size * (omp_get_thread_num() + 1)) / omp_get_num_threads();
        memset(&source[start], 0, (stop - start) * sizeof(double));
        memset(&target[start], 0, (stop - start) * sizeof(double));
    }
}

void __attribute__ ((noinline)) benchmark_classical_stores(double* target, double* source, size_t size)
{
    // GCC generate a SIMD loop using classical load/store with OpenMP but not with a sequential code
    #pragma omp parallel for // Clause ignored by GCC: simd nontemporal(target)
    for (size_t i = 0; i < size; i++) {
        target[i] = source[i];
    }
}

void __attribute__ ((noinline)) benchmark_nt_stores(double* target, double* source, size_t size)
{
    #pragma omp parallel
    {
        const size_t start = (size * omp_get_thread_num()) / omp_get_num_threads();
        const size_t stop = (size * (omp_get_thread_num() + 1)) / omp_get_num_threads();
        memcpy(&target[start], &source[start], (stop - start) * sizeof(double));
    }
}

int main(int argc, char **argv)
{
    if (argc != 2) {
        printf("Usage: %s <BYTES>\n", argv[0]);
        return EXIT_FAILURE;
    }

    size_t n = atol(argv[1]) / sizeof(double);

    double *source = malloc(n * sizeof(double));
    double *target = malloc(n * sizeof(double));

    init(target, source, n);

    for (int j = 0; j < 10; ++j)
    {
        struct timeval tv1, tv2;
        gettimeofday(&tv1, NULL);

        benchmark_nt_stores(target, source, n);

        gettimeofday(&tv2, NULL);
        double duration = (double)(tv2.tv_usec - tv1.tv_usec) / 1e6 +
                          (double)(tv2.tv_sec - tv1.tv_sec);

        fprintf(stderr, "Bandwidth is %lf GB/s\n", 2 * n * sizeof(double) / duration / 1e9);

        fprintf(stderr, "%lf\n", target[0]);
    }

    free(source);
    free(target);
    return EXIT_SUCCESS;
}

Я получаю 37,9 ГиБ/с на своей машине для решения с использованием невременной записи и 41,2 ГиБ/с для решения с использованием классической загрузки/сохранения. Максимальная практическая пропускная способность моей (двухканальной) оперативной памяти (3200 МГц) составляет 42–43 ГиБ/с, а теоретическая пропускная способность — 47,7 ГиБ/с. Результаты хорошие, поскольку мой процессор i5-9600KF рассчитан на пропускную способность 38,7 ГиБ/с. Я думаю, что нетемпоральное хранилище приводит к более низкой пропускной способности из-за ограниченного параллелизма по сравнению с альтернативным решением (которое может извлечь выгоду из целого кеша).

Немного лучших результатов, безусловно, можно достичь с помощью огромных страниц (чтобы избежать промахов TLB) и выравниваемых загрузок (memcpy выполняет невыровненную загрузку на моей машине).

Обратите внимание, что насыщение оперативной памяти крайне сложно для процессоров, особенно когда нагрузки и хранилища смешаны (особенно невременные). Если вы достигаете >80% теоретической пропускной способности при смешанных чтениях/сохранениях, то можете считать, что код насыщает вашу память (>85% только для чтения).