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

Question

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

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

против

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) и проверьте, откуда эти символы на самом деле берутся в двух ссылках.