Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Stack is slow than heap?

Reply
Thread Tools

Stack is slow than heap?

 
 
BGB
Guest
Posts: n/a
 
      11-09-2011
On 11/8/2011 1:52 PM, Cholo Lennon wrote:
> On 07/11/2011 19:28, BGB wrote:
>> On 11/7/2011 9:47 AM, Victor Bazarov wrote:
>>> On 11/7/2011 11:27 AM, Nephi Immortal wrote:
>>>> [..]
>>>> How big can stack hold on 32 bits machine? Should it hold between
>>>> 500 megabytes and 1 gigabytes of memory?
>>>
>>> It is usually controlled by the settings of your linker.
>>>

>>
>> and usually *much* smaller...
>>
>> on Windows, the default size if 4MB.
>>

>
> Correction: The default size, at least in Win32/VC++, is 1 MB, not 4 MB.
>


funny, I had thought I had read before that it was 4MB.

however, at least going by the PE/COFF header values, it appears you are
correct...

hmm...

either way though, it aint no 512MB or 1GB...


>>
>>>> After you write a function, do you prefer to store one buffer to hold
>>>> 1,024 bytes or 4,096 bytes?
>>>
>>> I prefer to store what my algorithm tells me to store.
>>>
>>> > Should 4,096 bytes be sufficient to hold
>>>> buffer or small array in stack?
>>>
>>> Depends on the use of the buffer.
>>>

>>
>> yep.
>>
>> sometimes 64 or 256 is more than sufficient...
>> and sometimes 4096 will still overflow.
>> it all depends on what one is doing, what data they are working with, ...
>>
>>
>>> > Every time, function is called and it
>>>> takes CPU time to push empty buffer or small array into stack, do
>>>> algorithm, and pop used buffer or small array out of stack prior
>>>> exiting function is always slow.
>>>
>>> Huh?
>>>

>>
>> nothing really has to be "added" or "removed" from the stack, as it is
>> usually just a sliding pointer.
>>
>>
>>
>>>> What option do you have? Do you prefer to create global variables to
>>>> hold buffer or small array into heap through reference or pointers
>>>> between function calls can be faster?
>>>
>>> Use anything available to you. If the size of the buffer is known at the
>>> compile-time, AND it's small enough, you can declare it locally in some
>>> function. It's *usually* as fast as, or faster than, dynamic allocation
>>> of arrays. If the size of the buffer is *not* known until run-time, you
>>> have a choice, use 'new[]/delete[]' and do it yourself or use standard
>>> containers.
>>>

