使用 int 与 int8_t 是否有任何性能差异

Question

我的主要问题是，int 和 int8_t 之间的执行时间有什么区别？

在我正在开发的框架中，我经常阅读代码，其中一些参数在函数中设置为 int8_t，因为“该特定参数不能超出 -126,125 范围”。

在很多地方，int8_t用于通信协议，或者将一个数据包切割成多个字段成一个__attribute((packed)) struct。

但在某些时候，它主要放在那里是因为有人认为使用更接近数据大小的类型会更好，可能会先于编译器考虑。

鉴于代码是在 Linux 上运行，使用 glibc 使用 gcc 编译的，并且内存或可移植性不是问题，我想知道它是否真的是一个好主意，就性能而言。

我的第一印象来自“试图比编译器更聪明总是一个坏主意”的规则（除非你知道在哪里以及如何优化）。

但是，我不知道使用int8_t 是否实际上是性能成本（更多的测试和计算来匹配int8_t 的大小，需要更多的操作来确保变量不会超出范围，等等。 )，或者如果它确实以某种方式提高了性能。

我不擅长阅读简单的asm，所以我没有将测试代码编译成asm来尝试知道哪个更好。

我试图找到一个相关的问题，但我在 int<size>_t 与 int 上发现的所有讨论都是关于可移植性而不是性能。

感谢您的意见。非常感谢解释的组装示例或有关此问题的来源。

Answer 1

当您谈论代码性能时，您需要考虑影响这一点的几件事：

• CPU 架构，更重要的是，cpu 原生支持哪些数据类型（是否支持 8 位操作？16 位？32 位？等等……）

• 编译器，使用知名编译器是不够的，您需要熟悉它：您编写代码的方式会影响它生成的代码

• 数据类型和编译器内在函数：编译器在生成代码时始终会考虑这些，使用正确的数据类型（即使是有符号与无符号问题）也会对性能产生巨大影响。

  “试图比编译器更聪明总是一个坏主意”——这实际上不是真的；请记住，编译器是为优化一般情况而编写的，而您对特定情况感兴趣；尝试比编译器更聪明总是一个好主意。

您的问题实在是太宽泛了，我无法给出“切中要害”的答案（即什么是更好的性能）。唯一确定的方法是检查生成的汇编代码；至少计算代码在这两种情况下执行所需的周期数。但是你需要了解代码才能理解如何帮助编译器。

Answer 2

int 通常相当于 CPU 上寄存器的大小。 C 标准规定，任何较小的类型都必须在使用运算符之前转换为 int。

这些转换（符号扩展）可能代价高昂。

int8_t a=1, b=2, c=3;
 ...
a = b + c; // This will translate to: a = (int8_t)((int)b + (int)c);

如果您需要速度，int 是一个安全的选择，或者使用int_fast8_t（更安全）。如果确切的大小很重要，请使用int8_t（如果可用）。