如何编译程序使其能够在 32 位 Linux 上使用 >4GB 内存?

发布于 2024-10-31 18:52:52 字数 612 浏览 4 评论 0原文

整个代码是用 C、C++ 和 Fortran 编写的。 是否可以让它使用4GB以上的内存? 现在内存到3GB就老是崩溃。

如果可能的话,如何设置编译选项(或配置标志)?

我们可以使用 gcc、g++...或 intel 编译器

我们的操作系统:Fedora 12 x32

cat /proc/cpuinfo
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority
bogomips : 5319.72
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual

The whole code is written in C, C++, and Fortran.
Is it possible to make it to use more than 4GB memory.
Now it is always crashed when it reaches 3GB memory.

If it is possible, how to set up the compiling options (or configure flags)?

We can use gcc, g++, ...or intel compilers

our OS: Fedora 12 x32

cat /proc/cpuinfo
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm tpr_shadow vnmi flexpriority
bogomips : 5319.72
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual

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

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

发布评论

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

评论(4

梓梦 2024-11-07 18:52:52

不幸的是,您已经达到了

R> 2^32
[1] 4294967296

4 GB 的限制。因此,无论操作系统是什么,对于单个应用程序的索引都无法超出

这是我们许多人改用 64 位版本操作系统的原因之一。 Linux 自 20 世纪 90 年代末以来就支持这一点。只需切换到 64 位的 FC(或 Ubuntu 或...)即可。

一种可能的替代方案是安装更多 RAM(Linux 将处理)并将任务分段到应用程序的多个实例上,从而有效地并行运行它。但这可能不值得这么麻烦......

Unfortunately you are hitting the limit that

R> 2^32
[1] 4294967296

which is your 4 gb limit. So you simply cannot index beyond for a single application, no matter what the OS.

This is one of the reasons many of us switched to 64 bit versions of our OSs. Linux has supported this since the late 1990s. Just switch to FC (or Ubuntu or ...) in 64bit.

One possible alternative is installing more RAM (which Linux will handle) and segmenting your task over several instances of the application, effectively running it in parallel. But that may not be worth the trouble...

注定孤独终老 2024-11-07 18:52:52

我相信,如果您将一个文件放入 tmpfs 文件系统(或 Hugetlbfs)中,并在程序中一次映射该文件的一小部分(1 - 2 GB),那么您可以一次处理超过 4 GB 的数据。

地图操作并不是那么快,因此如果您过于随机地跳转内存,您的性能将会受到影响。

I believe that if you put a file in a tmpfs filesystem (or hugetlbfs) and in your program map small (1 - 2 GB) pieces of it at a time, you can work with more than 4 GB of data at once.

The map operations aren't all that fast so you will take a performance hit if you jump through your memory too randomly.

薔薇婲 2024-11-07 18:52:52

您需要将其工作集划分为 << 的块。 3 GB,并在单独的进程中处理每个块。通过管道或套接字连接进程。

这与将其开发为网络/集群应用程序非常相似,如果您想要可扩展性,这可能不是一个坏主意。

You need to partition its working set into chunks of < 3 GB, and handle each chunk in a separate process. Connect the processes by pipes or sockets.

This is pretty similar to developing it into a network/cluster application, which might not be a bad idea if you want scalability.

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