“char”和“small int”比“int”慢吗？

Question

可能重复：内置类型的性能：char vs short vs int vs. float vs. double 你好。假设你有一个32位处理器。 8位的char和16位的short int类型是否比本地32位的int慢？ 使用64位的long long int呢？

这些数据类型是否默认由硬件支持，还是无论如何都会将它们全部转换为32位数据，使用附加指令来实现？

如果必须存储少量字符，将它们存储为整数不是更快吗？

- Artur Iwan

---

如果你只是存储少量字符，为什么要费心去追求可能的纳秒级差异呢？ - Erik

@Erik：一个变量可能被使用数百万次。你的论点不成立。 - R.. GitHub STOP HELPING ICE

@R.: 并且使用更宽的字符类型可能会增加缓存未命中率。在分析器证明之前，这是毫无意义的优化。 - Erik

CPU会将最近使用的内存位置保存在“快速RAM”中。这个RAM是远比主内存慢得多的缓存。 - Michael Dorgan

优化很重要，学习如何以最快的方式完成事情是一件好事！请停止过早的悲观。 - Researcher

Answer 1

在任何现代实用的计算机上，char、int和long都会很快（可能速度相等）。无论short是否快速，在不同的CPU架构甚至单个架构中的不同CPU型号之间都有所不同。

话虽如此，没有什么好的理由使用小类型来表示单个变量，无论它们的速度如何。它们的语义很容易混淆（由于默认提升为int），并且它们不会节省大量空间（甚至可能不会节省任何空间）。我唯一会使用char、short、int8_t、int16_t等类型的情况是在必须匹配固定二进制布局的数组或结构体中，其中每个变量的大小实际上很重要，比如像素或音频样本。

- R.. GitHub STOP HELPING ICE

---

真的吗？例如，您会使用int来代替signed char作为布尔值吗？ - Spidey

当然。不仅可以生成更小、更快的代码；而且也更符合惯用法。所有返回真值的标准C函数都使用int作为它们的返回类型，在C中所有比较/布尔运算符的值都具有int类型。 - R.. GitHub STOP HELPING ICE

我太倾向于极简设计，以至于认为这样做是正确的。哈哈。从现在开始我会尝试使用这种设计。 - Spidey

@Spidey：我建议不要在本意为布尔型或字符型时使用int。请使用您需要的类型。 - David Stone

还要注意有符号性可能会有影响。例如，Arm处理器早就有了快速加载和零扩展字节的指令，但对于快速加载和符号扩展字节的支持只在后续版本中添加，并且具有更严格的寻址方式。 - plugwash

Answer 2

这取决于指令集中的操作以及编译器。

- Daniel A. White