> Код, внезапно! LTO при линковке IIRC убивает glue, нужный для экспортирования функций
> и вызова оных извне. Отнюдь не это делает lto - с домашним заданием ты не справился. Гуглить gimple!
Что? О каком экспортировании функций ты говоришь?! А ну-ка,
$ nm <бинарник>
$ size <бинарник>
до и после твоей lto оптимизации.
>> Если речь о секции данных, то мимо. От cache miss это
>> не спасет вообще никак - оптимизируйте дальше.
> Каким хреном LTO относится к данным? Код сдувается, разумеется. Почему - см
> выше. Я как-то так не парился, а оказалось - крутая фича,
> временами дает весьма приятный выигрыш без каких либо усилий.
Каким хреном lto относится к данным? Никаким, но должен же я убедиться, что мой оппонент хоть малейшее представление об lto.
Разумеется, дает выигрыш в _размере_кода_. Дает ли (дало ли) какой-то выигрыш в твоем случае? Сомневаюсь. А ты можешь его измерить? Ты, помнится, о cache miss говорил?
> Типовой размер L2/L3 кэшей современных х86 нынче измеряется в *мегабайтах*, с разморозкой
Ой... а я забыл, что есть такой процессор, x86/x86_64...
> Не к чему до..ться - до...сь к формулировкам. Ну или к личности
> оппонента.
Дорогой мой неразумный друг, напомню, et hominem исходило от тебя, буквально в первом же ответе на мое замечание. В том посте, напоминаю, я указал на безграмотность твоих доводов относительно корреляции размера кода и частоты cache miss. Чуть позже я призвал тебя провести профилирование кода (сам то знаешь, как это сделать?), чтобы определить эту частоту. Или ты и дальше будешь сводить все к личностям?
Профилировать твой код я не могу - нет его у меня, и не буду - твой код, ты и профилируй, потому привожу общие соображения относительно оптимизации и указываю на твои заблуждения. (Не отрицаю, может частота cache miss и уменьшилась, но это тем интереснее, так как это side effect, который требует особого внимания) У тебя код есть, но ты, вместо того, чтобы показать мне конкретные результаты, громко кричишь, про разного рода доводы, хотя понятия не имеешь ни о работе cache, ни о работе tlb.
> Он не "должен", работать будет и без этого. Но если уместится и
> тасовка кода минимизируется - производительность может прилично подскочить. Правда логично?
> :)
Тасовка? Это еще один технический термин, применимый в ключе работы кешей? Тасовка чего, с чем, где? Что хотел сказать автор? :-D
>> Это что же, по вашему, если это так, то все отлично и мы спасены от промахов кеша?
> Вопрос в общем то в количестве этих самых промахов. Меньше код -
> меньше промахов. Попробуй оспорь :). В сферическом случае в вакууме, когда
> кэша хватило на вообще все и вся - промахов почти не
> будет. Вот так вот просто и логично.
Кеш все равно меньше общего объема памяти, все равно он многократно вытесняется. О том, что влияет на cache miss ниже и в предыдущих постах.
>> (Это Вам домашнее задание)
> Ну да, сразу видно бсдшника - пальцы веером. При том что типовой
> размер кэша современного проца не знает, как и про то что
> делает LTO.
Сюрприз! Я Linux Kernel программист. Более того, речь я веду только о gcc и linux, чтобы тебе было проще :-)
> Если код целиком в кэш не влез - его куски будут дергаться
> из оперативы по мере промахов, а там латентность уже совершенно конская.
> А сферический случай в вакууме - это, конечно, круто, но кого
> это волнует?
Они (куски) и так будут дергаться. Ну не живет какое-то одно приложение, без соседства с другими. Еще раз, читай что тебе написал: к промахам приводит не излишне большой размер кода, а частые переходы за границы линии кеша. Именно поэтому код, имеющий бОльший размер не обязан увеличивать частоту промахов, важно то, как компилятор организовал work flow.
> А еще лучше - если в кэш вгрузится все что используется. Так
> что промахов в идеальном случае почти не будет. Чем чаще наступает
> именно этот случай - тем лучше. Вот уменьшение размера кода очень
> тому способствует.
Опять ты про tlb забыл :-D
> Приколись, оно покажет то что и должно. В среднем по больнице станет
> лучше, ясен хрен.
Ну? Я жду.
