Windows限制中的共享内存（C ++）

Question

Currently I'm working on a solution for the memory limits per process. So I came to shared memory. First, I'm using windows 7 with visual studio as developer platform, the software will run on a modern windows server system with multiple CPU's and a huge memory.

Well, I informed my self about memory limits per process, and I need to access much more memory. So my idea was creating multiple processes and use shared memory.

But is it really good to create a lot shared memory? And what about performance?

Answer 1

Well, I informed my self about memory limits per process, and I need to access much more memory. So my idea was creating multiple processes and use shared memory.

The limits on memory per process are for virtual memory . This basically means that your address space has a maximum size (eg 4 gigabytes on a system with 32-bit pointers). Since shared memory is a mapping of memory into your address space, there's no way that would get you out of the problem you have.

Keep in mind that if you distribute the memory blocks into multiple processes, you'll eventually reach the limits of physical memory and then system performance will slow to a crawl.

If you really need more memory than your system can grant you, you need to start to persist your data to disk. Memory mapped files can allow you to quickly swap memory blocks in and out of your address space.

Answer 2

@ Aurus,

It sounds as though what you require to cover your targets is a custom-engineered solution tailored to specific (albeit under-described) requirements. While Stack Overflow is extremely useful for developers and software engineers seeking professional clarity and programmatic examples, whatever applicable high-level engineering is available within may not be easy to locate and will likely not provide the specific answers you seek. One could make too many assumptions from your post.

Whatever benefit(s) you may (or may not) attain from staggering quantities of RAM and or multiple threads on multiple processors would best be left to those with hard experience building such systems. I have years in the field myself and can confidently express that I myself lack that specific experience. Honestly I hope to avoid that eventuality because high-dollar hardware commonly attends high-pressure schedules, and those can lead to other issues as well. I'll speculate a tiny bit though -- if only because it costs you nothing...

If your intent is firmly fixed upon utilizing Windows platforms my first-order guess is:

• a clustered server environment (many multi-core processors for crunching high numbers of threads, backed by a massive quantity of available RAM)
• cutting edge drive hardware -- if you're seeking to minimize the impact of frequent virtual memory access you'll likely need to target specific cutting-edge hardware options that enable you to literally replace spindle-drives with more eloquent DRAM sticks, that is to say solid state drives -- not the trivial type you commonly find in modern iPods and mobile PDAs... I refer to the real deal -- classic solid state drives [ one fine example is here -- look under hardware]. Their products are two to three orders of magnitude faster than spindle drives and even far faster than consumer solid state as well (albeit not cheap).

Your goals appear to indicate that cost isn't a great concern, but that's about as good as I can give you while lacking more specific information.

One final bit of advice though, when seeking help from engineers it's best to tell them exactly what you seek to accomplish (the goal(s)). Allow them to provide the options and match the limitations of reality and modern technology to your dilemma as well as your financial targets. More often than not, even with esoteric and eccentric requirements, the best solution is actually a custom 'outside-the-box' engineering solution that also ends up being far cheaper to build / implement than a brute-force approach. To put it another way, help the engineers to help you while noting that the GIGO Principle applies as well.

I sincerely hope something I provided is useful. Good luck.