Any reason not to change the stack size?
i think one interesting question keeps open (for me at least):
assume that some programmer - probably me - loves stack based allocation, because it perfectly suits his needs (speed and such), what would be the problem with increasing the stack size to lets say 256 mbyte ?
is there any technical problem associated with that? where would be the difference if i would do the same with the heap and dynamic memory allocation, besides the obvious things like memory management ?
Author
One I heard of is that you can't recover from a failed stack allocation, while you can from heap allocation.
Quote:Original post by MushuQuote:Original post by SymLinkedget (256, 256); // Wouldn't that overflow?
No, it would fail to compile (the assert would evaluate to false; assuming an assert does what I think it does).
Assertions are triggered at run-time, it would compile fine.
Quote:Original post by hercis there any technical problem associated with that? where would be the difference if i would do the same with the heap and dynamic memory allocation, besides the obvious things like memory management ?
Yes, there's a reason there's a stack and a heap. It has to do with virtual memory and paging.
Stack is intended to be paged as little as possible. If you define 256Mb stack, you either fall back to usual paging faults when system manages memory, or you define all of it as non-commitable, completely depriving the system of that particular chunk of RAM.
Don't fix what isn't broken.
For example, Java VM partitions heap (stack is irrelevant in that case) into several different blocks, each based on how long an object will live. The longer an object lives, the higher it gets pushed up.
This mimics the cache strategy employed by processors (L1 <- L2 <- RAM). Stack serves the same purpose. Short-lived allocations are performed on stack (function calls, temporaries), the rest goes into heap.
There's a whole lot of science behind stack and heap sizes, sizes of allocations, cache efficiency, ...
When dealing with large continuous data structures, cache coherency will determine performance, not where it's allocated.
Quote:Original post by SymLinkedQuote:Original post by Palidine
*** Source Snippet Removed ***
and when you're done using it:
*** Source Snippet Removed ***
-me
Thanks Palidine. That's the approach I tried to understand previously. What worries me is how you access the array.
There's another way to go about it (which is interesting because it allows natural usage, while also having decent spatial locality):
size_t const D1 = 256;size_t const D2 = 256;int * * array = new int *[D1];array[0] = new int[D1*D2];for( int i = 1; i < D1; ++i ) array = &array[0];<br><br>// …<br><br>// You can therefore use it as normal:<br>array[3][55] = 324;<br>std::cout << array[252][75];<br><br>// …<br><br>delete [] array[0];<br>delete [] array;</pre><br><br><br>But then again, if you're going to go through the trouble, you might as well install and use <a href="http://www.boost.org/libs/multi_array/index.html">boost::multi_array</a> (or at least wrap Palidine's solution so that you have a subscript operator).Quote:Original post by herc
assume that some programmer - probably me - loves stack based allocation, because it perfectly suits his needs (speed and such), what would be the problem with increasing the stack size to lets say 256 mbyte ? is there any technical problem associated with that?
One issue is threads. Most people don't bother to give a stack size to CreateThread so when a thread does spin up it uses whatever the default thread size is for the executable. If the default thread stack size is 256MB it only takes a couple of threads before you are completely out of contiguous address space. Note that even if you don't do threads various system components do. It could be made to work but you'd probably get occasional wierd behaviors in different environments / OS versions.
Of course if your app was native 64-bit 256MB of address space is chicken feed :).
Quote:Original post by ToohrVyk
Then, as you said, the size of stack-allocated memory must be known at compile-time—only C99 allows variable-size stack arrays.
alloca works with older version of C.
There is also portability to be taken into account - not all system (especially embedded) will allow the stack size to be changed.
Quote:Original post by Driv3MeFarQuote:Original post by MushuQuote:Original post by SymLinkedget (256, 256); // Wouldn't that overflow?
No, it would fail to compile (the assert would evaluate to false; assuming an assert does what I think it does).
Assertions are triggered at run-time, it would compile fine.
Ah, okay. I guess I should do some more reading.
You can do a compile time assert if you so very wish:
Although these generally shouldn't be needed, used, or glanced at.
#define COMPILE_TIME_ASSERT( a ) { int Temp[ ( a ) ? 1 : 0 ]; }Although these generally shouldn't be needed, used, or glanced at.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement