LINUX.ORG.RU

LTO для нескольких проектов/библиотек одновременно

 , , ,


4

4

Будет ли разница, если я скомпилирую 3 библиотеки с lto отдельно; и если скомпилирую их вместе? Что делать, если нет возможности объединить два проэкта? Как заставить lto продолжить оптимизацию в совокупности со всеми слинкованными библиотеками (которые также были скомпилированны с lto, но автономно)? А то я сильно удивился, когда скомпилил основной проект с LTO и производительность не изменилась ни на грамм. А там куча зависимостей, к которым я не применил LTO, и я не знаю, как применить его ко всем библиотекам сразу.

Большинство зависимостей можно статически связать с моей программой, но некоторые нельзя. В каком случае можно сделать общий LTO, если его вообще можно сделать, и как?

Можно ли то же самое провернуть с PGO? (Тоже почти не заметил разницы из-за этого, она была 1%, где-то в лучшую где-то в худшую сторону).



Последнее исправление: gradle (всего исправлений: 2)

Вся информация есть в RTFM: статические библиотеки, одинаковые флаги, -fvisibility=hidden. Лучше еще -fno-fat-lto-objects и -flto-odr-type-merging.

Разница будет (как в скорости, так и в размере кода) от 0.1% до нескольких раз. Но конечно зависит от исходной ситуации.

Deleted
()
Ответ на: комментарий от Deleted

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

gradle
() автор топика
Ответ на: комментарий от Deleted

Где visibility hidden писать? В каждой зависимости при сборке с lto? А как они потом линковаться будут то? Функции же удалены.

gradle
() автор топика
Ответ на: комментарий от gradle

Ты чётко объясни, что писать в флагах зависимостей статических (что в cflags что в ldflags), и что в финальной сборке/линковке их вместе?

gradle
() автор топика

Будет ли разница, если я скомпилирую 3 библиотеки с lto отдельно; и если скомпилирую их вместе?

Библиотеки статические или динамические?

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

Для статических библиотек достаточно собрать их с -flto (скорее всего они должны быть собраны той же версией GCC, которая используется для сборки основного приложения).

Что делать, если нет возможности объединить два проэкта?

Не использовать динамические библиотеки…

anonymous
()
Ответ на: комментарий от yugr

Так по отдельности это в 2 раза медленнее чем сразу все вместе. Как их вместе обработать? Чтобы функции из одной библиотеки приставлялись к другой

gradle
() автор топика
Ответ на: комментарий от yugr

Один профиль на все библиотеки так скажем, а не каждую по отдельности, меня такая производительность не устраивает

gradle
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.