使用 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

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 （如果可用）。

Answer 2

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

CPU 架构，更重要的是，cpu 本身支持哪些数据类型（它支持 8 位操作？16 位？32 位？等等...）
编译器，使用众所周知的编译器是不够的，您需要熟悉它：您编写代码的方式会影响它生成的代码
数据类型和编译器内在函数：编译器在生成代码时总是会考虑这些，使用正确的数据类型（即使是有符号和无符号问题）会对性能产生巨大的影响。
“试图比编译器更聪明总是一个坏主意”——这实际上并非如此； 请记住，编译器是为了优化一般情况而编写的，您对特定情况感兴趣； 尝试比编译器更聪明总是一个好主意。

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