Memory Allocation Limitations on Windows for Large Arrays in C++

  • Context: C/C++ 
  • Thread starter Thread starter sid_galt
  • Start date Start date
  • Tags Tags
    Memory Windows
Click For Summary

Discussion Overview

The discussion revolves around memory allocation issues in C++ on Windows when declaring large arrays, specifically a 24 MB array. Participants explore the differences in behavior when the array is declared inside versus outside of a function, and the implications of stack size limitations.

Discussion Character

  • Technical explanation
  • Debate/contested

Main Points Raised

  • One participant reports a runtime error when declaring a 24 MB static array inside a function, while no error occurs when declared outside the function.
  • Another participant suggests showing code and inquires about memory deallocation practices upon exiting the function.
  • A participant confirms that the array is static and shares the relevant code that generates the error.
  • It is noted that the stack has finite sizes in C, and allocating large arrays on the stack is generally discouraged.
  • One participant questions the necessity of such a large array and asks about the program's purpose, suggesting that it may be unnecessary to load such large data into an array.
  • Another participant mentions that the 24 MB array is for quick mapping in the context of the Netflix Prize competition and indicates that the actual data may require even larger arrays of 200-300 MB.
  • There is a suggestion to use pointer arithmetic instead of array indexing to potentially improve performance.

Areas of Agreement / Disagreement

Participants express differing views on the appropriateness of large array allocations on the stack, with some emphasizing limitations and others discussing performance considerations. The discussion does not reach a consensus on the best approach to handle large arrays in this context.

Contextual Notes

Participants note the limitations of stack size and the implications of declaring large arrays within functions, but do not resolve the underlying issues related to memory allocation practices on different operating systems.

sid_galt
Messages
503
Reaction score
1
When I declare an array of size 24 mb in c++, I have discovered that the result is a runtime error if the declaration is made inside a function. If the declaration is made outside a function, then there is no problem.

The problem exists with both VC++ Express and Cygwin GCC (GCC gives a segmentation fault). There is no problem on Suse Linux.

Does windows have a limitation on the amount of memory that can be allocated using functions or something?

I have 1 GB Ram of which atleast 350 MB is free at all times and 3.2 GHz 2MB L2 cache Pentium IV.
 
Technology news on Phys.org
It might help if you show some code.
Do you deallocate the memory when you exit the function?
 
robphy said:
It might help if you show some code.
Do you deallocate the memory when you exit the function?

Actually the array declared is a static array. Here's the relevant code which generates error.
<code>
void LoadHistory(bool k)
{
//Declare and initialize variables
int matchUser[3000000][2] //The erring variable

fstream fbinary, fmovieratingcount;
fbinary.open(BINARY_FILE_PATH, ios::in | ios::binary);
fmovieratingcount.open(MOVIE_RATING_COUNT, ios::in | ios::binary);

if(!fbinary && !fmovieratingcount)
{
count<<"FILE CAN'T BE OPENED!\a\n";
exit(1);
}

int tmp, movieId;

for(int i = 0; i < 3000000; i++)
{
matchUser[0] = 0;
}

//While loop to read movie ratings
while(!fmovieratingcount.eof() && !fbinary.eof() && net_movie_no < NO_MOVIES)
{
int custId, ratings_no;
int rating;

fmovieratingcount.read((char*) &tmp, sizeof(tmp));
fbinary.read((char*) &movieId, sizeof(movieId));
}

}
</code>

Moving matchUser declaration outside the function results in no error.

<code>
int matchUser[3000000][2] //No error now
void LoadHistory(bool k)
{
//Declare and initialize variables


fstream fbinary, fmovieratingcount;
fbinary.open(BINARY_FILE_PATH, ios::in | ios::binary);
fmovieratingcount.open(MOVIE_RATING_COUNT, ios::in | ios::binary);

if(!fbinary && !fmovieratingcount)
{
count<<"FILE CAN'T BE OPENED!\a\n";
exit(1);
}

int tmp, movieId;

for(int i = 0; i < 3000000; i++)
{
matchUser[0] = 0;
}

//While loop to read movie ratings
while(!fmovieratingcount.eof() && !fbinary.eof() && net_movie_no < NO_MOVIES)
{
int custId, ratings_no;
int rating;

fmovieratingcount.read((char*) &tmp, sizeof(tmp));
fbinary.read((char*) &movieId, sizeof(movieId));
}

}
</code>
 
Looks like you are trying to allocate a big array on the stack.
Stacks have finite sizes in C, usually you can increase the size but it really does not make any sense to create stacks that are that big.

By the way, what are you trying to do with this program? There are exceptions, so that's why I ask, but usually it is completely unnecessary and generally a bad idea to load something into an array that big.
 
Last edited:
Thanks robphy.

MeJennifer said:
By the way, what are you trying to do with this program? There are exceptions, so that's why I ask, but usually it is completely unnecessary and generally a bad idea to load something into an array that big.

Playing around with this http://www.netflixprize.com

The 24 mb array is for quick mapping. This is actually a very small array. The actual data requires an array of size 200-300 mb minimum.
 
sid_galt said:
Playing around with this http://www.netflixprize.com

The 24 mb array is for quick mapping. This is actually a very small array. The actual data requires an array of size 200-300 mb minimum.
I see! :smile:

If you want to be fast then don't use array indexing but, wherever possible, use pointer arithmetic.

For instance, in your array initialization routine, you require the program each time to calculate the address instead of just incrementing some pointer.

Keep that in mind when you run your statistical analysis, you could easily improve the speed of such a program by 50% if you minimize the use of array indexing and use pointer arithmetic.
 
Thanks, I'll keep that in mind.
 

Similar threads

  • · Replies 17 ·
Replies
17
Views
4K
  • · Replies 4 ·
Replies
4
Views
3K
  • · Replies 10 ·
Replies
10
Views
7K
  • · Replies 13 ·
Replies
13
Views
8K
  • · Replies 17 ·
Replies
17
Views
3K
Replies
3
Views
4K
  • · Replies 7 ·
Replies
7
Views
11K
  • · Replies 2 ·
Replies
2
Views
2K
  • · Replies 7 ·
Replies
7
Views
3K