>> А также в оптимизации значение имеет суммарный конечный результат, а если одни параметры оптимизируются в ущерб других - зачем такая оптимизация нужна.
>
> Открыть секрет? Оптимизация по размеру делается в ущерб производительности почти всегда. И наоборот. Причем именно эти крайности имеют место быть в основном.Ну допустим, здесь я позволил себе допустить небрежность. Следовало сказать не об "одном в ущерб другого". Следовало сказать о балансе в целях оптимизации. Однако высказывание о "суммарном конечном результате" остается в силе.
Про размеры вы совершенно правы. Сейчас Винды в лидерах по быстродействию за счет больших объемов и сложности кода.
И Linux идет по пятам за ними в этом деле.
Об остальных целях оптимизации вы вообще предпочли умолчать.
>> Видите ли, в нормальных ОСях (и даже не только в Юниксах) принято доверять ядру, и не доверять прикладному коду.
>
> Видите ли, к точке сохранения и использования регистров это имеет отношения ровно 0.00.
Значит для вас не имеет. Я уже понял, что вы предпочитаете сохранять регистры, не доверяя это ядру, хотя оно это и так делает. А потом рассуждать об оптимизации.
> Нисколько. Перезагрузка указателя на фиксированную структуру обычно вообще делается с помощью MOV r,imm,
Ну допустим, в этом случае так. Значит видимо в вашем коде преобладают именно статические структуры, когда вам еще на этапе компиляции известно их количество и размеры. Ну да, любители шаблонов С++ любят так развлекаться. А иначе - смотрим далее.
> на динамически распределенную - MOV r,mem, если же структура вся помещается на стеке - никакой перезагрузки не нужно.
Ну а здесь какой выигрыш? В итоге та же память, тот же стек.
Я ведь уже сказал, при оптимизациях надо смотреть на суммарный конечный результат.
Убирая из стека в регистры одно, вы будете вынуждены класть туда другое.
Если еще учесть, что вы предпочитаете сохранять и восстанавливать одни и те же регистры дважды (см. выше и ранее).
> Такое и может быть только в ваших системах. У нормальных систем есть ABI, и оптимизаторы о нем знают.
В "наших" системах это называется "Keep it simple, stupid!".
Т.е. вы искренне верите, что ABI сообщит вам все варианты ветвления кода в ядре в зависимости от текущего состояния процессора и памяти на момент системного вызова, и все это на этапе компиляции.
Оно вам просто сообщит максимальное объединенное множество регистров. Дополнительный источник потенциальных багов. И зачем? Когда ядро все равно в рантайме сохраняет нужные регистры по мере необходимости. Все просто.
> ЗЫ. Последний тезис - про абстрактные сферические в пределах одной программы. При вызовах в ядро переключение контекста все равно сбрасывает очередь.
Я к непорочной целостности очереди вообще никак не апеллировал.
Это вы берете на себя ответственность утверждать, что можете лихо контролировать очередь на этапе компиляции.
Ну да. Для колдовства с очередями сейчас много всяких средств придумано. Только "серебряной пулей" они не являются. Ими еще надо знать когда пользоваться. И результат должен окупать затраты, а не наоборот.
> Опа, iZEN, залогиньтесь.
И это сюда же. Я уже понял, что вы сторонник гадания на кофейной гуще. Так же как с очередью и регистрами.
> Конечно дает. Особенно при инклюзивных кешах, когда любая запись в стек пролетает несколько уровней кеша, и очередь встает колом из-за ожидания доступа в память.
Т.е. вас как-то от этого спасает сохранение регистров в тот же самый стек, да еще и дважды (когда это и так делает ядро).
> В чём? Примеры в студию.
> Дык пруф где?
Это вы так и не привели в студию примеры ваших "хитростей".
Или тотальное использование статических структур - это и есть вся ваша хитрость?
Т.е. рассуждая о всяких там кешах, очередях и регистрах в современных процах, вы по прежнему убеждены, все эти технологии обошли стек стороной.
Резюме.
В традициях DOSовского наследия выжимать скорость любой ценой, используя любые сомнительные методы оптимизации. Когда скорость растет незначительно, зато комбинаторно пухнет сложность как самого кода, так и инструментов, с помощью которых этот код создается.
В традициях же Юниксов - осторожное отношение к оптимизациям. Когда сначала создется правильный код, а уже потом его профилировкой решается, нужно его оптимизировать или нет, и в каких конкретно местах. И не полагаться на интрументы, котрые якобы заранее "все знают", особенно поведение всяких там очередей.
