¿Es x + = a más rápido que x = x + a?

Estaba leyendo "El lenguaje de programación C ++" de Stroustrup, donde dice que hay dos formas de agregar algo a una variable

x = x + a;

y

x += a;

Él prefiere +=porque probablemente esté mejor implementado. Creo que quiere decir que también funciona más rápido.
¿Pero realmente es así? Si depende del compilador y otras cosas, ¿cómo lo compruebo?

Cualquier compilador vale su sal generará exactamente la misma secuencia en lenguaje de máquina para ambas construcciones para cualquier tipo incorporado ( int, float, etc.), siempre y cuando la declaración realmente es tan simple como x = x + a; y optimización está activada . (En particular, GCC -O0, que es el modo predeterminado, realiza anti-optimizaciones , como insertar almacenes completamente innecesarios en la memoria, para garantizar que los depuradores siempre puedan encontrar valores de variables).

Sin embargo, si la declaración es más complicada, pueden ser diferentes. Supongamos que fes una función que devuelve un puntero, entonces

*f() += a;

llamadas fsolo una vez, mientras que

*f() = *f() + a;

lo llama dos veces. Si ftiene efectos secundarios, uno de los dos estará mal (probablemente el último). Incluso si fno tiene efectos secundarios, es posible que el compilador no pueda eliminar la segunda llamada, por lo que esta última puede ser más lenta.

Y dado que estamos hablando de C ++ aquí, la situación es completamente diferente para los tipos de clases que sobrecargan operator+y operator+=. Si xes de ese tipo, entonces, antes de la optimización, se x += atraduce en

x.operator+=(a);

mientras que se x = x + atraduce en

auto TEMP(x.operator+(a));
x.operator=(TEMP);

Ahora, si la clase está escrita correctamente y el optimizador del compilador es lo suficientemente bueno, ambos terminarán generando el mismo lenguaje de máquina, pero no es tan seguro como lo es para los tipos integrados. Esto es probablemente en lo que está pensando Stroustrup cuando fomenta su uso +=.

Puede comprobarlo mirando el desmontaje, que será el mismo.

Para los tipos básicos , ambos son igualmente rápidos.

Esta es la salida generada por una compilación de depuración (es decir, sin optimizaciones):

    a += x;
010813BC  mov         eax,dword ptr [a]  
010813BF  add         eax,dword ptr [x]  
010813C2  mov         dword ptr [a],eax  
    a = a + x;
010813C5  mov         eax,dword ptr [a]  
010813C8  add         eax,dword ptr [x]  
010813CB  mov         dword ptr [a],eax  

Para tipos definidos por el usuario , donde puede sobrecargar operator +y operator +=, depende de sus respectivas implementaciones.

¡Si! Es más rápido de escribir, más rápido de leer y más rápido de entender, para lo último en el caso de que xpueda tener efectos secundarios. Entonces, en general, es más rápido para los humanos. El tiempo humano en general cuesta mucho más que el tiempo de la computadora, así que eso debe ser lo que preguntaba. ¿Derecho?

Realmente depende del tipo de xya y de la implementación de +. por

   T x, a;
   ....
   x = x + a;

el compilador tiene que crear una T temporal para contener el valor de x + a mientras lo evalúa, que luego puede asignar a x. (No puede usar xo como espacio de trabajo durante esta operación).

Para x + = a, no necesita un temporal.

Para los tipos triviales, no hay diferencia.

La diferencia entre x = x + ay x += aes la cantidad de trabajo que debe realizar la máquina: algunos compiladores pueden (y generalmente lo hacen) optimizarla, pero generalmente, si ignoramos la optimización por un tiempo, lo que sucede es que en el fragmento de código anterior, el machine tiene que buscar el valor xdos veces, mientras que en el último, esta búsqueda debe ocurrir solo una vez.

Sin embargo, como mencioné, hoy en día la mayoría de los compiladores son lo suficientemente inteligentes como para analizar la instrucción y reducir las instrucciones de máquina resultantes requeridas.

PD: ¡Primera respuesta en Stack Overflow!

Como ha etiquetado este C ++, no hay forma de saberlo por las dos declaraciones que ha publicado. Necesita saber qué es 'x' (es un poco como la respuesta '42'). Si xes un POD, entonces realmente no hará mucha diferencia. Sin embargo, si xes una clase, puede haber sobrecargas para los métodos operator +y operator +=que podrían tener diferentes comportamientos que conducen a tiempos de ejecución muy diferentes.

Si dice que +=le está haciendo la vida mucho más fácil al compilador. Para que el compilador reconozca que x = x+aes lo mismo que x += a, el compilador debe

• analice el lado izquierdo ( x) para asegurarse de que no tenga efectos secundarios y siempre se refiera al mismo valor l. Por ejemplo, podría serlo z[i], y debe asegurarse de que ambos zy ino cambien.

• analice el lado derecho ( x+a) y asegúrese de que sea una suma, y ​​que el lado izquierdo aparezca una vez y solo una vez en el lado derecho, aunque podría transformarse, como en z[i] = a + *(z+2*0+i).

Si lo que quiere decir es agregar aa x, el escritor compilador lo aprecia cuando se acaba de decir lo que quiere decir. De esa manera, no estás ejercitando la parte del compilador de la que su escritor espera que haya eliminado todos los errores, y eso en realidad no te hace la vida más fácil, a menos que honestamente no puedas sacar la cabeza del modo Fortran.

Para un ejemplo concreto, imagine un tipo de número complejo simple:

struct complex {
    double x, y;
    complex(double _x, double _y) : x(_x), y(_y) { }
    complex& operator +=(const complex& b) {
        x += b.x;
        y += b.y;
        return *this;
    }
    complex operator +(const complex& b) {
        complex result(x+b.x, y+b.y);
        return result;
    }
    /* trivial assignment operator */
}

Para el caso a = a + b, tiene que hacer una variable temporal extra y luego copiarla.

Estás haciendo la pregunta incorrecta.

Es poco probable que esto impulse el rendimiento de una aplicación o función. Incluso si lo fuera, la forma de averiguarlo es perfilar el código y saber con certeza cómo te afecta. En lugar de preocuparse a este nivel por cuál es más rápido, es mucho más importante pensar en términos de claridad, corrección y legibilidad.

Esto es especialmente cierto cuando se considera que, incluso si se trata de un factor de rendimiento significativo, los compiladores evolucionan con el tiempo. Alguien puede encontrar una nueva optimización y la respuesta correcta hoy puede volverse incorrecta mañana. Es un caso clásico de optimización prematura.

Esto no quiere decir que el rendimiento no importe en absoluto ... Solo que es el enfoque incorrecto para lograr sus objetivos de rendimiento. El enfoque correcto es utilizar herramientas de creación de perfiles para saber dónde gasta realmente su tiempo su código y, por lo tanto, dónde centrar sus esfuerzos.

Creo que eso debería depender de la máquina y su arquitectura. Si su arquitectura permite el direccionamiento indirecto de memoria, el escritor del compilador PODRÍA usar este código en su lugar (para la optimización):

mov $[y],$ACC

iadd $ACC, $[i] ; i += y. WHICH MIGHT ALSO STORE IT INTO "i"

Considerando que, i = i + ypodría traducirse a (sin optimización):

mov $[i],$ACC

mov $[y],$B 

iadd $ACC,$B

mov $B,[i]

No, ambas formas se manejan de la misma manera.