¿Hay algún estudio o conjunto de pruebas que demuestren la degradación del rendimiento debido a la especificación de alias -fno-strict-aliasing en GCC (o equivalente en otros compiladores)?Impacto de rendimiento de -fno-strict-aliasing
Variará mucho de compilador a compilador, ya que los diferentes compiladores lo implementan con diferentes niveles de agresión. GCC es bastante agresivo al respecto: habilitar un alias estricto hará que piense que los punteros que son "obviamente" equivalentes a un humano (como en, foo* a; bar * b; b = (foo*)a;) no pueden alias, lo que permite algunas transformaciones muy agresivas, pero obviamente pueden romperse sin cuidado código escrito. El GCC de Apple desactiva el aliasing estricto de forma predeterminada por este motivo.
LLVM, por el contrario, lo hace ni siquiera tienen estricta aliasing, y, si bien se prevé, los desarrolladores han dicho que planean implementarlo como un caso de repliegue cuando nada más se puede determinar la equivalencia. En el ejemplo anterior, todavía juzgaría ayb equivalentes. Solo usaría un alias basado en tipos si no pudiera determinar su relación de ninguna otra manera.
En mi experiencia, el impacto en el rendimiento del aliasing estricto tiene que ver principalmente con el movimiento de código invariante de bucle, donde la información de tipo se puede utilizar para demostrar que las cargas in-loop no pueden aliar la matriz iterada, lo que les permite ser sacado del circuito. YMMV.
El enfoque de LLVM me parece el correcto – Spudd86
Lo que puedo decirte por experiencia (habiendo probado esto con un gran proyecto en PS3, PowerPC es una arquitectura que debido a sus muchos registros realmente puede beneficiarse de SA) es que las optimizaciones que vas a ver generalmente van a ser muy locales (en cuanto al alcance) y pequeñas. En un ejecutable de 20MB raspaba quizá 80kb de la sección .text (= código) y todo esto en pequeños ámbitos & loops.
Esta opción puede hacer que su código generado sea un poco más liviano y optimizado de lo que es ahora (piense en el rango del 1 al 5 por ciento), pero no espere grandes resultados. Por lo tanto, el efecto de usar -fno-strict-aliasing probablemente no va a ser una gran influencia en su rendimiento, en absoluto. Dicho esto, tener un código que requiera -fno-strict-aliasing es una situación subóptima en el mejor de los casos.
Porque el tamaño del código == velocidad? Tu ejemplo de PS3 no está aquí ni allá. ¿Cómo FUNCIONó? – Eloff
¿Dónde digo que es más rápido? Podría ser - no es impensable dado que las cargas/tiendas potenciales se han omitido - y en cualquier caso, es preferible un ejecutable más pequeño en una máquina con memoria encuadernada. Así que está aquí, y también está allí. – nielsj
El OP pidió implicaciones de rendimiento y usted solo habló sobre el tamaño del código. Luego utilizó un argumento ipso facto sobre por qué no verá una gran diferencia de rendimiento. Luego llamaste al kernel de Linux una "situación subóptima en el mejor de los casos". Creo que puedes ver por qué obtuviste el voto a favor. – Eloff
Aquí hay un enlace al estudio realizado en 2004: http://docs.lib.purdue.edu/cgi/viewcontent.cgi?article=1124&context=ecetr relacionado, entre otros, con un impacto de aliasing estricto en el rendimiento del código. La Figura 2.5 muestra una mejora relativa del 3% al 10%. explicación
Investigadores de la degradación del rendimiento:
de inspeccionar el código ensamblador, se encontró que la degradación es un efecto de el algoritmo de asignación de registros. GCC implementa un asignador de registro colorante de gráficos [2, 3]. Con aliasing estricto, los rangos activos de las variables se vuelven más largos, dando lugar a una alta presión de registro y 'derrame'. Con aliasing más conservadores, las mismas variables incurren en transferencias de memoria al final de sus rangos de vida (más cortos) también.
[2] Peter Bergner, Peter Dahl, David Engebretsen y Matthew T. O'Keefe. Código de derrame minimización a través del derrame de la región de interferencia. En SIGPLAN Conference on Programming Language Design and Implementation, páginas 287-295, 1997.
[3] Preston Briggs, Keith D. Cooper y Linda Torczon. Mejoras en la coloración de gráficos asignación de registros. Transacciones de ACM en Lenguajes y Sistemas de Programación, 16 (3): 428-455, mayo de 1994.
¿Conoces algún estudio que haya analizado el valor de las optimizaciones que estaría permitido por el estricto aliasing * que no podría lograrse también mediante el calificador 'restrict' *? – supercat
No conozco ninguna, ¿conoces alguna optimización que satisfaga estos requisitos? – SzymonPajzert
El calificador 'restrict 'no se puede usar de manera efectiva para decirle a un compilador que los objetos de duración estática no alias, y en algunos casos los programas pueden tener varios apuntadores posiblemente relacionados al mismo tipo que podrían alias entre sí. El alias basado en tipos permitiría algunas optimizaciones en aquellos casos que de otro modo no estarían disponibles. En mi humilde opinión, tales casos podrían haberse manejado mejor agregando mejores calificadores (por ejemplo, permitir un calificador de 'registro' en los casos en que un objeto puede estar expuesto a un código externo, pero que podría comportarse como si obtuvieran una nueva dirección cuando se accede a través de un puntero) – supercat
Duplicado exacto: http://stackoverflow.com/questions/754929/strict-aliasing – GManNickG
No encontré ningún número de rendimiento en esa discusión. Estoy buscando algunos resultados/datos de prueba. ¿Me he perdido algo? – Carlos
FWIW, tampoco hay números de rendimiento en la respuesta aceptada. – peterchen