Лучше использовать std :: memcpy () или std :: copy () с точки зрения производительности?

Лучше использовать, memcpyкак показано ниже, или лучше с std::copy()точки зрения производительности? Зачем?

char *bits = NULL;
...

bits = new (std::nothrow) char[((int *) copyMe->bits)[0]];
if (bits == NULL)
{
    cout << "ERROR Not enough memory.\n";
    exit(1);
}

memcpy (bits, copyMe->bits, ((int *) copyMe->bits)[0]);

Я собираюсь пойти против общей мудрости здесь, которая std::copyбудет иметь небольшую, почти незаметную потерю производительности. Я только что сделал тест и обнаружил, что это не соответствует действительности: я заметил разницу в производительности. Однако победителем стал std::copy.

Я написал реализацию C ++ SHA-2. В моем тесте я хэшировал 5 строк, используя все четыре версии SHA-2 (224, 256, 384, 512), и зацикливался 300 раз. Я измеряю время, используя Boost.timer. Этого счетчика 300 циклов достаточно, чтобы полностью стабилизировать мои результаты. Я запускал тест по 5 раз каждый, чередуя memcpyверсию и std::copyверсию. Мой код использует преимущества сбора данных как можно большим количеством фрагментов (многие другие реализации работают с char/ char *, тогда как я работаю с T/ T *(где Tсамый большой тип в пользовательской реализации, который имеет правильное поведение переполнения), поэтому быстрый доступ к памяти на Наибольшие типы, которые я могу, имеют решающее значение для производительности моего алгоритма. Вот мои результаты:

Время (в секундах) для завершения запуска тестов SHA-2

std::copy   memcpy  % increase
6.11        6.29    2.86%
6.09        6.28    3.03%
6.10        6.29    3.02%
6.08        6.27    3.03%
6.08        6.27    3.03%

Общее среднее увеличение скорости std :: copy over memcpy: 2,99%

Мой компилятор - gcc 4.6.3 на Fedora 16 x86_64. Мои флаги оптимизации есть -Ofast -march=native -funsafe-loop-optimizations.

Код для моих реализаций SHA-2.

Я решил провести тест на моей реализации MD5. Результаты были гораздо менее стабильными, поэтому я решил сделать 10 прогонов. Тем не менее, после моих первых нескольких попыток я получил результаты, которые сильно отличались от одного запуска к другому, поэтому я предполагаю, что происходила какая-то активность ОС. Я решил начать все сначала.

Те же настройки компилятора и флаги. Существует только одна версия MD5, и она быстрее, чем SHA-2, поэтому я сделал 3000 циклов на подобном наборе из 5 тестовых строк.

Вот мои последние 10 результатов:

Время (в секундах) до завершения теста MD5

std::copy   memcpy      % difference
5.52        5.56        +0.72%
5.56        5.55        -0.18%
5.57        5.53        -0.72%
5.57        5.52        -0.91%
5.56        5.57        +0.18%
5.56        5.57        +0.18%
5.56        5.53        -0.54%
5.53        5.57        +0.72%
5.59        5.57        -0.36%
5.57        5.56        -0.18%

Общее среднее снижение скорости std :: copy over memcpy: 0,11%

Код для моей реализации MD5

Эти результаты показывают, что есть некоторая оптимизация, которую std :: copy использовал в моих тестах SHA-2, которую std::copyнельзя было использовать в моих тестах MD5. В тестах SHA-2 оба массива были созданы в той же функции, которая вызвала std::copy/ memcpy. В моих тестах MD5 один из массивов был передан функции в качестве параметра функции.

Я провел немного больше тестов, чтобы увидеть, что я могу сделать, чтобы сделать std::copyбыстрее снова. Ответ оказался простым: включите оптимизацию времени ссылки. Это мои результаты с включенным LTO (опция -flto в gcc):

Время (в секундах) завершения теста MD5 с параметром -flto

std::copy   memcpy      % difference
5.54        5.57        +0.54%
5.50        5.53        +0.54%
5.54        5.58        +0.72%
5.50        5.57        +1.26%
5.54        5.58        +0.72%
5.54        5.57        +0.54%
5.54        5.56        +0.36%
5.54        5.58        +0.72%
5.51        5.58        +1.25%
5.54        5.57        +0.54%

Общее среднее увеличение скорости std :: copy over memcpy: 0.72%

Таким образом, за использование, похоже, не снижается производительность std::copy. На самом деле, похоже, увеличение производительности.

Объяснение результатов

Так почему же это может std::copyповысить производительность?

Во-первых, я не ожидал бы, что это будет медленнее для любой реализации, если включена оптимизация встраивания. Все компиляторы встраиваются агрессивно; это, возможно, самая важная оптимизация, поскольку она позволяет выполнять множество других оптимизаций. std::copyможет (и я подозреваю, что все реализации реального мира) обнаруживают, что аргументы легко копируются и что память распределяется последовательно. Это означает, что в худшем случае, когда memcpyэто законно, std::copyдолжно работать не хуже. Тривиальная реализация, от std::copyкоторой зависит, memcpyдолжна соответствовать критериям вашего компилятора «всегда вставляйте это при оптимизации для скорости или размера».

Тем не менее, std::copyтакже хранит больше своей информации. При вызове std::copyфункция сохраняет типы без изменений. memcpyоперирует void *, что отбрасывает практически всю полезную информацию. Например, если я передам массив std::uint64_t, компилятор или разработчик библиотеки могут воспользоваться преимуществами 64-разрядного выравнивания std::copy, но это может оказаться более сложным memcpy. Многие реализации алгоритмов, как эта, работают, сначала работая с невыровненной частью в начале диапазона, затем с выровненной частью, затем с невыровненной частью в конце. Если все это гарантированно выровнено, то код становится проще и быстрее, и предиктору ветвления в вашем процессоре становится проще.

Преждевременная оптимизация?

std::copyнаходится в интересной позиции. Я ожидаю, что это никогда не будет медленнее, memcpyа иногда и быстрее, с любым современным оптимизирующим компилятором. Более того, все, что вы можете memcpy, вы можете std::copy. memcpyне допускает никакого перекрытия в буферах, тогда как std::copyподдерживает перекрытие в одном направлении (с std::copy_backwardдругим направлением перекрытия). memcpyработает только на указатели, std::copyработает на любых итераторы ( std::map, std::vector, std::deque, или мой собственный пользовательский тип). Другими словами, вы должны просто использовать, std::copyкогда вам нужно скопировать куски данных вокруг.

Все известные мне компиляторы заменят простой std::copyна, memcpyкогда это уместно, или даже лучше, векторизируют копию, чтобы она была еще быстрее, чем a memcpy.

В любом случае: профиль и узнай сам. Разные компиляторы будут делать разные вещи, и вполне возможно, что они не будут делать именно то, что вы просите.

Смотрите эту презентацию по оптимизации компилятора (pdf).

Вот что делает GCC для простого std::copyтипа POD.

#include <algorithm>

struct foo
{
  int x, y;    
};

void bar(foo* a, foo* b, size_t n)
{
  std::copy(a, a + n, b);
}

Вот разборка (только с -Oоптимизацией), показывающая вызов memmove:

bar(foo*, foo*, unsigned long):
    salq    $3, %rdx
    sarq    $3, %rdx
    testq   %rdx, %rdx
    je  .L5
    subq    $8, %rsp
    movq    %rsi, %rax
    salq    $3, %rdx
    movq    %rdi, %rsi
    movq    %rax, %rdi
    call    memmove
    addq    $8, %rsp
.L5:
    rep
    ret

Если вы измените подпись функции на

void bar(foo* __restrict a, foo* __restrict b, size_t n)

затем memmoveстановится memcpyдля небольшого улучшения производительности. Обратите внимание, что memcpyсамо по себе будет сильно векторизовано.

Всегда использовать std::copyпотому , что memcpyограничивается только C-стиле POD структур, и компилятор, вероятно , заменить вызовы std::copyс , memcpyесли цели, на самом деле POD.

Кроме того, std::copyможет использоваться со многими типами итераторов, а не только с указателями. std::copyявляется более гибким без потери производительности и явным победителем.

Теоретически, memcpyможет иметь небольшое , незаметное , бесконечно малое преимущество в производительности, только потому, что оно не имеет тех же требований, что и std::copy. Со страницы руководства memcpy:

Чтобы избежать переполнений, размер массивов, на которые указывают параметры назначения и источника, должен составлять не менее num байтов и не должен перекрываться (для перекрывающихся блоков памяти memmove является более безопасным подходом).

Другими словами, memcpyможно игнорировать возможность перекрытия данных. (Передача перекрывающихся массивов memcpy- неопределенное поведение.) Поэтому memcpyнет необходимости явно проверять это условие, в то время как std::copyего можно использовать, если OutputIteratorпараметр не находится в исходном диапазоне. Обратите внимание, что это не то же самое, что сказать, что исходный диапазон и целевой диапазон не могут перекрываться.

Так как std::copyтребования к нему несколько иные, теоретически он должен быть немного (с чрезмерным акцентом на немного ) медленнее, поскольку он, вероятно, будет проверять наличие перекрывающихся C-массивов или делегировать копирование C-массивов memmove, что необходимо для выполнения чек. Но на практике вы (и большинство профилировщиков), вероятно, даже не обнаружите никакой разницы.

Конечно, если вы не работаете с POD , вы всеmemcpy равно не сможете их использовать .

Мое правило простое. Если вы используете C ++, предпочитайте библиотеки C ++, а не C :)

