¿Es mejor usar std :: memcpy () o std :: copy () en términos de rendimiento?

¿Es mejor usar memcpycomo se muestra a continuación o es mejor usar std::copy()en términos de rendimiento? ¿Por qué?

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

Voy a ir en contra de la sabiduría general aquí que std::copytendrá una pérdida de rendimiento leve, casi imperceptible. Acabo de hacer una prueba y descubrí que no era cierto: noté una diferencia de rendimiento. Sin embargo, el ganador fue std::copy.

Escribí una implementación de C ++ SHA-2. En mi prueba, combiné 5 cadenas con las cuatro versiones SHA-2 (224, 256, 384, 512) y realicé un bucle 300 veces. Mido los tiempos usando Boost.timer. Ese contador de 300 bucles es suficiente para estabilizar completamente mis resultados. Ejecuté la prueba 5 veces cada uno, alternando entre la memcpyversión y la std::copyversión. Mi código aprovecha la captura de datos en la mayor cantidad de fragmentos posible (muchas otras implementaciones operan con char/ char *, mientras que opero con T/ T *(donde Tes el tipo más grande en la implementación del usuario que tiene un comportamiento de desbordamiento correcto), por lo que el acceso a la memoria es rápido Los tipos más grandes que puedo son fundamentales para el rendimiento de mi algoritmo. Estos son mis resultados:

Tiempo (en segundos) para completar la ejecución de las pruebas 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%

Incremento promedio total en la velocidad de std :: copy over memcpy: 2.99%

Mi compilador es gcc 4.6.3 en Fedora 16 x86_64. Mis banderas de optimización son -Ofast -march=native -funsafe-loop-optimizations.

Código para mis implementaciones SHA-2.

Decidí ejecutar una prueba en mi implementación MD5 también. Los resultados fueron mucho menos estables, así que decidí hacer 10 carreras. Sin embargo, después de mis primeros intentos, obtuve resultados que variaron enormemente de una ejecución a la siguiente, así que supongo que estaba ocurriendo algún tipo de actividad del sistema operativo. Decidí comenzar de nuevo.

La misma configuración y banderas del compilador. Solo hay una versión de MD5, y es más rápida que SHA-2, así que hice 3000 bucles en un conjunto similar de 5 cadenas de prueba.

Estos son mis 10 resultados finales:

Tiempo (en segundos) para completar la ejecución de las pruebas 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%

Disminución promedio total en la velocidad de std :: copy over memcpy: 0.11%

Código para mi implementación MD5

Estos resultados sugieren que hay alguna optimización que std :: copy utilizada en mis pruebas SHA-2 que std::copyno podría usar en mis pruebas MD5. En las pruebas SHA-2, ambas matrices se crearon en la misma función que llamó a std::copy/ memcpy. En mis pruebas MD5, una de las matrices se pasó a la función como parámetro de función.

Hice un poco más de pruebas para ver qué podía hacer para std::copyacelerar de nuevo. La respuesta resultó ser simple: active la optimización del tiempo de enlace. Estos son mis resultados con LTO activado (opción -flto en gcc):

Tiempo (en segundos) para completar la ejecución de las pruebas MD5 con -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%

Incremento promedio total en la velocidad de std :: copy over memcpy: 0.72%

En resumen, no parece haber una penalización de rendimiento por usar std::copy. De hecho, parece haber una ganancia de rendimiento.

Explicación de resultados.

Entonces, ¿por qué podría std::copyaumentar el rendimiento?

Primero, no esperaría que fuera más lenta para ninguna implementación, siempre y cuando la optimización de inlining esté activada. Todos los compiladores están en línea agresivamente; posiblemente sea la optimización más importante porque permite muchas otras optimizaciones. std::copypuedo (y sospecho que todas las implementaciones del mundo real lo hacen) detectar que los argumentos son trivialmente copiables y que la memoria se presenta secuencialmente. Esto significa que en el peor de los casos, cuando memcpyes legal, no std::copydebería funcionar peor. La implementación trivial de std::copyeso difiere memcpydebe cumplir con los criterios de su compilador de "siempre alinear esto al optimizar la velocidad o el tamaño".

Sin embargo, std::copytambién guarda más de su información. Cuando llama std::copy, la función mantiene los tipos intactos. memcpyopera en void *, que descarta casi toda la información útil. Por ejemplo, si paso una matriz de std::uint64_t, el compilador o el implementador de la biblioteca pueden aprovechar la alineación de 64 bits std::copy, pero puede ser más difícil hacerlo memcpy. Muchas implementaciones de algoritmos como este funcionan trabajando primero en la porción no alineada al comienzo del rango, luego la porción alineada, luego la porción no alineada al final. Si se garantiza que todo está alineado, entonces el código se vuelve más simple y rápido, y más fácil para que el predictor de rama en su procesador sea correcto.

Optimización prematura?

std::copyEstá en una posición interesante. Espero que nunca sea más lento memcpyy a veces más rápido con cualquier compilador de optimización moderno. Además, todo lo que puedas memcpy, puedes std::copy. memcpyno permite ninguna superposición en las memorias intermedias, mientras que std::copyadmite la superposición en una dirección (con std::copy_backwardla otra dirección de superposición). memcpysolo funciona con punteros, std::copyfunciona en cualquier iteradores ( std::map, std::vector, std::deque, o mi propio tipo personalizado). En otras palabras, solo debes usar std::copycuando necesites copiar fragmentos de datos.

Todos los compiladores que conozco reemplazarán un simple std::copycon a memcpycuando sea apropiado, o incluso mejor, vectoricen la copia para que sea aún más rápido que a memcpy.

En cualquier caso: perfil y descúbrelo tú mismo. Diferentes compiladores harán diferentes cosas, y es muy posible que no haga exactamente lo que pides.

Vea esta presentación sobre optimizaciones del compilador (pdf).

Esto es lo que hace GCC para un simple std::copytipo de POD.

#include <algorithm>

struct foo
{
  int x, y;    
};

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

Aquí está el desmontaje (con solo -Ooptimización), que muestra la llamada a 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 cambia la firma de la función a

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

entonces se memmoveconvierte memcpyen una mejora leve en el rendimiento. Tenga en cuenta que memcpysí será fuertemente vectorizado.

Siempre use std::copyporque memcpyestá limitado solo a estructuras POD de estilo C, y el compilador probablemente reemplazará las llamadas std::copycon memcpysi los objetivos son de hecho POD.

Además, std::copyse puede usar con muchos tipos de iteradores, no solo punteros. std::copyes más flexible para no perder rendimiento y es el claro ganador.

En teoría, memcpypodría tener una ligera , imperceptible , infinitesimal , ventaja de rendimiento, solo porque no tiene los mismos requisitos que std::copy. De la página del manual de memcpy:

Para evitar desbordamientos, el tamaño de las matrices señaladas por los parámetros de destino y de origen debe ser al menos num bytes y no debe superponerse (para superponer bloques de memoria, memmove es un enfoque más seguro).

En otras palabras, memcpypuede ignorar la posibilidad de superposición de datos. (Pasar matrices superpuestas a memcpyes un comportamiento indefinido). Por memcpylo tanto, no es necesario verificar explícitamente esta condición, mientras que std::copypuede usarse siempre que el OutputIteratorparámetro no esté en el rango de origen. Tenga en cuenta que esto no es lo mismo que decir que el rango de origen y el rango de destino no pueden superponerse.

Entonces, dado que std::copytiene requisitos algo diferentes, en teoría debería ser un poco (con un énfasis extremo en un poco ) más lento, ya que probablemente comprobará la superposición de los arreglos en C o delegará la copia de los arreglos en C memmove, que debe realizar el cheque. Pero en la práctica, usted (y la mayoría de los perfiladores) probablemente ni siquiera detectarán ninguna diferencia.

Por supuesto, si no está trabajando con POD , no puede usarlo de memcpytodos modos.

Mi regla es simple. Si está utilizando C ++, prefiera las bibliotecas de C ++ y no C :)

