Каковы плюсы и минусы генерации кода Link-Time? (VS 2005) - PullRequest
18 голосов
/ 14 ноября 2008

Я слышал, что активация Link-Time Code Generation (ключ / LTCG) может быть основной оптимизацией для больших проектов с большим количеством библиотек для объединения. Моя команда использует его в конфигурации выпуска нашего решения, но длительное время компиляции - это настоящее перетягивание. Одно изменение в одном файле, от которого не зависит ни один другой файл, вызывает еще 45 секунд «Генерация кода ...». Релиз, конечно, намного быстрее, чем Debug, но мы могли бы добиться такого же ускорения, отключив LTCG и просто оставив / O2 включенным.

Стоит ли оставлять / LTCG включенным?

Ответы [ 5 ]

12 голосов
/ 14 ноября 2008

Трудно сказать, потому что это зависит в основном от вашего проекта - и, конечно, от качества LTCG, предоставляемого VS2005 (по которому у меня недостаточно опыта, чтобы судить). В конце концов, вам придется измерить.

Однако мне интересно, почему у вас так много проблем с дополнительной продолжительностью сборки релиза. Вы должны раздавать только воспроизводимые, стабильные, версионные двоичные файлы, которые имеют воспроизводимые или архивированные источники. Я редко видел причину частых инкрементных сборок релиза.

Рекомендуемая настройка для команды: Разработчики обычно создают только инкрементные сборки отладки на своих машинах. Сборка релиза должна быть полной сборкой от контроля версий до перераспределения (двоичные файлы или даже установки) с новым номером версии и маркировкой / архивированием источников. Только они должны быть предоставлены внутренним тестерам / клиентам.

В идеале вы должны перенести полную сборку на отдельную машину или, возможно, на виртуальную машину на хорошем ПК. Это обеспечивает стабильную среду для ваших сборок (включая сторонние библиотеки, переменные среды и т. Д.).

В идеале, эти сборки должны быть автоматизированы («один щелчок от управления исходным кодом до настройки») и запускаться ежедневно.

11 голосов
/ 14 ноября 2008

Это позволяет компоновщику выполнять фактическую компиляцию кода, и, следовательно, он может выполнять дополнительную оптимизацию, такую ​​как вставка.

Если вы не используете LTCG, компилятор является единственным компонентом в процессе сборки, который может встроить функцию, например, заменить «вызов» функции содержимым функции, что обычно происходит намного быстрее. , В любом случае компилятор будет делать это только для функций, в которых это дает улучшение.

Поэтому он может делать это только с функциями, для которых он имеет тело. Это означает, что если функция в файле cpp вызывает другую функцию, которая не реализована в том же файле cpp (или в заголовочном файле, который включен), то она не имеет фактического тела функции и поэтому не может встроить ее .

Но если вы используете LTCG, это компоновщик, который выполняет встраивание, и он имеет все функции во всех файлах cpp всего проекта, за исключением ссылочных файлов lib, которые не были созданы с помощью LTCG. Это дает компоновщику (который становится компилятором) гораздо больше возможностей для работы.

Но это также увеличивает длительность сборки, особенно при внесении дополнительных изменений. Возможно, вы захотите включить LTCG в своей конфигурации сборки релиза.

Обратите внимание, что LTCG - это не то же самое, что оптимизация по профилю.

3 голосов
/ 14 ноября 2008

Я знаю, что ребята из Bungie использовали его для Halo3, единственный недостаток, который они упомянули, это то, что он иногда испортил их детерминированные данные воспроизведения.

Вы профилировали свой код и определили необходимость для этого? Мы фактически запускаем наши серверы почти полностью в режиме отладки, но в особом случае несколько файлов, которые профилируются как критичные для производительности. Это отлично работает и позволяет отлаживать вещи при возникновении проблем.

Не уверен, какое приложение вы создаете, но разбивка структур данных в соответствии с тем, как они обрабатывались в коде (для лучшей когерентности кэша), была для нас гораздо большей победой.

1 голос
/ 02 декабря 2008

Я обнаружил, что минусы - более длительное время компиляции, и что файлы .obj, созданные в этом режиме (LTCG включен), могут быть очень большими. Например, файлы .obj, которые могут быть размером 200-500 КБ, занимали около 2-3 МБ. Просто со мной случилось, что компиляция нескольких проектов в моей цепочке привела к папке размером 2 ГБ, большая часть которой составляла файлы .obj.

0 голосов
/ 14 ноября 2008

Я также не вижу проблем с дополнительным временем компиляции при использовании генерации кода времени компоновки в сборке релиза. Я собираю свою версию выпуска только один раз в день (в одночасье) и использую модульный тест и отлаживаю сборки в течение дня.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...