En C ++, ¿debería molestarme en almacenar en caché las variables o dejar que el compilador haga la optimización? (Aliasing)

Considere el siguiente código ( pes de tipo unsigned char*y bitmap->widthes de algún tipo entero, exactamente que se desconoce y depende de la versión de alguna biblioteca externa que estemos usando):

for (unsigned x = 0;  x < static_cast<unsigned>(bitmap->width);  ++x)
{
    *p++ = 0xAA;
    *p++ = 0xBB;
    *p++ = 0xCC;
}

_{¿Vale la pena optimizarlo [..]}

¿Podría haber un caso en el que esto pudiera producir resultados más eficientes escribiendo:

unsigned width(static_cast<unsigned>(bitmap->width));
for (unsigned x = 0;  x < width;  ++x)
{
    *p++ = 0xAA;
    *p++ = 0xBB;
    *p++ = 0xCC;
}

... o es esto trivial para que el compilador lo optimice?

_{¿Qué consideraría un código "mejor"?}

_{Nota del editor (Ike): para aquellos que se preguntan sobre el texto tachado, la pregunta original, tal como está redactada, estaba peligrosamente cerca de un territorio fuera del tema y estaba muy cerca de cerrarse a pesar de los comentarios positivos. Estos han sido eliminados. Sin embargo, no castigue a quienes respondieron que abordaron estas secciones afectadas de la pregunta.}

A primera vista, pensé que el compilador podría generar un ensamblado equivalente para ambas versiones con los indicadores de optimización activados. Cuando lo revisé, me sorprendió ver el resultado:

Fuente unoptimized.cpp

nota: este código no debe ejecutarse.

struct bitmap_t
{
    long long width;
} bitmap;

int main(int argc, char** argv)
{
    for (unsigned x = 0 ; x < static_cast<unsigned>(bitmap.width) ; ++x)
    {
        argv[x][0] = '\0';
    }
    return 0;
}

Fuente optimized.cpp

nota: este código no debe ejecutarse.

struct bitmap_t
{
    long long width;
} bitmap;

int main(int argc, char** argv)
{
    const unsigned width = static_cast<unsigned>(bitmap.width);
    for (unsigned x = 0 ; x < width ; ++x)
    {
        argv[x][0] = '\0';
    }
    return 0;
}

Compilacion

• $ g++ -s -O3 unoptimized.cpp
• $ g++ -s -O3 optimized.cpp

Montaje (no optimizado)

    .file   "unoptimized.cpp"
    .text
    .p2align 4,,15
.globl main
    .type   main, @function
main:
.LFB0:
    .cfi_startproc
    .cfi_personality 0x3,__gxx_personality_v0
    movl    bitmap(%rip), %eax
    testl   %eax, %eax
    je  .L2
    xorl    %eax, %eax
    .p2align 4,,10
    .p2align 3
.L3:
    mov %eax, %edx
    addl    $1, %eax
    movq    (%rsi,%rdx,8), %rdx
    movb    $0, (%rdx)
    cmpl    bitmap(%rip), %eax
    jb  .L3
.L2:
    xorl    %eax, %eax
    ret
    .cfi_endproc
.LFE0:
    .size   main, .-main
.globl bitmap
    .bss
    .align 8
    .type   bitmap, @object
    .size   bitmap, 8
bitmap:
    .zero   8
    .ident  "GCC: (GNU) 4.4.7 20120313 (Red Hat 4.4.7-16)"
    .section    .note.GNU-stack,"",@progbits

Montaje (optimizado.s)

    .file   "optimized.cpp"
    .text
    .p2align 4,,15
.globl main
    .type   main, @function
main:
.LFB0:
    .cfi_startproc
    .cfi_personality 0x3,__gxx_personality_v0
    movl    bitmap(%rip), %eax
    testl   %eax, %eax
    je  .L2
    subl    $1, %eax
    leaq    8(,%rax,8), %rcx
    xorl    %eax, %eax
    .p2align 4,,10
    .p2align 3
