Как определить порядок самой быстрой ссылки?
У меня есть около 50 различных статических библиотек, связанных с моим проектом на C ++, и связывание занимает в среднем 70-е годы.
Я обнаружил, что на этот раз изменение порядка следования библиотек меняется. Я предполагаю, что это ожидаемо, если компоновщик не должен продолжать поиск набора символов по всей таблице символов, которую он построил до этой точки.
Я полагаю, что мог бы использовать «nm» для получения графика зависимости между статическими библиотеками. Однако это дало бы мне только один «правильный» порядок ссылок. Каковы будут факторы, влияющие на получение заказа самой быстрой ссылки?
Я чувствую, что это будет иметь какое-то отношение к вышеупомянутому графу зависимостей, получая обход, который попытается минимизировать некоторое количество, но я действительно не уверен, какой.
Любая помощь будет оценена.
Я в основном время от времени использую компилятор intel, а также компилятор gcc. Кажется, что они оба используют компоновщик GNU ld, когда я проверяю его с помощью top. Надеюсь это поможет…
Так что, чтобы прояснить немного больше о том, что я пытаюсь спросить, я уже знаю, как получить 1-проходный порядок из набора статических библиотек. Я сам написал этот сценарий, но, как показывает ответ Олафа ниже, для этого есть хорошо известные инструменты.
У меня такой вопрос, у меня уже есть два порядка 1-проходных ссылок, один из которых выполняется в ~ 85 с, а другой — в ~ 70 с. Ясно, что есть еще некоторая оптимизация, которую мы можем выполнить в рамках однопроходных заказов.
Решение
В качестве альтернативы, почему бы не попробовать скомпилировать ваши библиотеки в общие библиотеки, а не в статические библиотеки?
Там, где я работаю, время соединения одного крупного проекта составляло около 6 минут, это было только для 5 библиотек!
Моим решением было (для отладочной версии) создание файлов .so в алфавитном порядке (libA.so, libB.so и т. Д.), Чтобы каждая отдельная ссылка не была слишком длинной, а конечная ссылка была намного короче, поскольку все (частичные) ссылки было сделано ранее. Релизная версия была построена по старинке, потому что с моим новым методом возникла «опасность».
Мне удалось сократить цикл компиляции / компоновки из 1 модуля с 6 минут до 10 секунд, используя этот метод.
Другие решения
В прошлом порядок объектов в статической библиотеке был важен. Вы можете сортировать объекты соответственно с:
$ lorder * .o | tsort
Может быть, вы могли бы сделать то же самое с вашими основными объектами и библиотеками, например lorder main.o test.o libsome.a libthing.a | tsort, смотреть на мужик
На основании информации сравнивая лд с золотом, на скорость ld влияет размер таблицы символов. По мере роста таблицы символов при обработке объектных файлов, тем медленнее становится шаг ссылки. Таким образом, если у вас есть два разных порядка однопроходного связывания, тот, который помещает библиотеки с большим количеством символов для последующего исправления в этом порядке, должен связываться быстрее. Вы должны иметь возможность изменить топологическую сортировку, включив количество символов в критерии упорядочения.
Вы говорите об однопроходном упорядочении, основанном на порядке объектов и библиотек, но если он ищет в статической библиотеке, он не может гарантировать, что что-либо в статической библиотеке будет в каком-то конкретном порядке, и на самом деле вы можете контролировать только это. заказав статическую библиотеку определенным образом, когда вы ar Это.
Кроме того, без понимания того, как компоновщик использует статический библиотекарь (да), можно сделать два лучших предположения:
- Он создает хеш-таблицу символов, которая ссылается на объект (ы), которые предоставляют или нуждаются в них; если это точное предположение, то лучшая нижняя граница, которую вы можете получить для статической библиотеки, — это время, необходимое для заполнения такой хеш-таблицы и чтения из нее.
- Он читает вслепую из архива на основе порядка, указанного в индексе архива.
В качестве попытки найти нижнюю границу для вашего оптимального времени соединения попробуйте связать все или подмножество объектов в архиве (ах) как перемещаемый объект; для подмножества, если возможно, идентифицируйте все объекты, фактически связанные в.
Справочная страница для lorder означает, что вы можете получить те же результаты с ar ts <archive> … который напечатает упорядоченный список для вас. Справочная страница для ar кажется, указывает на бег ar с s Флаг автоматически сохранит этот оптимальный порядок в индексе архива.
Кроме того, помните, что потенциально могут быть циклические зависимости, хотя, если вы уже испортили tsort Вы должны были уже знать об этом.
Наконец, я оставлю вам последнюю часть информации. То, что вы хотите, это то, что может решить NP-полную проблему. Удачи.
В последнее время я проводил некоторые тесты синхронизации для сборки, над которой я работаю; Я добавил s флаг моей ARFLAGS чтобы увидеть, какой эффект это имеет.
В целом, похоже, это увеличило время моей сборки, но я считаю, что есть логическое объяснение, почему:
- Большинство исполняемых файлов / общих объектов не используют статические ссылки
- Он строит PIC и не PIC версии каждой статической библиотеки.
Если бы мы более интенсивно использовали статические библиотеки, мы, вероятно, увидели бы выгоду от этого.