> Кэши тоже растут

и поэтому надо сильней забивать их мусором!

> По вычислениям остаётся только распараллеливание — и увеличение
> длины регистров — неплохой шаг.

честное слово: у меня нет задач, гиперсложно обсчитывающих массу целочисленых значений. а плавающим числам и вовсе плевать на целочисленые регистры, у них своя подсистема.

> Если уж хочется сократить объем памяти под указатели — есть
> x86–64/x32, хотя пользы от него кот наплакал.

да нет его, увы. пересобирать руками всю систему и скакать по граблям я как-то не особо готов.

> Даже банальным strcpy/memcpy/memcmp хорошеет от наличия 16 регистров вместо 8.

да пофигу им, пофигу. не заметишь ты разницы — разве что если твоя программа два часа ничем другим не занимается, кроме как усердно копирует стомегабайтную строку.

> Большее
> число явно доступных регистров позволяет меньше лазить в память при вычислениях,
> и оперировать бОльшими блоками, что позитивно влияет на кеширование.

ровно в том случае, когда ты упорно оптимизируешь свою числодробилку руками. во всех остальных опять пофигу. а ещё я тебе скажу, что чтение/запись в небольшой регион памяти (как и происходит, когда регистров не хватает) очень дешёвое нынче. да и компилятор делает неплохую работу, чтобы это оптимизировать.

>>> И если 64-битному процу это 1 операция, на 32-битном это выливается
>> …в ту же одну операцию на том же ALU
> Ни разу. Чехарды с внутренним переименованием регистров больше, и не всегда оно
> оптимально в условиях конвееризации.

и всё это по-прежнему нифига не заметно.

не надо мне доказывать, что много регистров — хорошо: я это и так знаю. однако на практике разница в скорости между x86 и x86_64 на десктопе не заметна. а gcc у меня большой проект ещё и медленней собирал, зараза (подозреваю, что у него как раз немножко кончилась RAM).