.L3:
    movq    (%rsi,%rax), %rdx
    addq    $8, %rax
    cmpq    %rcx, %rax
    movb    $0, (%rdx)
    jne .L3
.L2:
    xorl    %eax, %eax
    ret
    .cfi_endproc
.LFE0:
    .size   main, .-main
.globl bitmap
    .bss
    .align 8
    .type   bitmap, @object
    .size   bitmap, 8
bitmap:
    .zero   8
    .ident  "GCC: (GNU) 4.4.7 20120313 (Red Hat 4.4.7-16)"
    .section    .note.GNU-stack,"",@progbits

diff

$ diff -uN unoptimized.s optimized.s
--- unoptimized.s   2015-11-24 16:11:55.837922223 +0000
+++ optimized.s 2015-11-24 16:12:02.628922941 +0000
@@ -1,4 +1,4 @@
-   .file   "unoptimized.cpp"
+   .file   "optimized.cpp"
    .text
    .p2align 4,,15
 .globl main
@@ -10,16 +10,17 @@
    movl    bitmap(%rip), %eax
    testl   %eax, %eax
    je  .L2
+   subl    $1, %eax
+   leaq    8(,%rax,8), %rcx
    xorl    %eax, %eax
    .p2align 4,,10
    .p2align 3
 .L3:
-   mov %eax, %edx
-   addl    $1, %eax
-   movq    (%rsi,%rdx,8), %rdx
+   movq    (%rsi,%rax), %rdx
+   addq    $8, %rax
+   cmpq    %rcx, %rax
    movb    $0, (%rdx)
-   cmpl    bitmap(%rip), %eax
-   jb  .L3
+   jne .L3
 .L2:
    xorl    %eax, %eax
    ret

El ensamblado generado para la versión optimizada realmente carga ( lea) la widthconstante a diferencia de la versión no optimizada que calcula el widthdesplazamiento en cada iteración ( movq).

Cuando tenga tiempo, eventualmente publico algún punto de referencia sobre eso. Buena pregunta.

En realidad, no hay información suficiente de su fragmento de código para poder decirlo, y lo único en lo que puedo pensar es en el alias. Desde nuestro punto de vista, es bastante claro que no desea py bitmapque apuntan a la misma ubicación en la memoria, pero el compilador no sabe que y (porque pes de tipo char*) el compilador tiene que hacer este trabajo código incluso si py bitmapsuperposición.

Esto significa en este caso que si el bucle cambia a bitmap->widthtravés del puntero, pentonces debe verse cuando se vuelva a leer bitmap->widthmás adelante, lo que a su vez significa que almacenarlo en una variable local sería ilegal.

Dicho esto, creo que algunos compiladores generarán a veces dos versiones del mismo código (he visto evidencia circunstancial de esto, pero nunca busqué directamente información sobre lo que está haciendo el compilador en este caso), y verificará rápidamente si los punteros alias y ejecute el código más rápido si determina que está bien.

Dicho esto, mantengo mi comentario sobre simplemente medir el rendimiento de las dos versiones, mi dinero está en no ver ninguna diferencia de rendimiento constante entre las dos versiones del código.

En mi opinión, preguntas como estas están bien si su propósito es aprender sobre las teorías y técnicas de optimización del compilador, pero es una pérdida de tiempo (una micro-optimización inútil) si su objetivo final aquí es hacer que el programa se ejecute más rápido.

Bien, chicos, he medido con GCC -O3(usando GCC 4.9 en Linux x64).

¡Resulta que la segunda versión funciona un 54% más rápido!

Entonces, supongo que el uso de alias es lo importante, no lo había pensado.

[Editar]

Probé de nuevo la primera versión con todos los punteros definidos con __restrict__y los resultados son los mismos. Extraño ... O el alias no es el problema o, por alguna razón, el compilador no lo optimiza bien incluso con __restrict__.

[Editar 2]

Ok, creo que pude demostrar que el problema es el alias. Repetí mi prueba original, esta vez usando una matriz en lugar de un puntero:

