> У современных процессоров кэши тоже большие.см. #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-битные программы как-то быстрее получаются
> обычно.
см. выше.
