Czy lepiej jest używać std :: memcpy () czy std :: copy () ze względu na wydajność?

Czy lepiej jest używać, memcpyjak pokazano poniżej, czy lepiej jest używać std::copy()pod względem wydajności? Czemu?

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]);

Mam zamiar sprzeciwić się ogólnej mądrości, która std::copyspowoduje niewielką, prawie niezauważalną utratę wydajności. Właśnie wykonałem test i stwierdziłem, że to nieprawda: zauważyłem różnicę w wydajności. Jednak zwycięzcą był std::copy.

Napisałem implementację C ++ SHA-2. W moim teście haszuję 5 ciągów przy użyciu wszystkich czterech wersji SHA-2 (224, 256, 384, 512) i wykonuję pętlę 300 razy. Czasy mierzę za pomocą Boost.timer. Ten licznik pętli 300 wystarczy, aby całkowicie ustabilizować moje wyniki. Przeprowadzałem test 5 razy, na przemian z memcpywersją i std::copywersją. Mój kod korzysta z przechwytywania danych w jak największej liczbie fragmentów (wiele innych implementacji działa z char/ char *, podczas gdy ja operuję z T/ T *(gdzie Tjest największym typem w implementacji użytkownika, który ma prawidłowe zachowanie przepełnienia), więc szybki dostęp do pamięci na największe typy, jakie mogę, mają kluczowe znaczenie dla wydajności mojego algorytmu. Oto moje wyniki:

Czas (w sekundach) do ukończenia testów 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%

Całkowity średni wzrost szybkości std :: copy over memcpy: 2,99%

Mój kompilator to gcc 4.6.3 w Fedorze 16 x86_64. Moje flagi optymalizacji to -Ofast -march=native -funsafe-loop-optimizations.

Kod dla moich implementacji SHA-2.

Postanowiłem również przeprowadzić test na mojej implementacji MD5. Wyniki były znacznie mniej stabilne, więc zdecydowałem się zrobić 10 biegów. Jednak po kilku pierwszych próbach otrzymałem wyniki, które różniły się znacznie od jednego uruchomienia do drugiego, więc domyślam się, że miała miejsce jakaś aktywność systemu operacyjnego. Postanowiłem zacząć od nowa.

Te same ustawienia i flagi kompilatora. Jest tylko jedna wersja MD5 i jest szybsza niż SHA-2, więc zrobiłem 3000 pętli na podobnym zestawie 5 ciągów testowych.

Oto moje 10 ostatnich wyników:

Czas (w sekundach) do ukończenia testów 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%

Całkowity średni spadek prędkości std :: copy over memcpy: 0,11%

Kod mojej implementacji MD5

Te wyniki sugerują, że istnieje pewna optymalizacja, którą std :: copy wykorzystałem w moich testach SHA-2, std::copyktórej nie można było użyć w moich testach MD5. W testach SHA-2 obie tablice zostały utworzone w tej samej funkcji, która wywołała std::copy/ memcpy. W moich testach MD5 jedna z tablic została przekazana do funkcji jako parametr funkcji.

Zrobiłem trochę więcej testów, aby zobaczyć, co mogę zrobić, aby std::copyznowu przyspieszyć. Odpowiedź okazała się prosta: włącz optymalizację czasu łącza. Oto moje wyniki z włączonym LTO (opcja -flto w gcc):

Czas (w sekundach) do zakończenia wykonywania testów MD5 z opcją -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%

Całkowity średni wzrost szybkości std :: kopia nad memcpy: 0,72%

Podsumowując, nie wydaje się, aby korzystanie z niego miało wpływ na wydajność std::copy. W rzeczywistości wydaje się, że nastąpił wzrost wydajności.

Wyjaśnienie wyników

Dlaczego więc miałby std::copyzwiększyć wydajność?

Po pierwsze, nie spodziewałbym się, że będzie wolniej w przypadku jakiejkolwiek implementacji, o ile włączona jest optymalizacja inliningu. Wszystkie kompilatory działają agresywnie; jest to prawdopodobnie najważniejsza optymalizacja, ponieważ umożliwia wiele innych optymalizacji. std::copymoże (i podejrzewam, że wszystkie implementacje w świecie rzeczywistym tak robią) wykryć, że argumenty można w prosty sposób skopiować, a pamięć jest ułożona sekwencyjnie. Oznacza to, że w najgorszym przypadku, kiedy memcpyjest to legalne, nie std::copypowinno działać gorzej. Prosta implementacja std::copytego odracza, memcpypowinna spełniać kryteria twojego kompilatora „zawsze wstaw to przy optymalizacji pod kątem szybkości lub rozmiaru”.

Jednak std::copyzachowuje również więcej swoich informacji. Kiedy dzwonisz std::copy, funkcja zachowuje typy nienaruszone. memcpydziała na void *, który odrzuca prawie wszystkie przydatne informacje. Na przykład, jeśli przekażę tablicę std::uint64_t, kompilator lub implementator biblioteki może być w stanie skorzystać z 64-bitowego wyrównania z std::copy, ale może to być trudniejsze do zrobienia z memcpy. Wiele implementacji algorytmów, takich jak ten, działa najpierw na części niewyrównanej na początku zakresu, następnie na części wyrównanej, a następnie na części bez wyrównania na końcu. Jeśli wszystko jest na pewno wyrównane, kod staje się prostszy i szybszy, a predyktor rozgałęzień w procesorze będzie łatwiejszy do poprawienia.

Przedwczesna optymalizacja?

std::copyjest w interesującej pozycji. Spodziewam się, że nigdy nie będzie wolniejszy, memcpya czasem szybszy w przypadku każdego nowoczesnego kompilatora optymalizującego. Co więcej, wszystko, co możesz memcpy, możesz std::copy. memcpynie pozwala na nakładanie się zderzaków, podczas gdy std::copypodpory zachodzą na siebie w jednym kierunku (z std::copy_backwardzachodzeniem na drugi kierunek). memcpydziała tylko na wskaźnikach, std::copydziała na każdej iteratorów ( std::map, std::vector, std::deque, lub mój własny niestandardowy typ). Innymi słowy, powinieneś używać go tylko std::copywtedy, gdy chcesz skopiować fragmenty danych.

Wszystkie kompilatory, które znam, zastępują prosty std::copyelement a, memcpygdy jest to odpowiednie, a nawet lepiej, wektoryzują kopię, aby była jeszcze szybsza niż memcpy.

W każdym razie: profiluj i przekonaj się sam. Różne kompilatory będą robić różne rzeczy i jest całkiem możliwe, że nie zrobią dokładnie tego, o co prosisz.

Zobacz tę prezentację na temat optymalizacji kompilatora (pdf).

Oto, co robi GCC dla prostego std::copytypu POD.

#include <algorithm>

struct foo
{
  int x, y;    
};

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

Oto demontaż (tylko z -Ooptymalizacją), pokazujący wywołanie 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

Jeśli zmienisz podpis funkcji na

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

następnie memmovestaje się a memcpydla niewielkiej poprawy wydajności. Zauważ, że memcpysam będzie silnie wektoryzowany.

Zawsze należy używać std::copy, ponieważ memcpyogranicza się tylko w stylu C struktur POD, a kompilator może zastąpić wywołań std::copyze memcpyjeśli cele są w rzeczywistości POD.

Ponadto std::copymoże być używany z wieloma typami iteratorów, a nie tylko ze wskaźnikami. std::copyjest bardziej elastyczny, aby nie tracić wydajności i jest wyraźnym zwycięzcą.

Teoretycznie memcpymoże mieć niewielką , niezauważalną , nieskończenie małą przewagę wydajności, tylko dlatego, że nie ma takich samych wymagań jak std::copy. Ze strony podręcznika man memcpy:

Aby uniknąć przepełnienia, rozmiar tablic wskazywanych przez parametry docelowe i źródłowe powinien wynosić co najmniej liczbę bajtów i nie powinien się pokrywać (w przypadku nakładających się bloków pamięci bezpieczniejszym podejściem jest memmove).

Innymi słowy, memcpymoże zignorować możliwość nakładania się danych. (Przekazywanie nakładających się tablic do memcpyjest niezdefiniowanym zachowaniem). memcpyNie trzeba więc jawnie sprawdzać tego warunku, natomiast std::copymożna go używać, o ile OutputIteratorparametr nie znajduje się w zakresie źródłowym. Pamiętaj, że to nie to samo, co stwierdzenie, że zakres źródłowy i docelowy nie mogą się pokrywać.

Więc ponieważ std::copyma nieco inne wymagania, teoretycznie powinien być nieco (z ekstremalnym naciskiem na nieco ) wolniejszy, ponieważ prawdopodobnie sprawdzi nakładające się tablice C lub deleguje kopiowanie tablic C do memmove, który musi wykonać czek. Ale w praktyce Ty (i większość osób zajmujących się profilowaniem) prawdopodobnie nie zauważysz żadnej różnicy.

Oczywiście, jeśli nie pracujesz z POD , i tak nie możesz z niego korzystać memcpy.

Moja zasada jest prosta. Jeśli używasz C ++, preferuj biblioteki C ++, a nie C :)