Solo una pequeña adición: la diferencia de velocidad entre memcpy()y std::copy()puede variar bastante dependiendo de si las optimizaciones están habilitadas o deshabilitadas. Con g ++ 6.2.0 y sin optimizaciones memcpy()gana claramente:

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

Cuando las optimizaciones están habilitadas ( -O3), todo se ve casi igual de nuevo:

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

Cuanto más grande es la matriz, menos perceptible es el efecto, pero incluso N=1000 memcpy()es aproximadamente el doble de rápido cuando las optimizaciones no están habilitadas.

Código fuente (requiere 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 realmente necesita el máximo rendimiento de copia (que quizás no necesite), no use ninguno de ellos .

Hay una gran cantidad que se puede hacer para optimizar la copia de memoria - aún más si usted está dispuesto a utilizar múltiples hilos / núcleos para ello. Ver, por ejemplo:

¿Qué falta / subóptimo en esta implementación de memcpy?

Tanto la pregunta como algunas de las respuestas han sugerido implementaciones o enlaces a implementaciones.

La creación de perfiles muestra esa declaración: std::copy()siempre es tan rápido memcpy()o más rápido es falso.

Mi sistema:

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

gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2

El código (lenguaje: 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 () perfil: main: 21: ahora: 1422969084: 04859 transcurrido: 2650 us
std :: copy () perfil: main: 27: ahora: 1422969084: 04862 transcurrido: 2745 us
memcpy () transcurrido 44 s std :: copy ( ) transcurrieron 45 s

g ++ -O3 -o test_stdcopy test_stdcopy.cpp

memcpy () perfil: main: 21: ahora: 1422969601: 04939 transcurrido: 2385 us
std :: copy () perfil: main: 28: ahora: 1422969601: 04941 transcurrido: 2690 us
memcpy () transcurrido 27 s std :: copy ( ) transcurrieron 43 s

Red Alert señaló que el código usa memcpy de matriz a matriz y std :: copy de matriz a vector. Esa podría ser una razón para una memoria más rápida.

Ya que hay

v.reserve (sizeof (arr1));

no habrá diferencia en la copia al vector o matriz.

El código está arreglado para usar una matriz en ambos casos. memcpy aún más rápido:

{
    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