嗯，一个明显的缺点是你必须移动更多的位。鉴于内存访问是当今的一个严重问题[1]，为相当数量的操作移动两倍的内存并不是一件好事。
但是这样的效果到底有多糟糕，真的吗？是什么弥补了它？或者我应该在 32 位机器上运行我所有的小应用程序？
我应该提一下，我正在考虑特别是在同一台机器上可以选择运行 32 位或 64 位的情况，因此在任何一种模式下，主内存的带宽都是相同的。
[1]：甚至在十五年前，就此而言。我记得很久以前就谈到过良好的缓存行为，尤其是赢得所有基准测试的 Alpha CPU 在当时拥有巨大的 8 MB 二级缓存。
你的应用程序是否应该是 64 位的，很大程度上取决于它执行的计算类型。如果需要处理非常大的数据集，显然需要 64 位指针。如果不是，您需要知道您的应用程序是否花费相对更多的时间进行算术或内存访问。在 x86-64 上，通用寄存器不仅宽两倍，数量也多一倍，而且更加“通用”。这意味着 64 位代码可以具有更好的整数运算性能。但是，如果您的代码不需要额外的寄存器空间，由于缓存效率的提高，您可能会通过使用更小的指针和数据来获得更好的性能。如果您的应用程序以浮点运算为主，则将其设为 32 位可能没有多大意义，因为无论如何大多数内存访问都将用于宽向量，
大多数 64 位编程环境使用“LP64”模型，这意味着只有指针和long int变量（如果您是 C/C++ 程序员）是 64 位的。整数 ( ints) 保持为 32 位，除非您使用“ILP64”模型，这并不常见。
我之所以提出它，是因为大多数int变量没有被用于size_t类似的目的——也就是说，它们保持在 32 位舒适的范围内。对于这种性质的变量，您将永远无法区分。
如果您正在使用 > 4GB 的数据进行数字或数据繁重的工作，那么无论如何您都需要 64 位。如果你不是，你不会注意到区别，除非你习惯long在大多数人使用 s 的地方使用ints。
我认为您从这里的错误假设开始。你说：
为相当数量的操作移动两倍的内存不是一件好事
第一个问题是问“为什么不”？在真正的 64 位机器中，数据路径是 64 位宽，因此移动 64 位所需的周期数与在 32 位机器上移动 32 位所需的周期数完全相同。所以，如果你需要移动 128 个字节，它所花费的周期是 32 位机器上的一半。