>> потом пройтись по табличке релоков/фиксапов, чтобы адреса в своём коде все поправить
> Относительная адресация

Что относительная адресация? Вот написал ты в своей программе:

printf("Hello, world\n");

Это сведётся к:

call printf

какой адрес у printf? Этот адрес станет известным только в процессе работы динамического линкера. И никакая относительная адресация тебе не поможет.

pic код, как я понимаю, использует глобальную табличку оффсетов, и этот call становится косвенным вызовом, и требует дополнительного обращения к памяти. То есть, во-первых, ту табличку надо заполнить на этапе динамической линковки. Во-вторых, при _каждом_ вызове printf будет дополнительная стоимость для процессора -- обращение к глобальной табличке оффсетов, таким образом процессорный кеш, внезапно, вынужден постоянно эту табличку хранить.

> Как бы это странно не звучало, но статика тоже может. Кеш-то не резиновый. Как процессорный, так и io. Да и так получается быстрее грузить систему с хардов или ещё чего с медленной скоростью чтения или случайного доступа.

Ты замерял этот эффект? Я как-то очень сомневаюсь, что будет быстрее. Во-первых, процессорный кеш инструкций вылетает от любого чиха, и надеятся на то, что переключение процессов его сохранит... Лучше бы не сохраняло, потому как мы знаем о том к каким дырам в процессорах оно приводит. А значит возможность шарить код между процессами -- это антифича.

Во-вторых, дисковый кеш, по-моим наблюдениям, вылетает не из-за кода, а из-за данных. Данных на порядки больше кода, и тормоза там лезут именно из-за данных, которые надо читать с диска. Мне приходилось неоднократно сталкиваться с исследованиями о том, как необходимость взаимодействия с жёстким диском для чтения данных приводит к тормозам. Разного уровня исследованиями, начиная от "гляньте чуваки, у меня программа тормозила, но я тут алгоритм поменял, чтобы он читал в другом порядке, и хоп, она стала тормозить в разы меньше", и заканчивая почти уровнем научной статьи, где использовались различные способы измерений (один подтверждает/опровергает другой), проверялись альтернативные гипотезы, где человек шёл на очень серьёзные меры, чтобы показать, что тормоза возникают именно таким образом, каким он говорит. Мне попадались такие исследования про данные, но я не видел ни одного исследования, которое показывало бы превосходство динамической линковки над статической по скорости выполнения.

Я отмечу, что я не искал специально, может они и есть такие? Но вот тут как раз у меня и возникает вопрос: что ты знаешь, и почему ты думаешь, что ты это знаешь? Тебе известны такие исследования? Сейчас будет очень кстати поделиться ссылками на них. Потому как я в этом месте склонен делать вывод, что отсутствие свидетельств -- это свидетельство отсутствия: если проблему никто не подтвердил измерениями, значит проблемы нет.

>> это можно было сделать статически, причём даже лучше сделать: lto, pgo,
> Это про оптимизацию. Зубилом хлеб не режут, ножём не делают статуи.

Да, это про оптимизацию. Статический линкер может её выполнять, динамический -- нет. Я не знаю, называешь ли ты его зубилом здесь или ножом, и я не очень понимаю, что ты хочешь сказать этой метафорой, но факт в том, что динамический линкер не может в оптимизации.

> Тут немного про другое. Тут про черезмерное использование динамичечкой линковки. И да, со статикой модет работать быстрее. Но это не повод запрещать динамику.

А раст не запрещает динамику. Тебе никто не мешает объявлять extern-символы. Единственное что, есть ограничения на то, что может быть extern. Параметризованную функцию, например, ты не сделаешь extern. В целом, в rust'е, ты можешь создавать API для динамических библиотек, и использовать эти API, но эти API будут выглядеть так, как выглядят API C.