[Read subject line]
Printable View
[Read subject line]
Dunno, never tried that. Afraid you just cannot address within the range as in x86 architecture the whole process address space is 4G only. :)
PS. Is it possible to have such a need?
To answer your question, then no, there'll probably be no reason for that much memory (yet). And I agree that a 32-bit process cannot address that much space. I'm thinking about future porting to x64 though.
I'm also always perplexed when a Windows API returns the result as a 64-bit LONGLONG variable and I have to cast it to a 32-bit LONG. Example is a file size. So, I thought, to save myself a hassle of dealing with this bottle neck in the future and start using 64-bit memory management now.
(You know, back in a day when all they had were 16-bit CPUs no one thought that a gigabyte of memory was even possible.)
Considering the moment of appearance of 486 CPU and contemporary RAM sizes afraid you should wait at least 3-4 years until you could afford such an allocation without any noticeable impact on OS. Hope that time will be enough to get some certain solution to your current perplexing.
Then once your mind is already set, just write a couple of code lines, build that for x64 and see if it works. I believe this is not your first time you get an answer of the sort, as this very common in the community. Nobody can know everything. ;)
On this reason I accustomed always do this step before asking. And you know, I never had a reason to ask anybody after. :)
Igor, I understand that. Unfortunately most times I don't have enough hours in a day to try it out ... and yes, I might be abusing this community by hoping that someone has already done that and may post it here and save me time. Because that is what I do when I browse through this forum and if I see something that someone is asking and I know how to help them, I do respond and issue my advice. On the other hand, I do not comment if I don't know the answer...
Why do you need to have so much memory in 1 malloc ?
Yep, this is very common. People tend to survive this their own ways. :)Quote:
most times I don't have enough hours in a day to try it out
You get it wrong way, I believe. It never was about abusing or something. It's just about obvious difference between "hoping somebody knows, possibly without any clue whether I should trust that knowing" and "knowing by experiment of my own". :)Quote:
I might be abusing this community by hoping
:) Might be good for you. Or might be not. As I already said, you get this forum mostly like "answering machine". While I do not. I comment when I feel like that. Hope this seems not very abusing... and you excuse my imperfection. ;)Quote:
On the other hand, I do not comment if I don't know the answer...
IMO, if there is more than 4GB attached (memory extensions) then it can be allocated even on 32 bit system. I think the limit is 2^36, if allocated with help of memory mapped files then this works, server datacenter edition is needed to have this I guess.
Quote:
Originally Posted by ahmd
I did an experiment with memory allocation and it seems like there's a limit in x86 address space. For some reason on my Windows 7 x64 system with 8GB of RAM I was able to allocate 0x5FFFFFFF bytes but for 0x6FFFFFFF bytes it failed. I also tried calling HeadAlloc and VirtualAlloc with the same negative result. So I guess it pays to code in x64 environment after all.
Yes, I'm with you on that one. What I'm hoping for is to learn something that I don't already know. And, speaking of some flaky code off the web, I never take it at a face value and copy it one-to-one into my project. In most code samples just the idea is what matters.
Hah, this is one of those cases that I've never heard of. What are you talking about? It would be nice if it worked.