C++ arreglos de tamaño fijo frente a múltiples objetos del mismo tipo

Question

Me preguntaba si (aparte de las obvias diferencias de sintaxis) habría una diferencia de eficiencia entre tener una clase que contenga instancias múltiples de un objeto (del mismo tipo) o una tamaño array de objetos de ese tipo.

En código:

struct A { 
    double x; 
    double y; 
    double z; 
}; 

struct B { 
    double xvec[3]; 
}; 

En realidad iba a usar boost :: matrices que son una mejor alternativa a C++ matrices de tipo C.

Me preocupa principalmente la construcción/destrucción y la lectura/escritura de estos dobles, porque estas clases a menudo se construirán solo para invocar una de sus funciones miembro una vez.

Gracias por su ayuda/sugerencias.

Answer 1

Normalmente, la representación de esas dos estructuras sería exactamente la misma. Sin embargo, es posible que tenga un rendimiento deficiente si elige el incorrecto para su caso de uso.

Por ejemplo, si necesita acceder a cada elemento en un bucle, con un arsenal que podría hacer:

for (int i = 0; i < 3; i++) 
    dosomething(xvec[i]); 

Sin embargo, sin una matriz, que le sea necesario duplicar el código:

dosomething(x); 
dosomething(y); 
dosomething(z); 

Esto significa duplicación de código, que puede ser de cualquier manera. Por un lado, hay menos código de bucle; por otro lado, los bucles muy apretados pueden ser bastante rápidos en los procesadores modernos, y la duplicación de código puede volar el I-caché.

La otra opción es un interruptor:

for (int i = 0; i < 3; i++) { 
    int *r; 
    switch(i) { 
     case 0: r = &x; break; 
     case 1: r = &y; break; 
     case 1: r = &z; break; 
    } 
    dosomething(*r); // assume this is some big inlined code 
} 

Esto evita la posiblemente a gran huella de i-cache, pero tiene un enorme impacto en el rendimiento negativo. No hagas esto

Por otro lado, es, en principio, posible gama accede a ser más lento, si su compilador no es muy inteligente:

xvec[0] = xvec[1] + 1; 
dosomething(xvec[1]); 

Desde xvec [0] y xvec [1] son distinto, en principio, el compilador debería ser capaz de mantener el valor de xvec [1] en un registro, por lo que no tiene que volver a cargar el valor en la siguiente línea. Sin embargo, es posible que algunos compiladores no sean lo suficientemente inteligentes como para notar que xvec [0] y xvec [1] no tienen alias. En este caso, usar campos separados podría ser un poco más rápido.

En resumen, no se trata de que una u otra sea rápida en todos los casos. Se trata de hacer coincidir la representación con la forma en que la usas.

Personalmente, le sugiero que vaya con lo que sea que haga que el código que funciona en xvec sea más natural. No vale la pena pasar mucho tiempo humano preocupándose por algo que, en el mejor de los casos, probablemente solo produzca una diferencia de rendimiento tan pequeña que solo la detectará en micro-puntos de referencia.

Answer 2

Depende. Por ejemplo, el ejemplo que dio es un clásico en favor de arrays 'vieja escuela': un punto/vector matemáticas (o matriz)

• tiene un número fijo de elementos
• los datos en sí es por lo general guardado privada en un objeto
• ya que (si?) que tiene una clase como una interfaz , puede adecuadamente inicializarlas en el constructor (de lo contrario, clásico gama inialization es algo que no me gusta mucho , sintaxis)

En tales casos (yendo con los ejemplos de matriz/vector matemático), siempre terminé usando matrices de estilo C internamente, ya que puede recorrerlas en lugar de escribir código de copia/pegado para cada componente.

Pero este es un caso especial - para mí, en C++ hoy en día matrices == vector de STL, es rápido y no tener que preocuparse por el nuthin :)

Answer 3

matrices primas ofrecen una mejor localización de caché matrices de C++, tal como se presenta, la única ventaja del ejemplo de matriz sobre los objetos múltiples es la capacidad de iterar sobre los elementos.

La respuesta real es, por supuesto, crear un caso de prueba y medir.

Answer 4

MVC++ 2010 generó exactamente el mismo código para lectura/escritura de dos estructuras POD como en su ejemplo. Dado que los desplazamientos para leer/escribir son computables en tiempo de compilación, esto no es sorprendente. Lo mismo ocurre con la construcción y la destrucción.

En cuanto al rendimiento real, se aplica la regla general: perfilar si es importante, si no es así - ¿por qué preocuparse?

La indexación en un miembro de la matriz es tal vez un poco más trabajo para el usuario de su estructura, pero una vez más, puede iterar más fácilmente sobre los elementos.

Answer 5

En caso de que no se puede decidir y quiere mantener sus opciones abiertas, se puede utilizar una unión anónima:

struct Foo 
{ 
    union 
    { 
     struct 
     { 
      double x; 
      double y; 
      double z; 
     } xyz; 
     double arr[3]; 
    }; 
}; 

int main() 
{ 
    Foo a; 
    a.xyz.x = 42; 
    std::cout << a.arr[0] << std::endl; 
} 

Algunos compiladores también soportan estructuras anónimas, en ese caso, puede dejar la parte xyz a cabo .

Answer 6

La diferencia puede estar en almacenar las variables en la memoria. En el primer ejemplo, el compilador puede agregar relleno para alinear los datos. Pero en tu caso particular, no importa.