const std::size_t n = 0x80000000ull;
bitmap->width = n;
static unsigned char d[n*3];
std::size_t i=0;
for (unsigned x = 0;  x < static_cast<unsigned>(bitmap->width);  ++x)
{
    d[i++] = 0xAA;
    d[i++] = 0xBB;
    d[i++] = 0xCC;
}

Y medido (tenía que usar "-mcmodel = large" para vincularlo). Entonces probé:

const std::size_t n = 0x80000000ull;
bitmap->width = n;
static unsigned char d[n*3];
std::size_t i=0;
unsigned width(static_cast<unsigned>(bitmap->width));
for (unsigned x = 0;  x < width;  ++x)
{
    d[i++] = 0xAA;
    d[i++] = 0xBB;
    d[i++] = 0xCC;
}

Los resultados de la medida fueron los mismos: parece que el compilador pudo optimizarlo por sí mismo.

Luego probé los códigos originales (con un puntero p), esta vez cuando pes de tipo std::uint16_t*. Nuevamente, los resultados fueron los mismos, debido al estricto aliasing. Luego intenté construir con "-fno-estricto-aliasing", y nuevamente vi una diferencia en el tiempo.

Otras respuestas han señalado que sacar la operación del puntero del bucle puede cambiar el comportamiento definido debido a las reglas de alias que permiten que char alias cualquier cosa y, por lo tanto, no es una optimización permitida para un compilador, aunque en la mayoría de los casos es obviamente correcto para un humano. programador.

También han señalado que sacar la operación del bucle suele ser, aunque no siempre, una mejora desde el punto de vista del rendimiento y, a menudo, es negativo desde el punto de vista de la legibilidad.

Me gustaría señalar que a menudo existe una "tercera vía". En lugar de contar hasta el número de iteraciones que desea, puede realizar una cuenta regresiva hasta cero. Esto significa que el número de iteraciones solo se necesita una vez al comienzo del ciclo, no tiene que almacenarse después de eso. Mejor aún, a nivel de ensamblador, a menudo elimina la necesidad de una comparación explícita, ya que la operación de decremento generalmente establecerá indicadores que indican si el contador era cero antes (indicador de acarreo) y después (indicador de cero) del decremento.

for (unsigned x = static_cast<unsigned>(bitmap->width);x > 0;  x--)
{
    *p++ = 0xAA;
    *p++ = 0xBB;
    *p++ = 0xCC;
}

Tenga en cuenta que esta versión del bucle da valores de x en el rango 1..ancho en lugar del rango 0 .. (ancho-1). Eso no importa en su caso porque en realidad no está usando x para nada, pero es algo que debe tener en cuenta. Si desea un ciclo de cuenta atrás con valores de x en el rango 0 .. (ancho-1), puede hacerlo.

for (unsigned x = static_cast<unsigned>(bitmap->width); x-- > 0;)
{
    *p++ = 0xAA;
    *p++ = 0xBB;
    *p++ = 0xCC;
}

También puede deshacerse de las conversiones en los ejemplos anteriores si lo desea sin preocuparse por su impacto en las reglas de comparación, ya que todo lo que está haciendo con mapa de bits-> ancho es asignarlo directamente a una variable.

Lo único aquí que puede evitar la optimización es la estricta regla de alias . Resumiendo :

"El alias estricto es una suposición, hecha por el compilador de C (o C ++), que los punteros de desreferenciación a objetos de diferentes tipos nunca se referirán a la misma ubicación de memoria (es decir, alias entre sí)".

[…]

La excepción a la regla es a char*, que puede apuntar a cualquier tipo.

La excepción también se aplica a unsignedy signed charpunteros.

Este es el caso en su código: está modificando a *ptravés de pcuál es un unsigned char*, por lo que el compilador debe asumir que podría apuntar a bitmap->width. Por lo tanto, el almacenamiento en caché de bitmap->widthes una optimización no válida. Este comportamiento de prevención de optimización se muestra en la respuesta de YSC .

Si y solo si se papunta a un tipo que no es chary que no es de decltype(bitmap->width)tipo, el almacenamiento en caché sería una posible optimización.

La pregunta originalmente formulada:

¿Vale la pena optimizarlo?

