我应该使用最小的类型吗？

Question

很久以前，我记得你应该总是使用尽可能小的类型来存储你的数据，但是我几乎读到的每一段代码都不会这样做。他们经常在整个地方使用32位整数。

我听说过一个32位值的取值与8位值一样快的原因，但处理器有一些方法可以一次取出几个较小的值..对吗？

所以如果我使用4个字节而不是4个整数，编译器是不是应该优化这个，所以4个字节被提取/存储在一个32位寄存器中？

或者所有这些都只是过早的优化，潜在的性能增益可以忽略不计？

Answer 1

确实过早优化！但是，一旦你正在优化，它也取决于你的架构。例如，在ARM上，内存访问必须是32位对齐的（一些指令可以做到这一点，但他们只是做了32位访问，然后在后台屏蔽/移位）。如果你使用一个字节，编译器通常会给每个'字节'四个RAM的实际字节，所以它可以更快地访问（更不用说CPU会怪你试图访问未对齐的字节，而没有特殊的代码来处理它们）。

有一种说法，使用“廉政”的一切，因为它是CPU的首选大小，但基本上，只要使用你需要的大小的类型，并让有关的优化编译器的担心：d

Answer 2

这取决于。如果您使用的是带有小缓存的小型处理器，那么选择最小的数据大小可能有意义。如果您有大量数据，例如数百万个样本，每个样本需要8位精度，那么使用最小的数据大小是有道理的。在其他大多数情况下，请将其留给编译器。

Answer 3

在32位CPU中，将四个8位字节打包为32位字可以改善内存访问时间，因为可以一次提取四个字节。然而，现在为了操纵单个字节，CPU必须执行额外的移位掩模等。因此，无论如何将4个字节打包成一个字，或者将每个字节解压缩（对于每个8位字节使用32位）具有优点并且利弊。

假设我们正在谈论C或C++，优化编译器通常会做出正确的决定，你，但你可以，如果你都要通过做自己包装成结构明确地控制这种行为，等等

但是，还有其他更好的理由使用与数据域相匹配的类型：清晰性，可维护性等。我认为这些优势在99％的时间里都占据着优势。