我怀疑在针对64位操作系统时何时使用64位整数。
有没有人做过关于生成代码速度的结论性研究？
最好使用64位整数作为funcs或方法的参数？ （例如：uint64 myFunc（uint64 myVar）） 如果我们使用64位整数作为参数，则需要更多内存，但可能会更高效。 如果我们知道某个值应该总是小于，例如10，那么我们仍然继续使用64位整数作为此参数？
最好使用64位整数作为返回类型？ 使用32位作为返回值会有一些惩罚吗？
最好使用64位整数进行循环？ （for（size_t i = 0; i＆lt; ...））在这种情况下，我想它。 使用32位变量进行循环会有一些惩罚吗？
最好使用64位整数作为指针的索引？ （例如：myMemory [index]）在这种情况下，我想它。 对索引使用32位变量会有一些惩罚吗？
最好使用64位整数在类或结构中存储数据？ （我们不想保存到磁盘或类似的东西）
最好将64位用于bool类型？
64位整数和浮点数之间的转换怎么样？现在使用双打会更好吗？ 到目前为止，双打比漂浮慢。
每次访问32位变量时都会受到一些惩罚吗？
问候！
答案 0 :(得分：4)
我同意@MarkB，但希望提供有关某些主题的更多详细信息。
在x64上，有更多寄存器可用（两倍）。因此，标准调用约定被设计为默认情况下在寄存器中采用更多参数。因此，只要参数的数量不过多（通常为4或更少），它们的类型就没有区别。 无论如何，它们将被提升为64位并传入寄存器。
即使它们在寄存器中传递，也会在堆栈上为这些64位寄存器分配空间。这是为了使它们的存储位置简单且与剩余参数的存储位置相邻。多余的参数将被放置在堆栈中，因此在这些情况下大小可能很重要。
此问题对于内存数据结构尤为重要。使用32位足够的64位将浪费内存，更重要的是，占用缓存行中的空间。缓存影响并不简单。 如果您的数据访问模式是顺序的，那么您将通过基本上使一半缓存无法使用来支付费用。 （假设您只需要每个64位数量的一半。）
如果您的访问模式是随机的，则对缓存性能没有影响。这是因为无论如何每次访问都占用一个完整的缓存行。
访问小于字大小的整数会产生很小的影响。然而，流水线操作和多个指令问题将使得额外的指令（零或符号扩展）几乎总是被完全隐藏并且不被观察到。
所有这一切的结果很简单：选择对您的问题很重要的整数大小。对于参数，编译器可以根据需要进行推广。对于内存结构，通常更小。
答案 1 :(得分：3)
您已设法将吨问题填入此处的一个问题中。在我看来，所有问题基本上都与微观优化有关。因此，我将分两部分回答：
不要从性能角度考虑大小，而是使用指示它们将包含的数据的类型，并信任编译器的优化器来对其进行排序。
如果在开发过程中某些时候性能成为问题，请对代码进行概要分析。然后，您可以根据需要进行算法调整，如果分析器显示整数操作导致问题，您可以并排比较不同的大小以进行比较。
答案 2 :(得分：0)
使用int并信任平台和编译器作者他们已完成工作并为其选择最有效的表示。在大多数64位平台上，它是32位，这意味着它的效率不低于64位类型。