Y mi respuesta a eso (obteniendo una buena combinación de votos a favor y en contra ...)

Deje que el compilador se preocupe por eso.

Es casi seguro que el compilador hará un mejor trabajo que usted. Y no hay garantía de que su 'optimización' sea mejor que el código 'obvio'. ¿Lo ha medido?

Más importante aún, ¿tiene alguna prueba de que el código que está optimizando tenga algún impacto en el rendimiento de su programa?

A pesar de los votos negativos (y ahora veo el problema del alias), todavía estoy contento con eso como una respuesta válida. Si no sabe si vale la pena optimizar algo, probablemente no lo sea.

Una pregunta bastante diferente, por supuesto, sería la siguiente:

¿Cómo puedo saber si vale la pena optimizar un fragmento de código?

Primero, ¿su aplicación o biblioteca debe ejecutarse más rápido de lo que lo hace actualmente? ¿El usuario ha esperado demasiado? ¿Su software pronostica el tiempo de ayer en lugar del de mañana?

Solo usted puede saberlo, basándose en para qué sirve su software y en lo que esperan sus usuarios.

Suponiendo que su software necesita alguna optimización, lo siguiente que debe hacer es comenzar a medir. Los perfiladores le dirán dónde pasa su código, es hora. Si su fragmento no se muestra como un cuello de botella, es mejor dejarlo solo. Los perfiladores y otras herramientas de medición también le dirán si sus cambios han marcado una diferencia. Es posible pasar horas intentando optimizar el código, solo para descubrir que no ha hecho una diferencia apreciable.

De todos modos, ¿a qué te refieres con "optimizar"?

Si no está escribiendo un código 'optimizado', entonces su código debe ser tan claro, limpio y conciso como pueda. El argumento "La optimización prematura es mala" no es una excusa para un código descuidado o ineficiente.

El código optimizado normalmente sacrifica algunos de los atributos anteriores por el rendimiento. Podría implicar la introducción de variables locales adicionales, tener objetos con un alcance más amplio de lo esperado o incluso invertir el orden de bucle normal. Todos estos pueden ser menos claros o concisos, así que documente el código (¡brevemente!) Sobre por qué está haciendo esto.

Pero a menudo, con código "lento", estas microoptimizaciones son el último recurso. El primer lugar para mirar son los algoritmos y las estructuras de datos. ¿Hay alguna forma de evitar hacer el trabajo? ¿Se pueden reemplazar las búsquedas lineales por búsquedas binarias? ¿Una lista enlazada sería más rápida aquí que un vector? ¿O una mesa hash? ¿Puedo almacenar en caché los resultados? ¡Tomar buenas decisiones 'eficientes' aquí a menudo puede afectar el desempeño en un orden de magnitud o más!

Utilizo el siguiente patrón en una situación como esta. Es casi tan corto como el primer caso suyo, y es mejor que el segundo caso, porque mantiene la variable temporal local en el ciclo.

for (unsigned int x = 0, n = static_cast<unsigned>(bitmap->width); x < n; ++x)
{
  *p++ = 0xAA;
  *p++ = 0xBB;
  *p++ = 0xCC;
}

Esto será más rápido con un compilador menos inteligente, una compilación de depuración o ciertos indicadores de compilación.

Edit1 : colocar una operación constante fuera de un bucle es un buen patrón de programación. Muestra comprensión de los conceptos básicos del funcionamiento de la máquina, especialmente en C / C ++. Yo diría que el esfuerzo por demostrar su valía debería estar en personas que no sigan esta práctica. Si el compilador castiga por un buen patrón, es un error en el compilador.

Edit2: He medido mi sugerencia con el código original en vs2013, obtuve% 1 de mejora. ¿Podemos hacerlo mejor? Una simple optimización manual ofrece una mejora 3 veces mayor que el bucle original en la máquina x64 sin recurrir a instrucciones exóticas. El código siguiente asume un sistema little endian y un mapa de bits correctamente alineado. TEST 0 es original (9 seg), TEST 1 es más rápido (3 seg). Apuesto a que alguien podría hacer esto aún más rápido, y el resultado de la prueba dependería del tamaño del mapa de bits. Definitivamente, pronto en el futuro, el compilador podrá producir código consistentemente más rápido. Me temo que este será el futuro cuando el compilador también sea un programador de IA, por lo que estaríamos sin trabajo. Pero por ahora, simplemente escriba un código que muestre que sabe que no se necesita una operación adicional en el ciclo.

