我对在面向64位操作系统时何时使用64位整数有疑问。
是否有人做过针对生成代码速度的定量研究？
使用64位整数作为函数或方法的参数是否更好？（例如：uint64 myFunc(uint64 myVar)） 如果我们使用64位整数作为参数，它将占用更多内存，但也许效率会更高。 如果我们知道某个值始终应小于，例如，10。我们仍然要将这个参数设为64位整数吗？
使用64位整数作为返回类型是否更好？ 使用32位作为返回值会有什么惩罚吗？
使用64位整数作为循环变量是否更好？（例如：for(size_t i=0; i<...)）在这种情况下，我认为是的。 使用32位变量作为循环变量会有什么惩罚吗？
使用64位整数作为指针索引是否更好？（例如：myMemory[index]）在这种情况下，我认为是的。 使用32位变量作为索引会有什么惩罚吗？
对于类或结构中不想保存到磁盘等的数据，使用64位整数是否更好？
将bool类型设为64位是否更好？
关于64位整数和浮点数之间的转换，现在使用double是否更好？ 到目前为止，双精度数比单精度数慢。
每次访问32位变量时，是否有惩罚？
谢谢！
我同意@MarkB的观点，但希望在一些问题上提供更详细的解释。
在x64上，有更多的寄存器可用（数量增加了两倍）。因此，标准调用约定默认采用将更多参数放入寄存器中的方式。只要参数数量不过多（通常为4个或更少），它们的类型就不会产生影响。无论如何，它们都会被转换为64位并传递到寄存器中。
即使寄存器中传递了这些64位寄存器，内存中仍然会分配空间。这是出于设计考虑，使其存储位置与多余参数的连续性更加简单。对于多余的参数，无论如何都会将它们放置在堆栈上，因此在这些情况下大小可能很重要。
这个问题对于内存数据结构尤其重要。使用64位而32位足以满足需求的情况将浪费内存，并且更重要的是，占用缓存行的空间。但缓存影响并不简单。如果您的数据访问模式是顺序的，那么当您实际上只需要每个64位量的一半时，您将通过使得一半的缓存无法使用而受到代价。
如果您的访问模式是随机的，那么缓存性能就不会受到影响。这是因为每个访问都占用一个完整的缓存行。
访问小于字长的整数可能会有轻微影响。但是，流水线和多发指令将使得额外的指令（零或符号扩展）几乎总是被隐藏并且不会被观察到。
所有这些的要点很简单：选择与您的问题相关的整数大小。对于参数，编译器可以根据需要进行促进。对于内存结构，通常越小越好。
不要从性能角度考虑大小，而是使用反映它们所包含数据的类型，并相信编译器的优化器会解决这个问题。
如果在开发过程中出现性能问题，请对代码进行性能分析。然后，您可以根据需要进行算法调整，并且如果分析器显示整数操作存在问题，则可以进行不同大小的比较以进行比较。
使用int，并相信平台和编译器的作者已经完成了他们的工作，并选择了最有效的表示方式。在大多数64位平台上，它是32位，这意味着它不比64位类型低效。
<stdint.h>中的*_fast_*类型。 - Paul R