влияет ли порядок ссылок gcc на скорость выполнения программы

Question

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

g ++ -m32 ao bo ar1.a ar2.a -lm -lpthread -lcrypt -lz -pthread -o afast.out

vs

g ++ -m32 ao ar1.a bo ar2.a -lm -lpthread -lcrypt -lz -pthread -o aslow.out

Вторая версия работает в 2 раза медленнее.bo на самом деле находится в архиве ar1.a, но на ar2.o есть ссылки на него, поэтому компоновщик жалуется, поэтому мне пришлось поставить bo. Сначала я помещал bo до конца связки, чтобы сделатьправильный порядок зависимости, хотя потом выяснил, что он работает даже в начале и даже быстрее.

Кто-нибудь испытывал это?Отличается ли порядок связывания объектных файлов от порядка архивирования?Как может быть какое-либо влияние на скорость?

получение аналогичных результатов с gcc3.4.6 или gcc4.1.2

Answer 1

Там может иметь существенные различия в скорости выполнения в зависимости от того, как объектный код размещен в памяти.В общем, вы хотите, чтобы горячие функции были близко друг к другу, чтобы они не смешивались с холодными функциями, и чтобы ваши Icache и TLB не были загрязнены холодными функциями.Однако маловероятно, что это затронет вас.

Скорее всего, у вас есть некоторые символы, которые разрешаются одним способом в «быстром» исполняемом файле и другим способом в «медленном» исполняемом файле.Порядок библиотек архивов и объектных файлов в командной строке имеет значение , и вы можете в конечном итоге получить некоторый объект из ar1.a по "быстрой" ссылке, тогда как вы извлечете эквивалентный объект из ar2.aв "медленной" ссылке.Возможно, есть неоптимизированный код в ar2.a?

Запуск nm -A ar1.a ar2.a и проверка на наличие каких-либо символов, присутствующих в обоих, будет первым шагом.Затем вы можете попросить компоновщика создать карту ссылок (с -Wl,-M,map.out) и проверить, откуда эти символы на самом деле берутся в двух ссылках.