[lug] Huge stack size--any reason to avoid?

[D. Stimits]

Vince Dean wrote:

>I'm working with some C++ code which puts very large 
>data structures on the stack, large enough that we have 
>to increase the allowable stack size to 512 megabytes:
>
>  ulimit -Ss 512000
>
>The developers point out that variables on the stack are
>managed automatically, minimizing the risk of
>memory management errors.  If the lifetime of the
>objects is such that they can be managed conveniently
>on the stack, I can't disagree with that argument, but 
>something still makes me uncomfortable.   
>
>I understand that there are many cases where the sequence
>of creating and destroying objects makes it essential to 
>manage memory dynamically on the heap.  This is not such
>a case.  Stack allocation is perfectly reasonable here.
>The only issue is the very large size.
>
>Are there any practical arguments against putting
>big data structures on the stack?  We are running Suse
>Linux on an Itanium system.  Am I likely
>to run into a Unix or Linux desktop or server machine 
>where it is not possible to set the stack so large?
>
>In the end, it is all (virtual) memory, with the
>stack being allocated at one end of the address
>space and the heap on the other end.  Is there any
>reason for me to be concerned about this coding style?
>
>  
>

I'd be interested in hearing about the answers. I'm just wondering if 
performance is an issue...somehow (without any proof), I would think 
that a single reference into a heap space would be faster than using the 
stack, especially if you have exceptions enabled (are exceptions 
enabled?). Run it with gprof and see what changes. I also wonder if 
stack space can take advantage of virtual memory via swap as easily as 
heap can...until now I've never thought about that. If you plan to 
allocate and deallocate a lot, I have no doubt that running your own 
memory management (which does not need to be complicated) to cache and 
pool kernel requests and keep most new/delete in user space would be a 
huge performance bonus at that size.

FYI, I'm not a fan of inventing a new crutch as a way of avoiding doing 
the job right to start with. I'd be really curious as to why it is they 
felt the need to do this in the first place, and whether the app has to 
be portable, and whether it'll be on only 64 bit machines (you mentioned 
Itaniums, but perhaps not everyone running it has Itanium).

D. Stimits, stimits AT comcast DOT net