>>
>> yep, among other options.
>>
>> unless one has a good reason though, global variables are generally bad
>> practice though, as:
>> depending on use, they may not mix well with the use of threads;
>> they impede modularity;
>> they reduce flexibility;
>> ...
>>
>>
>>>> For example:
>>>> [..snip..]
>>>>
>>>> Please answer one question. How big can stack hold up to 500
>>>> megabytes on 32 bits machine?
>>>
>>> Please re-phrase the question. I don't understand what it is you're
>>> trying to learn about the stack (I presume you're talking about the
>>> process' memory for objects with automatic storage duration).
>>>

>>
>> I think the OP was asking how big the stack is...
>>
>> but, it does not hold anywhere near that much.
>>

>
>


 
Reply With Quote
 
 
 
 
Nick Keighley
Guest
Posts: n/a
 
      11-09-2011
On Nov 8, 3:45*pm, Nephi Immortal <(E-Mail Removed)> wrote:
> On Nov 8, 5:00*am, Nick Keighley <(E-Mail Removed)>
> > On Nov 7, 4:27 pm, Nephi Immortal <(E-Mail Removed)> wrote:



> > Include your question in the body of your post

>
> > "Stack is slow than heap"

>
> > maybe. It all depends on the implementaion. I'd expect access time to
> > be very similar. Allocation/release is a little slower for heap
> > (dynamic memory) than stack (automatic memory).

>
> * * * * Heap is slow unless you allocate and deallocate heap manytimes.


what?

> Heap is pretty fast if you allocate one time prior reaching main
> function and deallocate one time after exiting main function. *If you
> insist, you have to allocate and deallocate very often, you will
> implement your own memory pool to speed up performance.


only if you have MEASURED the performance of your program, shown it
does not meet its documented perfaormance criteria and also MEASURED
the performance of the modified program and shown it is better.

<snip>

> > > After you write a function, do you prefer to store one buffer to hold
> > > 1,024 bytes or 4,096 bytes?


I'd choose the number that was correct for the program.

> > >*Should 4,096 bytes be sufficient to hold
> > > buffer or small array in stack?

>
> > this is a nonsense question. What is the buffer for?

>
> * * * * If you have multiple buffers outside function, you will need to
> create one temporary buffer inside function and copy all multiple
> buffers into one buffer before one buffer outputs to the screen like
> printf() or cout << << endl;


why? I don't see why you have to do this.

cout << buffer1 << buffer2 << buffern < "\n";

> * * * * I guess temporary buffer should hold sufficient 4,096 bytes or less.


why? I don't know what a "temporary buffer" is. If it's holding a
large JPEG then 4096 bytes is way too small.

<snip>
 
Reply With Quote
 
 
 
 
Werner
Guest
Posts: n/a
 
      11-09-2011
On Nov 9, 12:20*pm, Nick Keighley <(E-Mail Removed)>
wrote:
> On Nov 8, 3:45*pm, Nephi Immortal <(E-Mail Removed)> wrote:


> > * * * * Heap is slow unless you allocate and deallocate heap many times.

>
> what?


I think he might have meant "when you de-/ allocate many times".

> > Heap is pretty fast if you allocate one time prior reaching main
> > function and deallocate one time after exiting main function. *If you
> > insist, you have to allocate and deallocate very often, you will
> > implement your own memory pool to speed up performance.

>
> only if you have MEASURED the performance of your program, shown it
> does not meet its documented perfaormance criteria and also MEASURED
> the performance of the modified program and shown it is better.


Measure or not, the fact remains that using memory management schemes
that make use of pre-allocated memory (on heap) [can] give a program
more deterministic behaviour in terms of allocation time. One can
rely on getting/returning memory in constant time. The heap caters
for too many different cases (not specialized enough) and using it
does not guarantee consistent behaviour over a range of scenarios.
Therefore - what exactly are you going to measure? If you do need
deterministic behaviour, the heap is not good enough. Most of the
time it is, though.

IM(h)O the behaviour of the stack wrt. allocation/deallocation time
is more deterministic (my impression). For me that would be an
interesting debate.

Regards,

Werner





 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      11-09-2011
On Wed, 2011-11-09, BGB wrote:
> On 11/8/2011 1:52 PM, Cholo Lennon wrote:
>> On 07/11/2011 19:28, BGB wrote:
>>> On 11/7/2011 9:47 AM, Victor Bazarov wrote:
>>>> On 11/7/2011 11:27 AM, Nephi Immortal wrote:
>>>>> [..]
>>>>> How big can stack hold on 32 bits machine? Should it hold between
>>>>> 500 megabytes and 1 gigabytes of memory?
>>>>
>>>> It is usually controlled by the settings of your linker.
>>>>
>>>
>>> and usually *much* smaller...
>>>
>>> on Windows, the default size if 4MB.
>>>

>>
>> Correction: The default size, at least in Win32/VC++, is 1 MB, not 4 MB.
>>

>
> funny, I had thought I had read before that it was 4MB.
>
> however, at least going by the PE/COFF header values, it appears you are
> correct...
>
> hmm...
>
> either way though, it aint no 512MB or 1GB...


And more importantly, no "a handful of kilobytes" which used to be the
norm a couple of decades ago (and still is on some embedded systems).

Personally, and for "normal" C++ code, I'd start worrying about my
design if I found myself needing more than 100KB or so of stack.
That doesn't seem quite normal.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Dombo
Guest
Posts: n/a
 
      11-09-2011
Op 09-Nov-11 12:03, Werner schreef:
> On Nov 9, 12:20 pm, Nick Keighley<(E-Mail Removed)>
> wrote:
>> On Nov 8, 3:45 pm, Nephi Immortal<(E-Mail Removed)> wrote:

>
>>> Heap is slow unless you allocate and deallocate heap many times.

>>
>> what?

>
> I think he might have meant "when you de-/ allocate many times".
>
>>> Heap is pretty fast if you allocate one time prior reaching main
>>> function and deallocate one time after exiting main function. If you
>>> insist, you have to allocate and deallocate very often, you will
>>> implement your own memory pool to speed up performance.

>>
>> only if you have MEASURED the performance of your program, shown it
>> does not meet its documented perfaormance criteria and also MEASURED
>> the performance of the modified program and shown it is better.

>
> Measure or not, the fact remains that using memory management schemes
> that make use of pre-allocated memory (on heap) [can] give a program
> more deterministic behaviour in terms of allocation time. One can
> rely on getting/returning memory in constant time. The heap caters
> for too many different cases (not specialized enough) and using it
> does not guarantee consistent behaviour over a range of scenarios.
> Therefore - what exactly are you going to measure? If you do need
> deterministic behaviour, the heap is not good enough. Most of the
> time it is, though.
>
> IM(h)O the behaviour of the stack wrt. allocation/deallocation time
> is more deterministic (my impression). For me that would be an
> interesting debate.


That is what I would expect. The compiler can figure out where a object
should go relative to the stack pointer during compile time, all
compilers of which I have studied the assembly output do this. At
runtime accessing an object on the stack is simply a matter of applying
a fixed offset to the stack pointer.

Allocating memory on the heap is typically slower because in this case
the address where the object should must be determined at runtime. In
most cases the time it takes to allocate memory on the heap is not
deterministic.

Once the memory is allocated I don't see any particular reason why
accessing an object on the stack should slower or faster than an object
on the heap on a typical architecture.

 
Reply With Quote
 
BGB
Guest
Posts: n/a
 
      11-09-2011
On 11/9/2011 1:38 PM, Paavo Helde wrote:
> BGB<(E-Mail Removed)> wrote in news:j9d8vv$788$(E-Mail Removed):
>
>> On 11/8/2011 1:52 PM, Cholo Lennon wrote:
>>> On 07/11/2011 19:28, BGB wrote:
>>>> On 11/7/2011 9:47 AM, Victor Bazarov wrote:
>>>>> On 11/7/2011 11:27 AM, Nephi Immortal wrote:
>>>>>> [..]
>>>>>> How big can stack hold on 32 bits machine? Should it hold between
>>>>>> 500 megabytes and 1 gigabytes of memory?
>>>>>
>>>>> It is usually controlled by the settings of your linker.
>>>>>
>>>>
>>>> and usually *much* smaller...
>>>>
>>>> on Windows, the default size if 4MB.
>>>>
>>>
>>> Correction: The default size, at least in Win32/VC++, is 1 MB, not 4
>>> MB.
>>>

>>
>> funny, I had thought I had read before that it was 4MB.

>
> IIRC it is 1M in 32-bit and 4M for 64-bit apps. So you are both right


that could be it...


I have developed both 32 and 64 bit apps, and a lot of when I was
looking into this stuff was when building 64-bit stuff.

I eventually returned to compiling for 32-bits though mostly because I
am still using some 32-bit systems, but in the future may go 64-bits only.

 
Reply With Quote
 
Richard Damon
Guest
Posts: n/a
 
      11-10-2011
On 11/9/11 2:16 PM, Dombo wrote:
>
> Once the memory is allocated I don't see any particular reason why
> accessing an object on the stack should slower or faster than an object
> on the heap on a typical architecture.
>


Actually the heap may be slightly slower as the stack variable is at an
addressed based on a value that is already sitting in the registers (the
stack pointer), while to get to the heap variable, the pointer to it may
need to be loaded from either a stack based or global variable.
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      11-10-2011
Jorgen Grahn <(E-Mail Removed)> wrote:
> Personally, and for "normal" C++ code, I'd start worrying about my
> design if I found myself needing more than 100KB or so of stack.
> That doesn't seem quite normal.


You clearly don't use many recursive algorithms.
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      11-10-2011
On Thu, 2011-11-10, Juha Nieminen wrote:
> Jorgen Grahn <(E-Mail Removed)> wrote:
>> Personally, and for "normal" C++ code, I'd start worrying about my
>> design if I found myself needing more than 100KB or so of stack.
>> That doesn't seem quite normal.

>
> You clearly don't use many recursive algorithms.


Does anybody?

I suppose I wouldn't mind one if there's a clearly defined max
recursion depth though.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Juha Nieminen
Guest
Posts: n/a
 
      11-10-2011
Jorgen Grahn <(E-Mail Removed)> wrote:
> On Thu, 2011-11-10, Juha Nieminen wrote:
>> Jorgen Grahn <(E-Mail Removed)> wrote:
>>> Personally, and for "normal" C++ code, I'd start worrying about my
>>> design if I found myself needing more than 100KB or so of stack.
>>> That doesn't seem quite normal.

>>
>> You clearly don't use many recursive algorithms.

>
> Does anybody?


You probably use them all the time, even without realizing. (Quicksort
is a recursive algorithm, and std::sort() usually uses introspective sort,
which uses quicksort as one of its steps.)

I use them from time to time when I need to implement algorithms which
are very recursive in nature. Often implementing them non-recursively
makes the implementation significantly more complicated (and usually
longer) than the recursive version.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
C/C++ compilers have one stack for local variables and return addresses and then another stack for array allocations on the stack. Casey Hawthorne C Programming 3 11-01-2009 08:23 PM
Re: slow slow slow! Expert lino fitter Computer Support 5 12-12-2008 04:00 PM
Re: slow slow slow! chuckcar Computer Support 0 12-10-2008 11:25 PM
Re: slow slow slow! Beauregard T. Shagnasty Computer Support 2 12-10-2008 09:03 PM
Re: slow slow slow! Expert lino fitter Computer Support 0 12-10-2008 02:33 PM



Advertisments