KhodL1/L2/L3Например, чтобы делать ставку на алгоритм требующий низкой латености либо на требующий высокой пропускной способности, чтобы спрогнозировать скорость их работы, чтобы выбрать оптимальный CPU.

Вы на ассемблере писать будете?
Знание поддерживаемых инструкций, частоты процессора и размера кеша третьего уровня вполне достаточно.Недостаточно. Без знания алгоритма работы кешей и архитектуры процессора писать оптимальные программы невозможно. Программы, понятно, не бухгалтерские на интерпретируемых байт-кодах.
KhodТак что смысл?Да может человеку просто интересны компьютеры и процесоры. Вон, люди интересуются спортивными автомобилями, а ведь на спорткаре за милион хлеб их булошной быстрее не привезёшь...
L1/L2/L3А где можно найти технические характеристики по пропускной способности и задержкам кэшей L1/L2/L3 современных CPU x64?Вот некие азы, для начинающего программиста (серия из 4-х статей):
http://www.ixbt.com/cpu/sandy-bridge-1.shtml
Далее копать самому...

KhodalexeyvgДа может человеку просто интересны компьютеры и процесоры. Вон, люди интересуются спортивными автомобилями, а ведь на спорткаре за милион хлеб их булошной быстрее не привезёшь...

Спорткар разобрать можно, а процессор - ни-ни.Спорткары тоже не разбирают, по крайней мере, не чаще, чем процессоры (да, процессор тоже можно разобрать, срезая слои и исследуя микроскопом, делают и такое)

Вы почитайте статьи по ссылке, там описано, как можно сделать реверс-инженеринг процессора без его разборки.

KhodСмыл оптимизировать? Неужели эти задачи важнее задач для суперкомпьютеров 30-летней давности?Важность задачи определяется мотивацией выполняющего её человека. Почему бы не оптимизировать игру, если за это платят деньги и вообще игры - это большой рынок (может быть, более жирный, чем производство оружия)?

А глобально... Неужели радость ребёнка от игры менее важна, чем максимизация количества трупов от взрыва ядерной бомбы? Хотя для кого как, программерам первых суперкомпьютеров менее, это типа лоховство - игры писать :-(

KhodКак я уже писал выше, следует обратить внимание на поддерживаемый набор интструкций и оптимизировать под них.
Это куда важнее всяких задержек кешей.Я думаю, важна вся архитектура процессора, в т.ч. (но не только) работа кеша. Знания инструкций ИМХО совершенно недостаточно.

rahzerА затачивать конкретно под проц - хм, каждые два года смена поколений\линеек, а если вообще клиент амд возьмет?Я думаю, игро и кодеко писатели так и делают. Тем более что нужно работать не над всем кодом, а только над расчётным ядром. Прямо для каждого процессорного ядра делают ветки програмного ядра.

KhodТакого опытного работника днём с огнём не сыщешь.Ага, "ИТ загибается" :-)

KhodА если проц сдохнет и такой уже выпускаться не будет? Что тогда? Писать ПО заново? И менять весь парк техники?Ветки делают в коде, зачем старое выкидивать?

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

KhodalexeyvgЯ думаю, игро и кодеко писатели так и делают. Тем более что нужно работать не над всем кодом, а только над расчётным ядром. Прямо для каждого процессорного ядра делают ветки програмного ядра.

Тогда почему ПО не летает, а с выходом нового релиза работает всё медленнее и медленнее на том же железе?Как правило, просто из за упаковки новой функциональности. Хотя даже при этом в критических местах производительность реально увеличивается.

Это же очевидно - код специально не ухудшают от релиза к релизу, и заново тоже не переписывают, похуже (не потому что все белые и пушистые, а просто глупо на это тратить деньги).

Простой код при этом не улучьшается, потому как достиг предела (не считая оптимизации под новые наборы интсрукций и архитектуру), а сложный код оптимизируют, и он реально работает быстрее. Посмотрите хотя бы эволюцию СУБД, файловых систем, сетей передачи данных (возмьите для примера модемы 20-ти летней давности и ADSL - это же чисто софтовый прогресс) ...