0

I had a discussion with the team lead who told me that using uintX_t is very problematic and causes performance problems...I can't understand why.... using uint8_t and uint16_t is the same as unsigned char and unsigned short - I don't think that these types use causes performance problems... Exactly as uint64_t is like long...... May be the performance problems can occur with uint128_t etc.. Is it correct or I am missing something...

Upd It is known that unsigned char and unsigned short sizes should not be 8 and 16 in all platforms....Just used classic values.....

4

4 回答 4

4

保证尺寸是主要目的。

这些类型不是为性能问题而设计的。它们是为了保证整数大小在各种系统中是相同的。

例如，当您使用时，int32_t您可以确保在任何代码编译的地方它的大小都是 32 位，但您不确定int.

问题是使用这些保证大小的类型可能会影响性能，int_fastX_t类型可以减少这种不良影响，因为它们保证最小大小。

例如，编译器可以在 32 位机器int中int_fast16_t使用 32 位...

于 2013-11-12T16:06:24.157 回答
2

这是一个“一段字符串有多长”类型的问题。

每当有人提出您关心的这种性质的声明时，请要求查看他们使用的代码以及他们的基准测试结果。然后，您可以判断基准是否适用于您的案例，或许还可以自己运行它们。

换句话说，如果没有反映您的环境和您对这些类型的实际使用的基准，该声明就没有多大价值。可能是您的团队负责人对相关代码库进行了彻底的分析；也可能是他只是“认为”uintX_t会更慢。我们无法知道它是哪一个。

于 2013-11-12T16:07:38.833 回答
1

如果您uint8_t在 32 位处理器上使用 a 可能会遇到性能问题，并且如果数字大于 255，则不需要自动溢出。

原因：编译器可能需要在处理/使用它之前对值应用掩码。

例如 8 位值存储在 32 位寄存器中，您需要与它进行比较，如果您的处理器没有指令仅使用寄存器的低 8 位进行比较，因此编译器必须在进行比较之前应用掩码 0x0000FFFF

这就是为什么你确实有类型：int_least8_t或uint_fast8_t......看看这个页面stdint.h以查看所有可用的类型

于 2013-11-12T16:12:06.667 回答
0

它们是类型，并试图通过保证它们的大小来使某些类型跨平台。特别是它们不会导致性能问题。问题可能在于它们的使用方式（对于 、 和 来说没有什么unsigned int不同unsigned short）unsigned char。

简而言之，你的团队领导是错误的，很可能是彼得原则的直接后果。

于 2013-11-12T16:09:14.240 回答