Velocidad de desreferenciación del puntero de estructura C

Question

Tengo una pregunta sobre la velocidad de desreferenciación del puntero. Tengo una estructura como esta:

typedef struct _TD_RECT TD_RECT; 
struct _TD_RECT { 
    double left; 
    double top; 
    double right; 
    double bottom; 
}; 

Mi pregunta es, ¿cuál de estos sería más rápido y por qué?

---

CASO 1:

TD_RECT *pRect; 
... 
for(i = 0; i < m; i++) 
{ 
    if(p[i].x < pRect->left) ... 
    if(p[i].x > pRect->right) ... 
    if(p[i].y < pRect->top) ... 
    if(p[i].y > pRect->bottom) ... 
} 

---

CASO 2:

TD_RECT *pRect; 
double left = pRect->left; 
double top = pRect->top; 
double right = pRect->right; 
double bottom = pRect->bottom; 
... 
for(i = 0; i < m; i++) 
{ 
    if(p[i].x < left) ... 
    if(p[i].x > right) ... 
    if(p[i].y < top) ... 
    if(p[i].y > bottom) ... 
} 

---

Así en el caso 1, el bucle se dereferencing directamente el puntero pRect para obtener la comparación valores. En el caso 2, se hicieron nuevos valores en el espacio local de la función (en la pila) y los valores se copiaron del pRect a las variables locales. A través de un bucle habrá muchas comparaciones.

En mi mente, serían igualmente lento, ya que la variable local es también una referencia a memoria en la pila, pero no estoy seguro ...

Además, sería mejor mantener referencia p [] por índice, o incrementar p por un elemento y desreferenciarlo directamente sin un índice.

¿Alguna idea? Gracias :)

Answer 1

Creo que el segundo caso es probable que sea más rápido porque no está desreferenciando el puntero a pRect en cada iteración de bucle.

Prácticamente, un compilador que realiza la optimización puede notar esto y puede que no haya diferencia en el código que se genera, pero la posibilidad de que pRect sea un alias de un elemento en p [] podría evitarlo.

Answer 2

Probablemente descubrirá que no hará la diferencia con los compiladores modernos. La mayoría de ellos probablemente realizaría una eliminación de subexpresiones común de las expresiones que no cambian dentro del ciclo. No es prudente suponer que hay un mapeo simple uno a uno entre sus declaraciones C y el código ensamblador. He visto un código de bomba de gcc que avergonzaría mis habilidades como ensamblador.

Pero esta no es una pregunta en C ni en C++ ya que el estándar ISO no ordena cómo se hace. La mejor manera de verificarlo con seguridad es generar el código de ensamblador con algo como gcc -S y examinar los dos casos en detalle.

También obtendrá un mayor retorno de su inversión si se aleja de este tipo de micro-optimización y se concentra más en el nivel macro, como la selección de algoritmos y tal.

Y, como con todas las preguntas de optimización, medida, ¡no adivine! Existen demasiadas variables que pueden afectarlo, por lo que debe comparar diferentes enfoques en el entorno objetivo y con datos realistas.

Answer 3

Un compilador de optimización verá que los accesos a la estructura son invariantes de bucle y también un Loop-invariant code motion, haciendo que sus dos casos se vean iguales.

Answer 4

No es probable que sea una gran diferencia de rendimiento crítico. Podría hacer un perfil de cada opción varias veces y ver. Asegúrese de tener sus optimizaciones de compilador establecidas en la prueba.

Con respecto al almacenamiento de los dobles, es posible que obtenga algún rendimiento al usar const. ¿Qué tan grande es tu matriz?

Con respecto al uso de la aritmética del puntero, esto puede ser más rápido, sí.

Puede optimizar al instante si conoce < a la derecha en su rect (seguramente debe ser). Si x < se fue, tampoco puede ser> correcto para que pueda poner en "else".

Su gran optimización, si hay una, vendría de no tener que recorrer todos los elementos de su matriz y no tener que realizar 4 comprobaciones en todos ellos.

Por ejemplo, si indizaste o clasificaste tu matriz en xey, podrías, usando la búsqueda binaria, encontrar todos los valores que tienen x < a la izquierda y recorrer esos solo.

Answer 5

Me sorprenderé si incluso una compilación totalmente no optimizada (- O0) producirá differentcode para los dos casos presentados. Para realizar cualquier operación en un procesador moderno, los datos deben cargarse en los registros. Por lo tanto, incluso cuando declare variables automáticas, estas variables no existirán en la memoria principal, sino en uno de los procesadores de coma flotante. Esto será cierto incluso cuando no declare las variables usted mismo y, por lo tanto, no espero que exista diferencia en el código máquina generado, incluso cuando declare las variables temporales en su código C++.

Pero como han dicho otros, compile el código en el ensamblador y compruébelo usted mismo.