kdvнасчет оптимизации игр под кэши и прочее.
Оптимизация скорее выполняется под какой-то набор инструкций, которые раньше были только на части процессоров, а теперь практически на всех. Под кэши игры оптимизировать можно, но гляньте вот сюда:
http://store.steampowered.com/hwsurvey/
тут речь идет про статистику как минимум с 5 миллионов игровых компьютеров
и ткните в процессоры
http://store.steampowered.com/hwsurvey/processormfg/

так что, не думаю, что разработчики игр убиваются про оптимизацию кэша. Вот какие-нибудь математические пакеты - это да, там такое может быть оправдано.
Ну да, подавляющее большинство от 2.3 до 3.3 GHZ. Но как из этого следует что под кэши не оптимизируют?
Допустим почему оптимизируя под архитектуру Sandy Bridge не учесть помимо прочего и то, что у кэшей L1/L2 задержки стали больше относительно предыдущей архитектуры Nehalem, а у кэша L3 задержки стали меньше?

И кстати, совершенно очевидно, что и дальше приоритетом будет понижение задержек L3, т.к. это является узким звеном межъядерной синхронизации.

miksoftL1/L2/L3Но как из этого следует что под кэши не оптимизируют?Игры - обычно не оптимизируют. Для легких (indie) игр в этом нет смысла, а у "тяжелых" цикл разработки зачастую больше, чем цикл выхода нового семейства процессоров. Т.е. к моменты выхода на рынок основная масса процессоров может оказаться уже другой.

Самым правильным выходом (за исключением штучных не серийных разработок) мне кажется использование готовых библиотек, которые уже оптимизируются под разные семейства процессоров, например, та же Intel IPP. Вот там, действительно, есть отдельные ветки кода для разных семейств CPU.
Ну во-первых есть предсерийные образцы и критические места оптимизируются всегда перед выходом продукта, т.к. для выявления их нужно профилирование готового проекта.
А во-вторых есть патчи, которые выходят уже после и добавляют ветки под новые CPU.

А насчет IPP, да согласен, предпочтительней использовать готовые хорошо оптимизированные библиотеки. Так же для удобного распараллеливания по ядрам можно использовать TBB и OpenMP.

kdvL1/L2/L3критические места оптимизируются всегда перед выходом продукта, т.к. для выявления их нужно профилирование готового проекта.
перед выходом проекта уже ничего не оптимизируется. потому что на этапе Release Candidate, не говоря про Beta version только исправляются ошибки.
А бывают патчи выходящие после игры добавляющие оптимизированные ветки для новых CPU?

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

kdvL1/L2/L3А бывают патчи выходящие после игры добавляющие оптимизированные ветки для новых CPU?
понятия не имею. я только знаю, что для СУБД оптимизацию кэшей процов не используют :-)

Именно в Firebird или в СУБД в принципе? :)

iv_an_rukdvу СУБД обычно приоритеты производительности в таком порядке - диск, память, проц.
Диск, сеть, выделения памяти, мьютексы и прочие принудительные переключения нитей, префетч памяти, NUMA-эффекты на кэше .
Что значит "оптимизировать проц" я не вполне понял. Если надо сложить 3 и 4, то это надо сделать и всё тут.
"NUMA-эффекты на кэше" - ну тут наверное больше сыграет задержка QPI/HT/Infiniband нежели характеристики самого кэша?