Est-il préférable d'utiliser std :: memcpy () ou std :: copy () en termes de performances?

Vaut-il mieux utiliser memcpycomme indiqué ci-dessous ou est-il préférable d'utiliser std::copy()en termes de performances? Pourquoi?

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

Je vais aller à l'encontre de la sagesse générale ici qui std::copyentraînera une légère perte de performance presque imperceptible. Je viens de faire un test et j'ai trouvé que c'était faux: j'ai remarqué une différence de performance. Cependant, le gagnant était std::copy.

J'ai écrit une implémentation C ++ SHA-2. Dans mon test, je hache 5 chaînes en utilisant les quatre versions SHA-2 (224, 256, 384, 512) et je boucle 300 fois. Je mesure les temps en utilisant Boost.timer. Ce compteur de 300 boucles suffit à stabiliser complètement mes résultats. J'ai effectué le test 5 fois chacun, en alternant entre la memcpyversion et la std::copyversion. Mon code tire parti de la saisie de données en aussi gros morceaux que possible (de nombreuses autres implémentations fonctionnent avec char/ char *, alors que j'opère avec T/ T *(où Test le plus grand type dans l'implémentation de l'utilisateur qui a un comportement de débordement correct), donc un accès mémoire rapide sur le les plus grands types possibles sont essentiels aux performances de mon algorithme. Voici mes résultats:

Temps (en secondes) pour terminer l'exécution des tests 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%

Augmentation moyenne totale de la vitesse de std :: copy sur memcpy: 2,99%

Mon compilateur est gcc 4.6.3 sur Fedora 16 x86_64. Mes indicateurs d'optimisation sont -Ofast -march=native -funsafe-loop-optimizations.

Code pour mes implémentations SHA-2.

J'ai décidé de tester également mon implémentation MD5. Les résultats étaient beaucoup moins stables, j'ai donc décidé de faire 10 courses. Cependant, après mes premières tentatives, j'ai obtenu des résultats qui variaient énormément d'une exécution à l'autre, donc je suppose qu'il y avait une sorte d'activité du système d'exploitation. J'ai décidé de recommencer.

Mêmes paramètres et indicateurs du compilateur. Il n'y a qu'une seule version de MD5, et c'est plus rapide que SHA-2, j'ai donc fait 3000 boucles sur un ensemble similaire de 5 chaînes de test.

Voici mes 10 derniers résultats:

Temps (en secondes) pour terminer l'exécution des tests 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%

Diminution moyenne totale de la vitesse de std :: copy sur memcpy: 0,11%

Code pour mon implémentation MD5

Ces résultats suggèrent qu'il existe une certaine optimisation que std :: copy utilisée dans mes tests SHA-2 qui std::copyn'a pas pu être utilisée dans mes tests MD5. Dans les tests SHA-2, les deux tableaux ont été créés dans la même fonction qui a appelé std::copy/memcpy . Dans mes tests MD5, l'un des tableaux a été transmis à la fonction en tant que paramètre de fonction.

J'ai fait un peu plus de tests pour voir ce que je pouvais faire pour std::copyaccélérer à nouveau. La réponse s'est avérée simple: activez l'optimisation du temps de liaison. Voici mes résultats avec LTO activé (option -flto dans gcc):

Temps (en secondes) pour terminer l'exécution des tests MD5 avec -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%

Augmentation moyenne totale de la vitesse de std :: copy sur memcpy: 0,72%

En résumé, il ne semble pas y avoir de pénalité de performance pour l'utilisation std::copy. En fait, il semble y avoir un gain de performance.

Explication des résultats

Alors, pourquoi pourrait-il std::copyaugmenter les performances?

Premièrement, je ne m'attendrais pas à ce qu'il soit plus lent pour une implémentation, tant que l'optimisation de l'inlining est activée. Tous les compilateurs en ligne de manière agressive; c'est peut-être l'optimisation la plus importante car elle permet de nombreuses autres optimisations. std::copypeut (et je soupçonne que toutes les implémentations du monde réel le font) détecter que les arguments sont trivialement copiables et que la mémoire est disposée séquentiellement. Cela signifie que dans le pire des cas, quand memcpyc'est légal, std::copyne devrait pas être pire. L'implémentation triviale de std::copyce report memcpydevrait répondre aux critères de votre compilateur de "toujours en ligne lors de l'optimisation de la vitesse ou de la taille".

Cependant, std::copyconserve également plus de ses informations. Lorsque vous appelez std::copy, la fonction conserve les types intacts. memcpyfonctionne void *, ce qui supprime presque toutes les informations utiles. Par exemple, si je passe dans un tableau de std::uint64_t, le compilateur ou l'implémenteur de la bibliothèque peut être en mesure de profiter de l'alignement 64 bits avec std::copy, mais il peut être plus difficile de le faire avec memcpy. De nombreuses implémentations d'algorithmes comme celui-ci fonctionnent en travaillant d'abord sur la partie non alignée au début de la plage, puis sur la partie alignée, puis sur la partie non alignée à la fin. S'il est garanti que tout est aligné, le code devient plus simple et plus rapide, et plus facile pour le prédicteur de branche de votre processeur à être correct.

Optimisation prématurée?

std::copyest dans une position intéressante. Je m'attends à ce qu'il ne soit jamais plus lent memcpyet parfois plus rapide avec n'importe quel compilateur d'optimisation moderne. De plus, tout ce que vous pouvez memcpy, vous le pouvez std::copy. memcpyne permet aucun chevauchement dans les tampons, alors que les std::copysupports se chevauchent dans un sens (avec std::copy_backwardpour l'autre sens de recouvrement). memcpyne fonctionne que sur des pointeurs, std::copyfonctionne sur tous les itérateurs ( std::map, std::vector, std::deque, ou mon propre type personnalisé). En d'autres termes, vous ne devriez l'utiliser que std::copylorsque vous avez besoin de copier des morceaux de données.

Tous les compilateurs que je connais remplaceront un simple std::copypar un memcpyquand c'est approprié, ou encore mieux, vectoriseront la copie pour qu'elle soit encore plus rapide qu'un memcpy.

Dans tous les cas: profilez et découvrez vous-même. Différents compilateurs feront des choses différentes, et il est fort possible qu'il ne fasse pas exactement ce que vous demandez.

Voir cette présentation sur les optimisations du compilateur (pdf).

Voici ce que fait GCC pour un simple std::copyde type POD.

#include <algorithm>

struct foo
{
  int x, y;    
};

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

Voici le démontage (avec seulement l' -Ooptimisation), montrant l'appel à 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

Si vous modifiez la signature de la fonction en

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

puis le memmovedevient un memcpypour une légère amélioration des performances. Notez que memcpylui - même sera fortement vectorisé.

Toujours utiliser std::copycar il memcpyest limité uniquement aux structures POD de style C, et le compilateur remplacera probablement les appels à std::copyparmemcpy si les cibles sont en fait POD.

De plus, std::copypeut être utilisé avec de nombreux types d'itérateurs, pas seulement avec des pointeurs. std::copyest plus flexible pour aucune perte de performance et est clairement le gagnant.

En théorie, memcpypourrait avoir une légère , imperceptible , infinitésimale , l' avantage de la performance, seulement parce qu'il n'a pas les mêmes exigences que std::copy. Depuis la page de manuel de memcpy:

Pour éviter les débordements, la taille des tableaux pointés par les paramètres de destination et de source doit être d'au moins nombre d'octets et ne doit pas se chevaucher (pour les blocs de mémoire qui se chevauchent, memmove est une approche plus sûre).

En d'autres termes, memcpypeut ignorer la possibilité de chevauchement des données. (Passer des tableaux qui memcpyse chevauchent à est un comportement indéfini.) Il memcpyn'est donc pas nécessaire de vérifier explicitement cette condition, alors qu'il std::copypeut être utilisé tant que le OutputIteratorparamètre n'est pas dans la plage source. Notez que ce n'est pas la même chose que de dire que la plage source et la plage de destination ne peuvent pas se chevaucher.

Donc, comme std::copyles exigences sont quelque peu différentes, en théorie, il devrait être légèrement (avec un accent extrême sur légèrement ) plus lent, car il vérifiera probablement le chevauchement des tableaux C, ou bien déléguera la copie des tableaux C àmemmove , qui doit effectuer le vérifier. Mais en pratique, vous (et la plupart des profileurs) ne détecterez probablement même aucune différence.

Bien sûr, si vous ne travaillez pas avec des POD , vous ne pouvez pas utiliser de memcpytoute façon.

Ma règle est simple. Si vous utilisez C ++, préférez les bibliothèques C ++ et non C :)

Juste un ajout mineur: la différence de vitesse entre memcpy()et std::copy()peut varier un peu selon que les optimisations sont activées ou désactivées. Avec g ++ 6.2.0 et sans optimisations memcpy()gagne clairement:

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

Lorsque les optimisations sont activées ( -O3), tout se ressemble à nouveau:

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

Plus le tableau est grand, moins l'effet est perceptible, mais même à N=1000 memcpy()est environ deux fois plus rapide lorsque les optimisations ne sont pas activées.

Code source (nécessite 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 */

Si vous avez vraiment besoin de performances de copie maximales (ce que vous pourriez ne pas avoir), n'utilisez aucun des deux .

Il y a beaucoup à faire pour optimiser la copie de mémoire - encore plus si vous êtes prêt à utiliser plusieurs threads / cœurs pour cela. Voir, par exemple:

Qu'est-ce qui manque / sous-optimal dans cette implémentation memcpy?

la question et certaines des réponses ont suggéré des implémentations ou des liens vers des implémentations.

Le profilage montre cette affirmation: std::copy()est toujours aussi rapide memcpy()ou plus rapide est faux.

Mon système:

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

gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2

Le code (langage: 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 () profil: main: 21: maintenant: 1422969084: 04859 écoulé: 2650 us
std :: copy () profil: main: 27: maintenant: 1422969084: 04862 écoulé: 2745 us
memcpy () écoulé 44 s std :: copy ( ) écoulé 45 s

g ++ -O3 -o test_stdcopy test_stdcopy.cpp

memcpy () profil: main: 21: maintenant: 1422969601: 04939 écoulé: 2385 us
std :: copy () profil: main: 28: maintenant: 1422969601: 04941 écoulé: 2690 us
memcpy () écoulé 27 s std :: copy ( ) écoulé 43 s

Red Alert a souligné que le code utilise memcpy de tableau en tableau et std :: copy de tableau en vecteur. Cela pourrait être une raison pour un memcpy plus rapide.

Puisqu'il y a

v.reserve (sizeof (arr1));

il ne doit y avoir aucune différence dans la copie vers le vecteur ou le tableau.

Le code est fixe pour utiliser un tableau dans les deux cas. memcpy encore plus vite:

{
    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