¿Puede la adición de 'const' a un puntero ayudar a la optimización?

Question

Tengo un puntero int* p y realizo algunas operaciones en un bucle. No modifico la memoria, solo leo. Si agrego const al puntero (en ambos casos, const int* p y int* const p), ¿puede ayudar a un compilador a optimizar el código?

Conozco otros méritos de const, como seguridad o auto-documentación, pregunto sobre este caso en particular. Reformulando la pregunta: ¿puede el const dar al compilador alguna información útil (para optimización) alguna vez?

Answer 1

Si bien esto es obviamente específico para la implementación, es difícil ver cómo el cambio de un puntero de int* a int const* podría proporcionar alguna información adicional que el compilador de otra forma no hubiera conocido.

En ambos casos, el valor señalado puede cambiar durante la ejecución del ciclo.

Por lo tanto, probablemente no ayudará al compilador a optimizar el código.

Answer 2

Puede ayudar o no puede hacer la diferencia o puede empeorar las cosas. La única manera de saber es probar ambos e inspeccionar el código de la máquina emitida.

Los compiladores modernos son muy inteligentes, por lo que a menudo pueden deducir que la memoria no cambia sin ningún calificador (pueden deducir que muchas otras optimizaciones son posibles sin código escrito de manera más fácil de analizar) pero son bastante complejas y tienen un muchas deficiencias y, a menudo no se puede optimizar todo lo posible en cada oportunidad.

Answer 3

No. Usar const like that no proporcionará al compilador ninguna información que pueda usarse para la optimización.

Teóricamente, para que sea una ayuda para su compilador, el optimizador debe ser capaz de demostrar que nadie usará const_cast en su puntero const pero no podrá demostrar que la variable nunca se escribió. Tal situación es altamente improbable.

Herb Sutter cubre esto con más profundidad en una de sus columnas Guru of the Week.

Answer 4

Creo que el compilador no puede hacer mucho en su escenario. El hecho de que su puntero declarado como const int * const p no garantiza que la memoria no se pueda cambiar externamente, p. por otro hilo Por lo tanto, el compilador debe generar código que lea el valor de memoria en cada iteración de su ciclo.

Pero si que no van a escribir en la ubicación de memoria y que sabe que ningún otro fragmento de código, a continuación, puede crear una variable local y utilizarlo similar a esto:

const int * p = ... 
... 
int val = *p; 
/* use the value in a loop */ 
for (i = 0; i < BAZILLION; i++) 
{ 
    use_value(val); 
} 

No solo ayuda a los lectores potenciales de su código a ver que el val no se cambia en un bucle, sino que también le da al compilador la posibilidad de optimizar (cargar val en un registro, por ejemplo).

Answer 5

El uso de const es, como todos han dicho, poco probable que ayude al compilador a optimizar su ciclo.

Puede, sin embargo, ayudar a optimizar el código fuera de el bucle, o en el sitio de una llamada a un método const-calificado, o a una función que toma argumentos const.

Esto probablemente dependa de si el compilador puede probar que está permitido eliminar cargas redundantes, moverlas o guardar valores calculados en lugar de volver a calcularlos.

La única manera de probar esto sigue siendo perfilar y/o verificar el ensamblaje, pero es ahí donde probablemente debería estar buscando.

Answer 6

Usted no dice qué compilador está utilizando. Pero si ambos leen y escriben en la memoria, podrían beneficiarse del uso de "restringir" o similar. El compilador no sabe si los punteros aliasen la misma memoria, por lo que cualquier tienda a menudo obliga a cargar otros valores de nuevo. "restringir" le dice al compilador que no hay aliasing del puntero y puede seguir utilizando los valores cargados antes de una posterior escritura. Otra forma de evitar el problema del aliasing es cargar sus valores en variables locales, luego el compilador no está obligado a volver a cargar después de escribir.