Printable View
I have a question about an error in a C program.
I need to define a float array as follow:
float rad[1000][1000000];
But this error is occured:
size of variable 'rad' is too large
I need to define an array with those sizes. So, what should I do in order to solve the problem? Please help me if anyone knows the solution.
Thanks so much
I'm not surprised. You want 1000 * 1000000 * sizeof(float) bytes. That is about 4GB, which for a 32-bit application is "too large".
If you can use a 64-bit OS and a 64-bit compiler, you could probably solve the problem that way.
However, I would seriously consider your needs - because even if you manage to build an application that "works" for this size of an array, you will probably find that it's quite slow unless your machine also has a huge amount of memory [at least 5GB].
For most problems like this [that is, where you have a "need" for a large array], there are alternative solutions, where you only actually store "useful" data, and "standard values are ignored".
If you can't use a 64-bit OS for some reason, you will DEFINITELY have to rethink the design of your software.
--
Mats
You'll need to acquire the memory from the heap (general processor RAM) instead of using the stack. Look to malloc().
Todd
In a 32-bit machine, that won't make ANY difference.Quote:
Originally Posted by Todd Burch
Of course, using a approx 4GB stack based variable would be complete lunacy - even in a 64-bit system.
--
Mats
1,000 * 1,000,000 * 4 (length of float)= 4,000,000,000 = 0xEE6B 2800 (ala, < 4GB.)Quote:
Originally Posted by matsp
Why won't it work? Are lengths treated as signed values?
Todd
Could you please tell me what is a malloc() code program which is equivalent to rad[1000][1000000]
p.s. And yes, it's lunacy to request this much storage.
It is less than 4GB by a bit more than 256MB. But for any 32-bit OS that has any memory management at all, the > 3GB is sufficient to make it not work.Quote:
Originally Posted by Todd Burch
Quote:
Originally Posted by yazdan59
But that will not work any better if you don't have a machine that supports more than 3GB for application address spaces, so you need a 64-bit OS [or a custom built OS].Code:rad = malloc(sizeof(float) * 1000 * 1000000)
--
Mats
you can do one thing....
just create a memory space when it is needed usin maloc and cear of the space usig free if you r done with it....
why do you want to allocate so much of space at a time...
allocate it before you take an input.......
more details read dma
I believe each application is limited to 2 GB of (virtual) memory, aren't they (on x86)?Quote:
Originally Posted by Todd Burch
But even so, good luck allocating much more than 1 GB of memory - it just won't work, because you'll find that there's no such thing as 1 GB of contiguous virtual memory available! It's all fragmented a little bit here and there (why it doesn't allocate in a contiguous manner beats me).
No, all 32-bit operating systems can handle up to 4gb of memory(Eg, 2^32). 64-bit operating systems are thus limited to 2^64 bytes, which I think is something like 16-18 exabytes.Quote:
Originally Posted by Elysia
Please differentiate between can handle and limited/reserved. Yes, 32-bit can address 4 GB of memory, but a lot of virtual memory for each process is reserved (I believe it's the lower half of the memory space) plus Windows reserves a bit of memory space for itself, so it can't address all 4 GB.
EDIT:
Each application only has access to 2 GB virtual memory.Quote:
Operating systems based on Microsoft Windows NT technologies have always provided applications with a flat 32-bit virtual address space that describes 4 gigabytes (GB) of virtual memory. The address space is usually split so that 2 GB of address space is directly accessible to the application and the other 2 GB is only accessible to the Windows executive software.
The limitation has nothing to do with the architecture. The OS is implemented with a certain chunk of virtual address space reserved for its own purposes while in kernel mode. If all 4 gigabytes were reserved for user space, how would the kernel be able to access its internal data structures and user application data at the same time? To make things easier the kernel just says that the top gig (or two gig) of virtual address space is reserved for the kernel, period.Quote:
Originally Posted by Elysia
An OS could be written or modified to allow the user application access to more memory, but at that point it seems preferable to go to a 64-bit architecture anyway.
It's reserved because the OS says it is. There's no reason it couldn't be made available, it just isn't.Quote:
Please differentiate between can handle and limited/reserved. Yes, 32-bit can address 4 GB of memory, but a lot of virtual memory for each process is reserved (I believe it's the lower half of the memory space)
Yeah, point being, just because the OS is 32-bit doesn't mean you can access and use all that 4 GB of virtual memory. On Windows (NT), each application only has 2 GB to play around with.
So all calls with > 2GB automatically fails.
On IBM mainframes (my day job), prior to the 64 bit OS, we had (actually still have) 31 (not 32) bit addressing. An address space (aka, a logged on user for simplicity sake) was 2GB-1 bytes long. Reducing out the system resident code and the common areas of memory available to all address spaces, the rest is available for the user (or application). If you needed more memory than 2GB, you simply told the operating system you needed another address space, and thus you got another "2GB", and so on and so on. In theory, you can have 32,767 address spaces (minus the address spaces required to keep the system running.
Now with the 64-bit OS, you get 16 exabytes (10**18) virtual in each address space. It's obscene.
Todd