#include <memory>
#include <time.h>

struct Bitmap_line
{
  int blah;
  unsigned int width;
  Bitmap_line(unsigned int w)
  {
    blah = 0;
    width = w;
  }
};

#define TEST 0 //define 1 for faster test

int main(int argc, char* argv[])
{
  unsigned int size = (4 * 1024 * 1024) / 3 * 3; //makes it divisible by 3
  unsigned char* pointer = (unsigned char*)malloc(size);
  memset(pointer, 0, size);
  std::unique_ptr<Bitmap_line> bitmap(new Bitmap_line(size / 3));
  clock_t told = clock();
#if TEST == 0
  for (int iter = 0; iter < 10000; iter++)
  {
    unsigned char* p = pointer;
    for (unsigned x = 0; x < static_cast<unsigned>(bitmap->width); ++x)
    //for (unsigned x = 0, n = static_cast<unsigned>(bitmap->width); x < n; ++x)
    {
      *p++ = 0xAA;
      *p++ = 0xBB;
      *p++ = 0xCC;
    }
  }
#else
  for (int iter = 0; iter < 10000; iter++)
  {
    unsigned char* p = pointer;
    unsigned x = 0;
    for (const unsigned n = static_cast<unsigned>(bitmap->width) - 4; x < n; x += 4)
    {
      *(int64_t*)p = 0xBBAACCBBAACCBBAALL;
      p += 8;
      *(int32_t*)p = 0xCCBBAACC;
      p += 4;
    }

    for (const unsigned n = static_cast<unsigned>(bitmap->width); x < n; ++x)
    {
      *p++ = 0xAA;
      *p++ = 0xBB;
      *p++ = 0xCC;
    }
  }
#endif
  double ms = 1000.0 * double(clock() - told) / CLOCKS_PER_SEC;
  printf("time %0.3f\n", ms);

  {
    //verify
    unsigned char* p = pointer;
    for (unsigned x = 0, n = static_cast<unsigned>(bitmap->width); x < n; ++x)
    {
      if ((*p++ != 0xAA) || (*p++ != 0xBB) || (*p++ != 0xCC))
      {
        printf("EEEEEEEEEEEEERRRRORRRR!!!\n");
        abort();
      }
    }
  }

  return 0;
}

Hay dos cosas a considerar.

A) ¿Con qué frecuencia se ejecutará la optimización?

Si la respuesta no es muy frecuente, como solo cuando un usuario hace clic en un botón, no se moleste si hace que su código sea ilegible. Si la respuesta es 1000 veces por segundo, probablemente querrá ir con la optimización. Si es incluso un poco complejo, asegúrese de incluir un comentario para explicar lo que está sucediendo para ayudar al próximo chico que se presente.

B) ¿Esto hará que el código sea más difícil de mantener / solucionar?

Si no está viendo una gran ganancia en el rendimiento, hacer que su código sea críptico simplemente para guardar unos pocos tics de reloj no es una buena idea. Mucha gente le dirá que cualquier buen programador debería poder ver el código y averiguar qué está pasando. Esto es verdad. El problema es que en el mundo empresarial el tiempo extra para averiguarlo cuesta dinero. Entonces, si puedes hacerlo más bonito de leer, hazlo. Tus amigos te lo agradecerán.

Dicho esto, personalmente usaría el ejemplo B.

El compilador puede optimizar muchas cosas. Para su ejemplo, debe optar por la legibilidad, la mantenibilidad y lo que sigue el estándar de su código. Para obtener más información sobre lo que se puede optimizar (con GCC), consulte esta publicación de blog .

