Question

我的主要问题是，执行时间int和int8_t之间是否存在差异？

在我正在研究的框架中，我经常阅读代码，其中一些参数在函数中被设置为int8_t，因为＆＃34;该特定参数不能超出-126,125范围＆＃34;。

在许多地方，int8_t用于通信协议，或将数据包分成多个字段为__attribute((packed)) struct。

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

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

我的第一印象来自规则＆＃34;试图比编译器更聪明一直是个坏主意＆＃34; （除非您知道需要优化的位置和方式）。

但是，我不知道使用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位？等等）
编译器，使用众所周知的编译器是不够的，您需要熟悉它：它们编写代码的方式会影响它生成的代码
数据类型和编译器内在函数：在生成代码时，编译器始终会考虑这些内容，使用正确的数据类型（即使是已签名和未签名的事务）也会对性能产生巨大影响。

＆＃34;试图比编译器更聪明总是一个坏主意＆＃34; - 事实并非如此;记住，编译器是为了优化一般情况编写的，并且您对特定情况感兴趣;尝试比编译器更聪明是一个好主意。

你的问题非常广泛，我可以提出一个问题＆＃34;回答（即明智的表现更好）。确切知道的唯一方法是检查生成的汇编代码;至少计算代码在两种情况下执行所需的周期数。但是您需要了解代码以了解如何帮助编译器。