64 位环境中 32 位整数的性能 (C++)

发布于 2024-08-11 16:47:01 字数 373 浏览 2 评论 0原文

我们已经开始编译一些应用程序的 32 位和 64 位版本。我的项目中的一个人鼓励我们将所有 32 位整数转换为 64 位整数,即使这些值保证适合 32 位空间。例如,我有一个保证永远不会超过 10,000 的值,我将其存储在无符号整数中。他的建议是将其切换为 size_t,以便在 64 位环境中扩展到 64 位,即使我们永远不需要额外的空间。他说,无论每个变量中存储的值如何,使用 64 位变量都会加快应用程序的速度。他说得对吗?事实证明这是一项艰巨的工作,如果实际上没有什么作用,我并不急于付出努力。

我们正在使用 Microsoft Visual C++ 2008。不过,我有点希望得到一个更通用、独立于平台的答案。

那么你觉得怎么样?我们出于性能原因而不是范围原因花时间更改数据类型是否正确?

We've started compiling both 32- and 64-bit versions of some of our applications. One of the guys on my project is encouraging us to switch all of our 32-bit integers to their 64-bit equivalents, even if the values are guaranteed to fit in a 32-bit space. For example, I've got a value that is guaranteed to never exceed 10,000 which I'm storing in an unsigned int. His recommendation is to switch this to a size_t so that it expands to 64 bits in a 64-bit environment, even though we'll never need the extra space. He says that using 64-bit variables will speed up the application regardless of the values stored in each variable. Is he right? It's turning out to be a lot of work, and I'm not anxious to put in the effort if it doesn't actually make a difference.

We're using Microsoft Visual C++ 2008. I'm kinda hoping for a more general, platform-independent answer though.

So what do you think? Are we right to spend time changing our data types for performance reasons rather than range reasons?

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

扫码二维码加入Web技术交流群

发布评论

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

评论(6

念三年u 2024-08-18 16:47:01

我认为您面临着一个巨大的不成熟优化案例。在分析器明确告诉您这是重大性能问题的根源之前,切勿在应用程序中进行此类微小更改。

否则,您将花费大量时间修复非问题。

I think you have a huge case of pre-mature optimization staring you in the face. Never make micro changes like this in your application until a profiler has definitively told you that it is a source of significant performance problems.

Otherwise you'll spend a lot of time fixing non-problems.

在风中等你 2024-08-18 16:47:01

好吧,如果 32 位操作发生在 64 位寄存器中,则确实需要发出一些额外的指令来处理诸如设置进位/溢出标志等之类的事情。不过,如果您意识到任何明显的性能改进,我会感到惊讶。我几乎可以保证您的程序中存在更严重的瓶颈。

Well if the 32-bit operations are taking place in 64-bit registers, some extra instructions do need to get emitted to handle things like setting carry/overflow flags, etc. I'd be surprised if you realised any noticeable performance improvement, though. I can all but guarantee there are far worse bottlenecks in your program.

风铃鹿 2024-08-18 16:47:01

首先,在 64 位环境中使用 64 位整数而不是 32 位整数通常不会加快任何速度。根据上下文和编译器的能力,这实际上可能会减慢速度。通常,您应该更喜欢使用 int/unsigned int 类型在程序中存储整数值,仅在真正需要时才切换到其他类型。最后,这个问题的最终答案只能通过实际实验才能获得,因为它取决于太多的变量。

其次,任何建议使用 size_t 达到此目的(作为通用无符号类型)的人都应立即拒绝访问代码,并在允许他们再次接触代码之前发送一些 C/C++ 类。

Firstly, using 64-bit ints instead of 32-bit ints in 64-bit environment will not generally speed-up anything. Depending on the context and on the compiler abilities, this might actually slow things down. Normally, you should prefer using int/unsigned int types for storing integral values in your program, switching to other types only when really necessary. In the end, the definitive answer to the question can only be obtained by an actual experiment, since it depends on too many variables.

Secondly, anyone who advises using size_t for that purpose (as a generic unsigned type) should be immediately denied access to code and sent to take some C/C++ classes before they are allowed to touch the code again.

夏日落 2024-08-18 16:47:01

不要这样做。这只是意味着CPU将无法在缓存中保存尽可能多的数据,并且进入主内存的惩罚比大多数其他事情要高得多。

Don't do it. It just means that the cpu will not be able to hold as much data in cache and the penalty for going to main memory is a lot higher than most other things.

暖树树初阳… 2024-08-18 16:47:01

使用 64 位整数与 32 位整数会加快速度的想法是一个神话。代码中更重要的是使用适当的类型。例如,当引用数组或数据结构的大小时,请使用 size_t,因为这就是 size_t 应该表示的内容。如果您要存储一些数据,请使用 int 而不是 size_t,因为这就是 int 所要描述的内容。

不要只是将所有内容更改为 size_t,因为它会“自动变为 64 位”,这可能不会带来任何改进。它将导致更大的内存开销,这可能会导致应用程序由于内存空间较大而因缓存未命中而变慢。它还很可能会导致意想不到的错误。

The idea that using a 64bit integer vs. a 32bit integer will speed things up is a myth. The more important thing in your code is to use the appropriate types. For instance, when referring to the size of an array or data structure, use a size_t because that's what a size_t is supposed to represent. If you're storing some piece of data, then use an int and not a size_t because that's what an int is meant to describe.

Don't just change everything to size_t because it will "automatically become 64bit" this will result in probably no improvement whatsoever. It will cause larger memory overhead which will probably cause the application to slow down due to cache misses because of the larger memory space. It will also quite possibly cause unexpected bugs.

停滞 2024-08-18 16:47:01

我猜测(这只是猜测),如果内存量增加导致某些内存访问丢失引用局部性并将内容更多地从缓存中推出,您可能会看到性能没有任何改进,并且可能会出现轻微下降比以前经常。

正如 JaredPar 所说,如果没有实际原因这样做,或者除非您需要增加较大整数的范围,否则这可能是浪费时间。

I'd guess (and it's just a guess) that you'll likely see no improvement in performance and may see a slight drop if the amount of memory increase causes some memory access to lose locality of reference and push things out of the cache more often than before.

As JaredPar says, if there's not a factual reason to do this or unless you need the increased range of the larger ints, it's probably a waste of time.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文