Printable View
I declare a two-dimensional dynamic array of size 65536 * 65536, but I can't initialize the entire array[65535][65535].
Any suggestions?Code:int** array = (int**)malloc(sizeof(int*) * 65536);
for(int i = 0; i < 65536; i++)
{
array[i] = (int*)malloc(sizeof(int) * 65536);
}
for(int x = 0; x < 65536; x++)
{
for(int y = 0; y < 65536; y++)
{
array[x][y] = 0 //my value, 0 for example
}
}
Thanks in advance for your answers.
If your ints are 4-bytes long, that's 16G of memory.
Suggestion: if you really really really need that many integers, use a disk-based approach
Suggestion #2: re-think your solution to whatever problem you're dealing with to not need that many values.
Can you process a smaller amount of memory at a time?
What is the array for?
Exactly what do you do with the data in it?
Where does the data come from?
How often is it accessed?
Check each malloc() call to see if it succeeds. malloc() returns NULL if it fails. NULL should not be dereferenced, so your initialisation loop exhibits undefined behaviour if any of the malloc() calls have failed.
At least one of the malloc() calls will fail if your host environment is 32 bits or less.
Generally, it is a rare program that justifiably needs to create arrays (dynamically or statically) of such a size.
If you happen to work with enormous data sets, much larger than what can fit in your RAM, make sure you have a 64-bit machine and use memory-mapping techniques.
Some time ago, I wrote an example here that creates an ephemeral (unlinked while open) sparse file to hold a terabyte-sized memory structure. In other words, you do not need a terabyte of swap, or disk space; just enough to hold the pages you modify.
In most cases you get better performance if you can stream the data, not hold the entire data structure in memory. If the data structure is truly that large, then you can always use one or more smaller mappings to the file, so you won't waste your RAM for the virtual memory overhead (kernel structures needed for the mappings).
That said, there is nothing wrong in doing
to allocate a 65536x65536-element matrix, if you really do need one. You just need a 64-bit machine with over 32G of RAM, or it will either fail or trash badly (swap a lot, slowing everything down to snail speed).Code:size_t rows = 65536;
size_t cols = 65536;
double *matrix = malloc(rows * cols * sizeof (double));
Even on 32-bit architectures you can usually have a 65536x65536 matrix, if you limit to one bit (or maybe just a few bits) per element, as that's just 512MB per bit per matrix ( rows * (cols / CHAR_BIT) chars). Using accessor macros or inline functions makes it quite straightforward, too.
Solved.
Thank tou for your help.