> У современных процессоров кэши тоже большие.

см. #108.

> примеры где 32-битные системы по скорости лучше 64-битных будут?

см. #108, последний абзац.

> Я думаю что при таком зуде вполне можно что-нибудь объявить ненyжным, чтобы
> не засоряло память и кэши процессора :). Можно какой-нибудь bash например
> расстрелять за то что слишком жирный.

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

>> почти два гигабайта ему вполне достаточно.
> Что за 2 гигабайта? И почему именно 2?

потому что это примерный объем свободной RAM в моей рабочей технике. остальное занято.

> и спасибо если без пушпопов которые в сумме равны NOPам

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

> и являют собой «необходимое зло» (которое вообще не часть логики программы).

прикинь: в любом машинном коде такого «необходимого зла» дофига. иначе «декомпиляция» была бы тривиальной задачей.

> Учитывая сколько регистров у х86 уродца — там не больно пошикуешь, программа
> наполовину состоит из сохранения-восстановления тасуемых в процессе счета регистров.

в x86_64 их не намного больше. и все их надо радостно перезагружать после вызова функции (или не менее радостно терять). а поскольку вызовы функций — дело очень частое, то получается, что ваш x86_64 ВНИЗАПНА! даёт выигрыш только говнокодерам, которые пишут портянки на десять экранов без единого обращения «наружу». гыг. спасибо, в таком разрезе я об этом раньше не думал.

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

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

а регистров у x86_64 не настолько много, чтобы всё было так уж красиво.

> Данный тезис не объясняет тот факт что 64-битные как правило программы быстрее.

настолько, что это вообще глазом не заметно. «ура, мы выиграли целых пять с половиной секунд на тестовом получасовом прогоне!»

> Не, конечно можно накапать море пипеткой, а 64-битную математику — 32-битными
> командами. Но вот оптимальность этого действия вызывает некоторые вопросы.

необходимость тоже. умножение/деление 64 на 32 давно уже одной командой делается. в подавляющем большинстве случаев этого достаточно.

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

см. выше.