使用 uint_fast8_t 时的性能优势？

发布于 2024-08-16 03:13:23 字数 470 浏览 3 评论 0原文

因此，在对引擎进行了大量研究之后，我一直在为 iphone 构建一个 2d 框架。如您所知，引擎架构的世界非常广阔，因此我一直在尝试尽可能地应用最佳实践。

我一直在使用：

uint_fast8_t mId;

如果我查找 uint_fast8_t 的定义，我发现：

/* 7.18.1.3 Fastest-width integer types */
...
typedef uint8_t          uint_fast8_t;

我在整个代码中一直使用这些类型 - 我的问题是，使用这些类型是否有性能优势？幕后究竟发生了什么？除了这是数据的正确数据类型（无符号 8 位整数）这一显而易见的事实之外，是否值得在我的代码中添加这种类型？

这是编译器可能会处理的不必要的优化吗？

谢谢。

编辑：没有回复/答案，所以我为此悬赏！

原文

So after researching engines a lot I've been building a 2d framework for the iphone. As you know the world of engine architecture is vast so I've been trying to apply best practices as much as possible.

I've been using:

uint_fast8_t mId;

If I look up the definition of uint_fast8_t I find:

/* 7.18.1.3 Fastest-width integer types */
...
typedef uint8_t          uint_fast8_t;

And I've been using these types throughout my code - My question is, is there a performance benefit to using these types? And what exactly is going on behind the scenes? Besides the obvious fact that this is correct data type (unsigned 8 bit integer) for the data, is it worthwhile to have this peppered throughout my code?

Is this a needless optimization that the compiler would probably take care of anyways?

Thanks.

Edit: No responses/answers, so I'm putting a bounty on this!

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

紫瑟鸿黎 2024-08-23 03:13:23

fast 整数类型被定义为可用的最快整数类型，至少所需的位数（在本例中为 8）。

如果您的平台将uint_fast8_t定义为uint8_t，那么速度绝对没有差异。

原因是有些架构在不使用其原生字长时可能会变慢。例如，我可以找到一份参考资料，其中 Alpha 处理器的 uint_fast8_t 被定义为 unsigned int。

回复收藏 0 原文

眼前雾蒙蒙 2024-08-23 03:13:23

uint_fast8_t 是保证至少 8 位宽的最快整数。根据您的平台，它可能是 8 位、16 位或 32 位宽。

它不是由编译器本身处理的，它确实使您的程序执行得更快

这里是我找到的一些资源，您可能已经看过它们http://embeddedgurus.com/stack-overflow/2008/06/efficient-c-tips- 1-选择正确的整数大小/

http://www.mail-archive.com/[电子邮件受保护]/msg03149.html

回复收藏 0 原文

肩上的翅膀 2024-08-23 03:13:23

mingw64 中的标头表示快速类型“实际上并不能保证在所有用途上都是最快的”，

/*  7.18.1.3  Fastest minimum-width integer types
 *  Not actually guaranteed to be fastest for all purposes <---------------------
 *  Here we use the exact-width types for 8 and 16-bit ints.
 */
typedef signed char int_fast8_t;
typedef unsigned char uint_fast8_t;
typedef short  int_fast16_t;
typedef unsigned short  uint_fast16_t;
typedef int  int_fast32_t;
typedef unsigned  int  uint_fast32_t;
__MINGW_EXTENSION typedef long long  int_fast64_t;
__MINGW_EXTENSION typedef unsigned long long   uint_fast64_t;

这仍然适用于 ARM 或其他架构，因为在许多架构中使用窄类型需要零扩展或符号扩展与本机 int 相比不太理想的情况。

然而，这对于大型数组或缓慢的操作（如除法）会很有好处。我不确定 ARM 除法有多慢，但在 x86 64 位除法上比 32 位或 8 位除法慢得多

The header in mingw64 said the fast types are "Not actually guaranteed to be fastest for all purposes"

/*  7.18.1.3  Fastest minimum-width integer types
 *  Not actually guaranteed to be fastest for all purposes <---------------------
 *  Here we use the exact-width types for 8 and 16-bit ints.
 */
typedef signed char int_fast8_t;
typedef unsigned char uint_fast8_t;
typedef short  int_fast16_t;
typedef unsigned short  uint_fast16_t;
typedef int  int_fast32_t;
typedef unsigned  int  uint_fast32_t;
__MINGW_EXTENSION typedef long long  int_fast64_t;
__MINGW_EXTENSION typedef unsigned long long   uint_fast64_t;

and that still applies to ARM or other architectures, because using a narrow type requires zero extension or sign extension in many situations which is less optimal than a native int.

However that'll benefit in large arrays or in case or slow operations (like division). I'm not sure how slow ARM divisions are but on x86 64-bit division is much slower than 32-bit or 8-bit division

回复收藏 0 原文

~没有更多了~