-AG- писал(а):
Есть ли реальные преимущества 64-бит над 32-мя, кроме расширения адресного пространства?
Да.

Не могли бы вы конкретизировать, какие?
Грецкий! писал(а):
В целом, чем больше вычислений с высокой точностью, тем больше прирост. Надо иметь ввиду, что процессор во время игры занимается непосредственно вычислениями далеко не все время (зависит от самой игры).

Я так понимаю, что особенно строгим и точным в матмоделях симуляторам переход на 64-бит пошел бы только на пользу?

Грецкий! писал(а):
-AG писал(а):
Есть ли реальные преимущества 64-бит над 32-мя, кроме расширения адресного пространства?
Да.

Какие, например?
Я кроме увеличения адресного пространства никаких преимуществ не вижу. В своей программисткой практике очень редко сталкивался с необходимостью в 64 битном типе данных. Возможно для каких-то финансовых программ это может помочь, где ещё, даже не знаю. Что касается научных программ, то тут в основном всё вертится вокруг FPU, а на мощность типов double, float и др. битность процессора не влияет. Игровые миры строятся процессором в действительных числах (т.е. здесь тоже важнее FPU), кроме того, в играх больше используются регистры SSEx, которые и так 128 битные и их битность не зависит от битности процессора. Физика - это тоже FPU. Есть, конечно, ещё AI - может там можно что-то выиграть, сомнительно...
А вот расхож памяти увеличится, так как указатели (адреса) теперь 8 байт занимают ...

по теме:
по 64 битам я вижу 2 как минимум очень ценных +
-больше памяти без лишнего геммора
-регистров в 2 раз больше и они в 2 раза шире - больше можно хранить в регистрах не обращаясь к кешу совсем
и один маленький плюс - 64битные данные обрабатываются/могут обрабатываться одной командой вместо... как часто это используется зависит от задачи

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

в общем для себя вижу такую картину - увеличение возможностей использования памяти и скорости части мелких алгоритмов (тут всё сильно зависит от задачи и может действительно быть и 0% прироста а может и >100% достичь если разрядность нужна + новые регистры уменьшат обращение к кешу) за счёт уменьшения производительности _в некоторых/особых_ случаях

это только моё мнение

DenisMak писал(а):
но за это надо платить:
-больший перерасход памяти начиная с указателей ...

Они кодируются RIP'ом в 4 байта как и абсолютные указатели в 32битах. Нет недостатков.
DenisMak писал(а):
-контекст задачи становится больше и переключение его занимает больше времени (это как догадка, нигде не читал про 64битный режим)

используются те же инструкции, благо в них заложен буфер подходящий для 32/64 битн. режимов. А запись 8ми (для целоцичленных) и 8ми для ХММ дополнительных регистров не сильно замедляет дела. Нет недостатков.

+Скорость набирается за счёт конвенции вызовов в 64 битах - стек приложения приблизительно постоянен всегда, как неплавающий буфер, т.е. не приходится перемещать указатель стека и выделять новую память. Очень удобно и быстро.

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

pusha/popa нет в 64 битах. API и конвенции вызова для 64 бит предусматривают передачу первых 4х парамтров как через РОН так и ХММ, либо через те и те одновременно в определённых ситуациях.
Под 64 бит ОС 64 выигрывают у 32 из-за отсутствия WOW переходников, посему никакие рекомендации мол если меньше 3х гигов и проч. не должны смущать. Если писать универсальный код, то перекомпиляции ис-под С/С++ компилера будет достаточно.
size_t, *_PTR, прочие макро- и просто фичи для компилера.