2008-11-13 14 views
14

He oído que habilitar la generación de código de tiempo de enlace (el modificador/LTCG) puede ser una gran optimización para proyectos grandes con muchas bibliotecas para vincular. Mi equipo lo está usando en la configuración de lanzamiento de nuestra solución, pero el largo tiempo de compilación es una verdadera carga. Un cambio en un archivo que no depende de otro archivo desencadena otros 45 segundos de "Generación de código ...". La liberación es ciertamente mucho más rápida que la depuración, pero podríamos lograr la misma aceleración al desactivar LTCG y simplemente dejar/O2 activado.¿Cuáles son los pros y los contras de la generación de código de tiempo de enlace? (VS 2005)

¿Vale la pena dejar/LTCG habilitado?

Respuesta

12

Es difícil de decir, porque eso depende principalmente de su proyecto, y por supuesto de la calidad del LTCG proporcionado por VS2005 (que no tengo suficiente experiencia para juzgar). Al final, tendrás que medir.

Sin embargo, me pregunto por qué tiene tantos problemas con la duración extra de la versión de lanzamiento. Solo debe distribuir binarios reproducibles, estables y versionados que tengan fuentes reproducibles o archivadas. Rara vez he visto una razón para las compilaciones de versiones incrementales frecuentes.

La configuración recomendada para un equipo es la siguiente: Los desarrolladores normalmente crean solo compilaciones de depuración incremental en sus máquinas. La creación de un lanzamiento debe ser una compilación completa desde el control de origen hasta redistribuible (binarios o incluso configuración), con un nuevo número de versión y etiquetado/archivo de las fuentes. Solo estos deben ser dados a probadores/clientes internos.

Idealmente, moverías la compilación completa a una máquina separada, o tal vez a una máquina virtual en una buena PC. Esto le proporciona un entorno estable para sus compilaciones (incluye bibliotecas de terceros, variables de entorno, etc.).

Lo ideal es que estas compilaciones se automaticen ("un clic del control de origen a la configuración") y se ejecuten diariamente.

+0

'La creación de un lanzamiento debe ser una compilación completa desde el control de origen hasta redistribuible (binarios o incluso configuración), con un nuevo número de versión y etiquetado/archivado de las fuentes ¿No está esto en contradicción con lo que está escrito en la sección? Limitación en el uso de LTCG "en [este artículo] (https://msdn.microsoft.com/en-us/library/bb985904.aspx) por Matt Pietrek (el énfasis es mío): ... continuará. – Belloc

+0

' Mientras LTCG Por lo general, es algo bueno, existen algunas trampas potenciales que pueden afectarlo. Primero, los encabezados precompilados y LTCG son incompatibles. Esto no debería ser un problema para la mayoría de los usuarios, ya que ** normalmente solo enciende LTCG en compilaciones de versiones * *, donde el tiempo de compilación no suele ser un problema.? – Belloc

+0

No veo ningún problema, mi punto central es que la duración de la versión de lanzamiento no debería importar demasiado. Las versiones de lanzamiento deberían ser automáticas y no bloquear la máquina reveladora. s (o al menos: son infrecuentes). Son significativamente más lentos de todos modos debido al optimizador y debido a LTCG. No usar PCH en compilaciones de lanzamiento lo haría aún más lento, pero no tanto, en términos relativos, y no afectaría las compilaciones de desarrollo. --- Además de que la limitación parece ser una cosa del pasado (VS2003 tal vez?), AFAICT LTCG y PCH son compatibles, – peterchen

-1

Tampoco veo problemas con el tiempo de compilación adicional utilizando la generación de código de tiempo de enlace con la compilación de lanzamiento. Solo construyo mi versión de lanzamiento una vez por día (durante la noche) y uso las compilaciones de prueba unitaria y de depuración durante el día.

3

Sé que los chicos de Bungie lo usaron para Halo3, la única estafa que mencionaron fue que a veces arruinaba sus datos de reproducción deterministas.

¿Ha perfilado su código y determinado la necesidad de esto? En realidad, ejecutamos nuestros servidores casi por completo en modo de depuración, pero en casos especiales, algunos archivos que se perfilaron como críticos para el rendimiento. Eso funcionó muy bien, y ha mantenido las cosas depuradas cuando hay problemas.

No estoy seguro de qué tipo de aplicación está haciendo, pero dividir las estructuras de datos para corresponder con la forma en que se procesaron en el código (para una mejor coherencia del caché) fue mucho más grande para nosotros.

10

Permite al vinculador hacer la compilación real del código y, por lo tanto, puede hacer más optimizaciones, como la alineación.

Si no utiliza LTCG, el compilador es el único componente en el proceso de compilación que puede alinear una función, como reemplazar una "llamada" a una función con el contenido de la función, que suele ser mucho Más rápido. El compilador solo lo haría de todos modos para las funciones donde esto produce una mejora.

Por lo tanto, solo puede hacerlo con las funciones que tiene el cuerpo de. Esto significa que si una función en el archivo cpp llama a otra función que no está implementada en el mismo archivo cpp (o en un archivo de encabezado incluido), entonces no tiene el cuerpo real de la función y, por lo tanto, no puede alinearla .

Pero si usa LTCG, es el enlazador el que hace la línea y tiene todas las funciones en todos los archivos cpp de todo el proyecto, menos los archivos lib referenciados que no fueron creados con LTCG. Esto le da al engarce (que se convierte en el compilador) mucho más para trabajar.

Pero también hace que su compilación tarde más tiempo, especialmente al realizar cambios incrementales. Es posible que desee activar LTCG en la configuración de lanzamiento de compilación.

Tenga en cuenta que LTCG no es lo mismo que la optimización guiada por perfil.

1

He encontrado que las desventajas son tiempos de compilación más largos y que los archivos .obj creados en ese modo (LTCG activado) pueden ser realmente masivos. Por ejemplo, los archivos .obj que pueden ser 200-500k tienen aproximadamente 2-3mb. Simplemente me pasó a mí que compilar un montón de proyectos en mi cadena me llevó a una carpeta de 2 gb, la mayor parte de los cuales eran archivos .obj.

Cuestiones relacionadas