intXX_t 和 int_fastXX_t 有什么区别？
我最近发现了标准最快类型的存在，主要是 int_fast32_t 和 int_fast64_t。
我总是被告知，为了在主流架构上正常使用，最好使用经典的 int & 。 long 应始终适合处理器的默认读取能力，从而避免无用的数字转换。
在 C99 标准中，§7.18.1.3p2 中写道：
“typedef 名称 int_fastN_t 指定宽度至少为 N 的最快有符号整数类型。typedef 名称 uint_fastN_t 指定宽度至少为 N 的最快无符号整数类型。”
§7.18.1.3p1 中也有一段关于它的引用：
“不能保证指定类型在所有用途上都是最快的；如果实现没有明确的理由选择一种类型而不是另一种类型，它只会选择一些满足符号性和宽度要求的整数类型。”
我不清楚最快的真正含义。我不明白什么时候应该使用这种类型，什么时候不应该使用这种类型。
我在谷歌上搜索了一下，发现一些 open 来源 项目已将其部分功能更改为它，但不是全部。他们并没有真正解释为什么他们改变了一部分，并且仅他们的代码的一部分。
您知道 int_fastXX_t 确实比经典更快的具体情况/用法是什么吗？
I have recently discovered existence of standard fastest type, mainly int_fast32_t and int_fast64_t.
I was always told that, for normal use on mainstream architecture, one should better use classical int & long which should always fit to the processor default reading capacity and so avoid useless numeric conversions.
In the C99 Standard, it says in §7.18.1.3p2 :
"The typedef name int_fastN_t designates the fastest signed integer type with a width of at least N. The typedef name uint_fastN_t designates the fastest unsigned integer type with a width of at least N."
And there is also a quote about it in §7.18.1.3p1 :
"The designated type is not guaranteed to be fastest for all purposes; if the implementation has no clear grounds for choosing one type over another, it will simply pick some integer type satisfying the signedness and width requirements."
It's unclear to me what fastest really means. I do not understand when I should use this type and when I should not.
I have googled a little on this and found that some open source projects have changed some of their functions to it, but not all of them. They didn't really explain why they have changed a part, and only a part, of their code to it.
Do you know what are the specific cases/usages when int_fastXX_t are really faster than the classical ones ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在 C99 标准中，7.18.1.3 最快的最小宽度整数类型。
和
类型
int_fastN_t和uint_fastN_t对应于精确宽度整数类型intN_t和uintN_t。该实现保证它们至少占用N位，但如果它可以使用更大的类型执行优化，则该实现可以占用更多位；它只是保证它们至少占用。 unsigned例如，在 32 位计算机上，
uint_fast16_t可以定义为unsigned int而不是Short因为使用机器字大小的类型会更有效，它们存在的另一个原因是精确宽度整数类型在 C 中是可选的，但最快的最小宽度整数类型和最小宽度整数类型。 (
int_leastN_t和uint_leastN_t) 是必需的。In the C99 Standard, 7.18.1.3 Fastest minimum-width integer types.
and
The types
int_fastN_tanduint_fastN_tare counterparts to the exact-width integer typesintN_tanduintN_t. The implementation guarantees that they take at leastNbits, but the implementation can take more bits if it can perform optimization using larger types; it just guarantees they take at leastNbits.For example, on a 32-bit machine,
uint_fast16_tcould be defined as anunsigned intrather than as anunsigned shortbecause working with types of machine word size would be more efficent.Another reason of their existence is the exact-width integer types are optional in C but the fastest minimum-width integer types and the minimum-width integer types (
int_leastN_tanduint_leastN_t) are required.Gnu libc 定义 {int,uint} _fast{16,32}_t 在为 64 位 CPU 编译时为 64 位，否则为 32 位。在 Intel 和 AMD 64 位 x86 CPU 上，64 位整数的操作比 32 位整数的相同操作更快。
Gnu libc defines {int,uint}_fast{16,32}_t as 64-bit when compiling for 64-bit CPUs and 32-bit otherwise. Operations on 64-bit integers are faster on Intel and AMD 64-bit x86 CPUs than the same operations on 32-bit integers.
可能不会有什么区别，除非在特殊的硬件上，
int32_t和int16_t甚至不存在。在这种情况下，您可以使用
int_least16_t来获取可包含 16 位的最小类型。如果您想节省空间，这可能很重要。另一方面，使用 int_fast16_t 可能会得到另一种类型，比 int_least16_t 更大，但对于“典型”整数使用可能更快。实施必须考虑什么是更快的以及什么是典型的。也许这对于某些特殊用途的硬件来说是显而易见的？
在大多数常见的机器上，这些 16 位类型都将是
short的 typedef，您不必费心。There will probably not be a difference except on exotic hardware where
int32_tandint16_tdon't even exist.In that case you might use
int_least16_tto get the smallest type that can contain 16 bits. Could be important if you want to conserve space.On the other hand, using
int_fast16_tmight get you another type, larger thanint_least16_tbut possibly faster for "typical" integer use. The implementation will have to consider what is faster and what is typical. Perhaps this is obvious for some special purpose hardware?On most common machines these 16-bit types will all be a typedef for
short, and you don't have to bother.在我看来，它们毫无意义。
编译器不关心你如何称呼类型，只关心它的大小以及适用于它的规则。因此，如果 int、in32_t 和 int_fast32_t 在您的平台上都是 32 位，那么它们几乎肯定都会执行相同的操作。
理论上，语言的实现者应该根据其硬件上最快的语言进行选择，但标准编写者从未明确定义最快的语言。再加上平台维护者不愿意更改此类类型的定义（因为这会破坏 ABI），并且这些定义最终会在平台生命周期开始时任意选取（或从 C 库所继承的其他平台继承）。移植自）并且再也没有碰过。
如果您处于微优化级别，您认为变量大小可能会产生显着差异，那么在您的处理器上使用您的代码对不同选项进行基准测试。否则不用担心。在我看来，“快速”类型不会添加任何有用的东西。
IMO they are pretty pointless.
The compiler doesn't care what you call a type, only what size it is and what rules apply to it. so if int, in32_t and int_fast32_t are all 32-bits on your platform they will almost certainly all perform the same.
The theory is that implementers of the language should chose based on what is fastest on their hardware but the standard writers never pinned down a clear definition of fastest. Add that to the fact that platform maintainers are reluctant to change the definition of such types (because it would be an ABI break) and the definitions end up arbitrarily picked at the start of a platforms life (or inherited from other platforms the C library was ported from) and never touched again.
If you are at the level of micro-optimisation that you think variable size may make a significant difference then benchmark the different options with your code on your processor. Otherwise don't worry about it. The "fast" types don't add anything useful IMO.