为什么64位版本的应用程序比32位版本慢很多
为了解决3G（Ubuntu）内存问题（有时我们确实需要比3G更多的内存），我在64位环境下编译我的应用程序以使用更多内存。
但是，我的 64 位应用程序比 32 位版本慢得多。
32Bit版本是在32位机器上构建的； 64位版本是在64位机器上构建的； 在我们的加载测试中，32 位和 64 位版本都在 64 位机器上运行。
我用谷歌搜索，有人说，不必要的 long 类型会使 64 位比 32 位慢，因为：
man g++:
-m64
Generate code for a 32-bit or 64-bit environment. The 32-bit environment
sets int, long and pointer to 32 bits and generates code that runs on any
i386 system. The 64-bit environment sets int to 32 bits and long and
pointer to 64 bits and generates code for AMD's x86-64 architecture. For
darwin only the -m64 option turns off the -fno-pic and -mdynamic-no-pic
options.
所以我将所有 long 更改为 ints，但结果仍然相同。
请指教。
Peter
编辑：
- 关于内存，32位和64位版本都使用相似的内存，大约1.5~ 2.5GB，我的机器有9GB物理内存；
- 我使用 OProfile 进行分析，对于大多数功能，64 位版本收集 比 32 位版本有更多的分析样本；
- 我想不出任何 其他瓶颈，请指教。
- 我的应用程序是一个服务器，加载测试是在 100 个客户端连接下完成的。服务器对来自客户端的音频数据进行大量计算处理。
In order to solve the 3G (Ubuntu) memory issue (sometimes we do need more memory than 3G), I compiled my app under a 64bit environment to use more memory.
But, my 64bit app is much slower than the 32bit version.
32Bit version is built on a 32 bit machine;
64Bit version is build on a 64 bit machine;
both 32Bit and 64Bit versions run on the 64Bit machine in our loading test.
I googled, and some folks said, the unnecessary long type can make the 64bit slower than 32bit, because:
man g++:
-m64
Generate code for a 32-bit or 64-bit environment. The 32-bit environment
sets int, long and pointer to 32 bits and generates code that runs on any
i386 system. The 64-bit environment sets int to 32 bits and long and
pointer to 64 bits and generates code for AMD's x86-64 architecture. For
darwin only the -m64 option turns off the -fno-pic and -mdynamic-no-pic
options.
So I changed all my longs to ints, but still same result.
Please advise.
Peter
Edit:
- About memory, both 32 and 64 versions use similar memory, about 1.5 ~
2.5 GB, and my machine has 9GB physical memory; - I profiled using OProfile, and for most of the functions, the 64bit version collects
more profiling samples than the 32bit version; - I cannot think of any
other bottlenecks, please advise. - My app is a server, and the loading test was done under a 100 client connections. The server does a lot of computation processing the audio data from the clients.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
介绍您的应用程序。这会告诉你慢代码在哪里。
Profile your app. That will tell you where the slow code is.
对于“为什么”这个问题，没有细节，谁也不会知道其中的原因。您必须分析分析结果，如果结果有任何问题，请在此处以问题形式发布。
如果您的应用不需要超过 4GB 的 RAM（在您的情况下为 1.5~2.5GB），您应该尝试 x32。这是一个新的 ABI，允许在 64 位环境中使用 32 位指针。
For the question "why", no one will know the reason without details. You must analyze the profiled result and if there are any problem with the result, post it as a question here.
If your app does not need more than 4GB of RAM (1.5~2.5GB in your case), you should try x32. It's a new ABI that allows for 32-bit pointers in 64-bit environment.