>Выгода только на очень узком множестве задач, Это узкое множество задач - везде где переменные не влезают в 32 бита.А это ... ну, например, любая современная файловая система позволяет файлы крупнее 4Gb.А это автоматически означает работу с 64-битными числами.А как еще адресовать данные за пределами 2^32? :)
>где голая математика и минимум обращений к памяти.
Память в современных системах не является узким местом AFAIK.Как ни странно.
>В общем же случае пофик - что add+addc,
В х86 поскольку регистров не дофига только этим не отделаетесь.Придется скорее всего еще push-нуть регистры, потом pop-нуть.Ну и так далее.Сколько оно там займет времени и лишнего кода - тот еще вопрос.Посему когда заходит вопрос об интенсивных 64-битных вычислениях, х86 в 32-битном режиме заметно сливает.Что впорчем неудивительно - быстрее хардварного выполнения операций "в лоб" в равноправных регистрах трудно что-то придумать.
>что addq выполнятся мгновенно по сравнению с обращениями к памяти.
У современной многоканальной оперативки как правило нет никаких проблем накормить ядро инструкциями и данными до предела его возможностей.Ее bandwidth хватает с запасом а на остальное есть префетч и кеши, как раз для компенсации латентностей.В результате на современных системах с быстрой 2-3 канальной памятью и неслабыми кэшами имхо еще вопрос пофиг это или нет.Судя по тому что оптимизация архитектуры процессора дает большой эффект (как в случае кор2) - времена выполнения команд и т.п. все-таки не пофиг.
>Распараллеливание инструкицй тоже никто не отменял,
А еще у х64 регистров здорово больше.Равноправных при том.Как бы тоже вместо долгой и нудной перетасовки чисел туда-сюда в нескольких куцых 32-битных регистрах можно все сделать в нескольких 64-битный регистрах чисто аппаратно.При том на каждое 64-битное действие на 32-битном проце потребуется довольно много операций.Add + Adc это конечно круто а ничего что содержимое регистров при этом сменится?Совсем не факт что старое было нафиг не нужно.Да и результат куда-то придется девать потом если регистры еще для чего-то нужны.А в х64 регистров может хватить на все и без нудных push\pop пачками...
>так что в итоге прироста там - от силы несколько процентов.
От задачи зависит очень.
>Да что ты? А `не дурные' 64битные регистры не надо значит сохранять/восстанавливать?
А их больше.Поэтому нужда сохранить регистры в стэк возникает гораздо реже.Например вызов функции.В x86 push параметров в стэк вызывающим и pop на стороне функции, тут все понятно - куцесть регистров ведет к неизбежному срачу в стэк и потом разгребанию оного.Ну и локально в функции придется возможно не раз пихать регистры в стэк если надо что-то посчитать а промежуточные значения регистров были не пофигу.Неизбежно придется сделать эти бесполезные действия потому что регистров элементарно мало и на все параметры и временные переменные 1 фиг как правило не хватит.А в х64 можно параметры тупо в регистрах передать а если повезет то незаюзанных регистров еще на временные локальные переменные останется.По-моему (боюсь соврать, гуру поправьте) если параметров у функции мало - х64 компилеры в этом случае не юзают стэк обходясь сугубо регистрами передавая функциям параметры в них.
