вот это заблуждение - насчет того что нужно очень много памяти чтобы заметить разницу

Во-первых мы имеем больше регистров общего назначения в 64 long mode
А это весьма существенно, ибо в 32 mode этих самых регистров кот наплакал.

Во-вторых - ассемблер в 64-mode другой и система команд другая - более адекватная.
Память конечно остается та же самая, но из-за системы команд чтобы выполнить задуманный алгоритм вам может потребоваться сделать больше операций в 32-битном режиме, чем в 64-битном режиме.

В-третьих вычисления над 64-битным операндами будут быстрее - а это криптография.

В-четвертых я проводил benchmark-тесты на
дохлый Xeon, зато c 4Gb памяти и 2x2 процами
Athlon 64 3000+
под управлением CentOS 5.1 32-bit и 64-bit

В целом в 64-битном режиме считает либо так же, либо быстрее.
Xотя были отдельные тесты где в 32-bit было чуть быстрее чем в 64-bit

Заодно выяснил, что Xeon-ы надо брать большой частоты (за гораздо большие деньги), так как даже старый-старый Athlon 3000+ уделывает Xeon низкой частоты при использовании 1 CPU :)))

А этого что, мало?Вместо постоянного push\pop которое ничего полезного не делает и только греет воздух можно просто поюзать лишние регистры и кроме того если надо работать с 64-бит числами, не надо делать кучу лишних операций с регистрами (коих у х86 и так то не дофига чтобы их лишний раз дергать).

>на данный момент узким местом любой вычислительной системы является память

Дааа?Вот блин, а чудаки в интеле и амд этого и не знают с своими быстрыми 2...3 канальными DDR 2 и 3 и интель вон козыряет что новый процессор дескать сможет полнее использовать bandwidth памяти.Ваши познания кажется отстали на несколько годков.Да, в древней система с одноканальной памятью типа первого DDR на мизерной частоте все так как вы говорите.Только вот с тех пор скорость работы RAM кардинально подросла.

>в 64битный режим быстрее не становятся :)

В *современных* системах а не выкопанных на помойке, RAM зачастую может выдать больше данных чем может обмолотить процессор и там есть запас.В итоге переход на х64 приведет к более полному юзанию bandwidth оперативы просто напросто и замедление за счет бОльшего объема прокачиваемых данных если и будет то весьма незначительное.А вот то что 64-бит режим быстрее молотит 64-бит числа а операции регистр-регистр особенно когда регистры 64 битные и их много а не 32-бит и несколько - быстрее, это думаю очевидно.

>до 4Гб и стандартным офисным софтом - то тут невооруженным глазом
>различий вы и не заметите.

Зато с 5Gb RAM на борту можно наслаждаться тем как практически любая запись на диск изящно и красиво буфферизуется, вообще не тормозя систему ни на йот.

Уху.
В синтетике - есть разница.
Вот только в реальных приложениях разница эта как-то мало ощутима. А почему?
Да потому, что Микрософт опять перемудрил с переключениями режимов с х86-64 на х86 и обратно.
Вот и имеем такую картину - в синтетике на сандре - +10%, в тестах на реальных приложениях.... - +2-3%. А иногда и - 2-3%. :-)
А тут вон стабильный плюс. и не 10, а 45.

    Linux тоже.

> ключи /3gb /pae добавляют только глюков.

    Ну, насчет /3GB -- наверное, все-таки, нет, как и опция ядра Линукса, позволяющая ему адресовать 4 ГБ ОЗУ (BIGMEM, если мне ни с кем не изменяет мой склероз).
    А вот PAE -- таки да (как и опция ядра Линукса, позволяющая ему адресовать 64 ГБ ОЗУ -- HUGEMEM, если опять-таки мой склероз ни с кем не изменяет, которая, впрочем, и отвечает за то, чтобы включить PAE).

    Впрочем, с PAE проблемы практически на всех операционных системах, если периферийные устройства поддерживают DMA, но не поддерживают его 64'х-битный режим. Такие уж вот кривые эти самые Physical Address Extensions.

При желании могли бы судится, но выгоднее дать 100$ редактору сайта, за удаление и молчание.