Небольшое дополнение: разница в скорости между memcpy()и std::copy()может варьироваться в зависимости от того, включена оптимизация или нет. С g ++ 6.2.0 и без оптимизаций memcpy()явно выигрывает:

Benchmark             Time           CPU Iterations
---------------------------------------------------
bm_memcpy            17 ns         17 ns   40867738
bm_stdcopy           62 ns         62 ns   11176219
bm_stdcopy_n         72 ns         72 ns    9481749

Когда оптимизация включена ( -O3), все выглядит примерно так же:

Benchmark             Time           CPU Iterations
---------------------------------------------------
bm_memcpy             3 ns          3 ns  274527617
bm_stdcopy            3 ns          3 ns  272663990
bm_stdcopy_n          3 ns          3 ns  274732792

Чем больше массив, тем менее заметен эффект, но даже в N=1000 memcpy()два раза быстрее, когда оптимизация не включена.

Исходный код (требуется Google Benchmark):

#include <string.h>
#include <algorithm>
#include <vector>
#include <benchmark/benchmark.h>

constexpr int N = 10;

void bm_memcpy(benchmark::State& state)
{
  std::vector<int> a(N);
  std::vector<int> r(N);

  while (state.KeepRunning())
  {
    memcpy(r.data(), a.data(), N * sizeof(int));
  }
}