Como regla general, deje que el compilador haga la optimización por usted, hasta que determine que debe hacerse cargo. La lógica de esto no tiene nada que ver con el rendimiento, sino con la legibilidad humana. En la gran mayoría de los casos, la legibilidad de su programa es más importante que su rendimiento. Debe apuntar a escribir código que sea más fácil de leer para un humano, y luego solo preocuparse por la optimización cuando esté convencido de que el rendimiento es más importante que la capacidad de mantenimiento de su código.

Una vez que vea que el rendimiento es importante, debe ejecutar un generador de perfiles en el código para determinar qué bucles son ineficientes y optimizarlos individualmente. De hecho, puede haber casos en los que desee hacer esa optimización (especialmente si migra hacia C ++, donde se involucran los contenedores STL), pero el costo en términos de legibilidad es grande.

Además, puedo pensar en situaciones patológicas en las que podría ralentizar el código. Por ejemplo, considere el caso en el que el compilador no pudo probar que bitmap->widthera constante durante el proceso. Al agregar la widthvariable, fuerza al compilador a mantener una variable local en ese ámbito. Si, por alguna razón específica de la plataforma, esa variable adicional impidió alguna optimización del espacio de pila, es posible que deba reorganizar la forma en que emite códigos de bytes y producir algo menos eficiente.

Como ejemplo, en Windows x64, uno está obligado a llamar a una llamada API especial, __chkstken el preámbulo de la función si la función usará más de 1 página de variables locales. Esta función le da a Windows la oportunidad de administrar las páginas de protección que utilizan para expandir la pila cuando sea necesario. Si su variable adicional aumenta el uso de la pila de menos de 1 página a 1 página o más, su función ahora está obligada a llamar __chkstkcada vez que se ingresa. Si tuviera que optimizar este bucle en una ruta lenta, ¡en realidad podría ralentizar la ruta rápida más de lo que ahorró en la ruta lenta!

Claro, es un poco patológico, pero el punto de ese ejemplo es que puedes ralentizar el compilador. Simplemente muestra que tiene que perfilar su trabajo para determinar dónde van las optimizaciones. Mientras tanto, no sacrifique la legibilidad de ninguna manera por una optimización que puede o no importar.

La comparación es incorrecta ya que los dos fragmentos de código

for (unsigned x = 0;  x < static_cast<unsigned>(bitmap->width);  ++x)

y

unsigned width(static_cast<unsigned>(bitmap->width));
for (unsigned x = 0;  x<width ;  ++x)

no son equivalentes

En el primer caso, widthes dependiente y no constante, y no se puede suponer que no cambie entre iteraciones posteriores. Por lo tanto, no se puede optimizar, pero debe comprobarse en cada bucle .

En su caso optimizado, a una variable local se le asigna el valor de bitmap->widthen algún momento durante la ejecución del programa. El compilador puede verificar que esto no cambie realmente.

¿Pensó en subprocesos múltiples, o tal vez el valor podría depender externamente de manera que su valor sea volátil? ¿Cómo se puede esperar que el compilador resuelva todas estas cosas si usted no lo dice?

El compilador solo puede funcionar tan bien como su código lo permita.

A menos que sepa exactamente cómo el compilador optimiza el código, es mejor hacer sus propias optimizaciones manteniendo la legibilidad y el diseño del código. Prácticamente es difícil verificar el código ensamblador para cada función que escribimos para las nuevas versiones del compilador.

El compilador no puede optimizar bitmap->widthporque el valor de widthse puede cambiar entre iteraciones. Hay algunas razones más comunes:

1. Multi-hilo. El compilador no puede predecir si otro hilo está a punto de cambiar de valor.
2. Modificación dentro del ciclo, a veces no es fácil saber si la variable se cambiará dentro del ciclo.
3. Es llamada a la función, por ejemplo, iterator::end()o container::size()por lo que es difícil predecir si siempre se devuelve el mismo resultado.

Para resumir (mi opinión personal) para los lugares que requieren un alto nivel de optimización, debe hacerlo usted mismo, en otros lugares simplemente déjelo, el compilador puede optimizarlo o no, si no hay una gran diferencia, la legibilidad del código es el objetivo principal.