Tylko niewielki dodatek: różnica prędkości między memcpy()i std::copy()może się znacznie różnić w zależności od tego, czy optymalizacje są włączone, czy wyłączone. Z g ++ 6.2.0 i bez optymalizacji memcpy()wyraźnie wygrywa:

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

Gdy optymalizacje są włączone ( -O3), wszystko znowu wygląda prawie tak samo:

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

Im większa tablica, tym mniej zauważalny jest efekt, ale nawet przy N=1000 memcpy()jest około dwa razy szybciej, gdy optymalizacje nie są włączone.

Kod źródłowy (wymaga testu porównawczego Google):

#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 */

Jeśli naprawdę potrzebujesz maksymalnej wydajności kopiowania (której możesz nie mieć), nie używaj żadnego z nich .

Istnieje wiele , że można zrobić, aby zoptymalizować kopiowania pamięci - nawet więcej, jeśli jesteś gotów do korzystania z wielu wątków / rdzeni dla niego. Zobacz na przykład:

Czego brakuje / nie jest optymalne w tej implementacji memcpy?

zarówno pytanie, jak i niektóre odpowiedzi mają sugerowane implementacje lub linki do implementacji.

Profilowanie pokazuje, że stwierdzenie: std::copy()jest zawsze tak szybkie, jak memcpy()lub szybciej jest fałszywe.

Mój system:

HP-Compaq-dx7500-Microtower 3.13.0-24-generic # 47-Ubuntu SMP piątek 2 maja 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU / Linux.

gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2

Kod (język: 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 () profile: main: 21: now: 1422969084: 04859 elapsed: 2650 us
std :: copy () profile: main: 27: now: 1422969084: 04862 elapsed: 2745 us
memcpy () elapsed 44 s std :: copy ( ) upłynęło 45 s

g ++ -O3 -o test_stdcopy test_stdcopy.cpp

memcpy () profile: main: 21: now: 1422969601: 04939 elapsed: 2385 us
std :: copy () profile: main: 28: now: 1422969601: 04941 elapsed: 2690 us
memcpy () elapsed 27 s std :: copy ( ) upłynęło 43 s

Red Alert zwrócił uwagę, że kod używa memcpy z tablicy do tablicy i std :: copy z tablicy do wektora. To może być powodem do szybszego memcpy.

Skoro jest

v.reserve (sizeof (arr1));

nie będzie różnicy w kopiowaniu do wektora lub tablicy.

Kod jest ustawiony tak, aby używał tablicy w obu przypadkach. memcpy jeszcze szybciej:

{
    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