void bm_stdcopy(benchmark::State& state)
{
  std::vector<int> a(N);
  std::vector<int> r(N);

  while (state.KeepRunning())
  {
    std::copy(a.begin(), a.end(), r.begin());
  }
}

void bm_stdcopy_n(benchmark::State& state)
{
  std::vector<int> a(N);
  std::vector<int> r(N);

  while (state.KeepRunning())
  {
    std::copy_n(a.begin(), N, r.begin());
  }
}

BENCHMARK(bm_memcpy);
BENCHMARK(bm_stdcopy);
BENCHMARK(bm_stdcopy_n);

BENCHMARK_MAIN()

/* EOF */

Если вам действительно нужна максимальная производительность копирования (чего у вас нет), не используйте ни одну из них .

Можно многое сделать для оптимизации копирования памяти - даже больше, если вы хотите использовать для этого несколько потоков / ядер. Смотрите, например:

Чего не хватает / неоптимально в этой реализации memcpy?

и вопрос, и некоторые ответы предложили варианты реализации или ссылки на реализации.

Профилирование показывает это утверждение: std::copy()всегда так быстро, как memcpy()или быстрее, ложно.

Моя система:

HP-Compaq-dx7500-Microtower 3.13.0-24-generic # 47-Ubuntu SMP пт 2 мая 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU / Linux.

gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2

Код (язык: c ++):

    const uint32_t arr_size = (1080 * 720 * 3); //HD image in rgb24
    const uint32_t iterations = 100000;
    uint8_t arr1[arr_size];
    uint8_t arr2[arr_size];
    std::vector<uint8_t> v;

    main(){
        {
            DPROFILE;
            memcpy(arr1, arr2, sizeof(arr1));
            printf("memcpy()\n");
        }

        v.reserve(sizeof(arr1));
        {
            DPROFILE;
            std::copy(arr1, arr1 + sizeof(arr1), v.begin());
            printf("std::copy()\n");
        }

        {
            time_t t = time(NULL);
            for(uint32_t i = 0; i < iterations; ++i)
                memcpy(arr1, arr2, sizeof(arr1));
            printf("memcpy()    elapsed %d s\n", time(NULL) - t);
        }

        {
            time_t t = time(NULL);
            for(uint32_t i = 0; i < iterations; ++i)
                std::copy(arr1, arr1 + sizeof(arr1), v.begin());
            printf("std::copy() elapsed %d s\n", time(NULL) - t);
        }
    }

g ++ -O0 -o test_stdcopy test_stdcopy.cpp

memcpy () профиль: главный: 21: сейчас: 1422969084: 04859 истек: 2650 us
std :: copy () профиль: main: 27: сейчас: 1422969084: 04862 истек: 2745 us
memcpy () истек 44 s std :: copy ( ) прошло 45 с

g ++ -O3 -o test_stdcopy test_stdcopy.cpp

memcpy () профиль: главный: 21: сейчас: 1422969601: истек 04939: 2385 us
std :: copy () профиль: main: 28: сейчас: 1422969601: 04941 истек: 2690 us
memcpy () прошло 27 с std :: copy ( ) прошло 43 с

Red Alert указал, что код использует memcpy из массива в массив и std :: copy из массива в вектор. Это может быть причиной для более быстрого memcpy.

Так как есть

v.reserve (SizeOf (arr1));

не должно быть никакой разницы в копировании в вектор или массив.

Код исправлен для использования массива в обоих случаях. memcpy еще быстрее:

{
    time_t t = time(NULL);
    for(uint32_t i = 0; i < iterations; ++i)
        memcpy(arr1, arr2, sizeof(arr1));
    printf("memcpy()    elapsed %ld s\n", time(NULL) - t);
}

{
    time_t t = time(NULL);
    for(uint32_t i = 0; i < iterations; ++i)
        std::copy(arr1, arr1 + sizeof(arr1), arr2);
    printf("std::copy() elapsed %ld s\n", time(NULL) - t);
}

memcpy()    elapsed 44 s
std::copy() elapsed 48 s