> хорошо себе представляете, что должен делать код, если он занимает несколько мегабайт?!Оно реализует туеву хучу замороченной логики, парсинг замороченных протоколов, разбор каких-то эзотерических форматов файлов и уйму всего еще. Да, это - дохрена. Сиплюсплюсники "поймавшие волну" генерят код лучше чем экскаватор грунт ворочает. Бинарь на 4-6 метров для си++'нутых программ обычное дело.
> А теперь скажите какая секция того бинарника уменьшилась в ходе оговоренной оптимизации?
Код, внезапно! LTO при линковке IIRC убивает glue, нужный для экспортирования функций и вызова оных извне. Поэтому линковка кода в 1 большой бинарь, из которого экспорт "внутренних" символов не делается - приносит нехилый выигрыш. И по скорости (вызов функций становится быстрее, особенно если функция дергается часто) и по размеру. К вопросу о том почему не надо плодить библы, если реюз кода не планируется.
> Если речь о секции данных, то мимо. От cache miss это
> не спасет вообще никак - оптимизируйте дальше.
Каким хреном LTO относится к данным? Код сдувается, разумеется. Почему - см выше. Я как-то так не парился, а оказалось - крутая фича, временами дает весьма приятный выигрыш без каких либо усилий. Линковка конечно куда дольше, не отнять. И ресурсов жрет прилично.
> У вас код занимает несколько мегабайт. В какой кеш Вы предлагает его
> запихнуть? Покажите мне этот кеш, я хочу его!
Типовой размер L2/L3 кэшей современных х86 нынче измеряется в *мегабайтах*, с разморозкой вас. А у монстров типа xeon и десятками уже бывает. Ну вот у моего десктопного проца, например, 1024Кб на ядро L2 и 8192Кб общего L3. И да, L3 - таки куда лучше чем DDR3 с его адской латентностью и "где-то там". До мозильщиков вон тоже долшло - они лису с -Os вообще собирают.
> поражает своей технической грамотностью.
Не к чему до..ться - до...сь к формулировкам. Ну или к личности оппонента.
> Собственно, а где Вы взяли такую чушь, что какой-либо код должен умещаться
> в кеш целиком?
Он не "должен", работать будет и без этого. Но если уместится и тасовка кода минимизируется - производительность может прилично подскочить. Правда логично? :)
> Это что же, по вашему, если это так, то все отлично и мы спасены от промахов кеша?
Вопрос в общем то в количестве этих самых промахов. Меньше код - меньше промахов. Попробуй оспорь :). В сферическом случае в вакууме, когда кэша хватило на вообще все и вся - промахов почти не будет. Вот так вот просто и логично.
> (Это Вам домашнее задание)
Ну да, сразу видно бсдшника - пальцы веером. При том что типовой размер кэша современного проца не знает, как и про то что делает LTO.
> В общем случае, бинарник бОльшего размера, с подряд идущими инструкциями, без далеких
> переходов, выходящих за границу линии кеша, лучше обрабатывается кешем,
Если код целиком в кэш не влез - его куски будут дергаться из оперативы по мере промахов, а там латентность уже совершенно конская. А сферический случай в вакууме - это, конечно, круто, но кого это волнует?
> нежели ужатый донельзя бинарник. Префетчеру гораздо проще подгрузить
> в кеш подряд несколько линий, идущих друг за другом блоков памяти,
А еще лучше - если в кэш вгрузится все что используется. Так что промахов в идеальном случае почти не будет. Чем чаще наступает именно этот случай - тем лучше. Вот уменьшение размера кода очень тому способствует.
> нежели поочереди грузить несколько разрозненных
> линий по каждому cache miss (ага, здравствуй tlb miss!).
Вот кэши и делают нынче жиииииирными. Чтобы туда лезло как можно больше. Потому что latancy DDR3 и близко не стоял с кэшатиной.
> профилирование_ полученного кода, а не сравнивать теплое с мягким.
Приколись, оно покажет то что и должно. В среднем по больнице станет лучше, ясен хрен.
