Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #11300 > unrolled thread

Stack is slow than heap?

Back to article view | Back to comp.lang.c++

Contents

  Stack is slow than heap? Nephi Immortal <immortalnephi@gmail.com> - 2011-11-07 08:27 -0800
    Re: Stack is slow than heap? Victor Bazarov <v.bazarov@comcast.invalid> - 2011-11-07 11:47 -0500
      Re: Stack is slow than heap? BGB <cr88192@hotmail.com> - 2011-11-07 15:28 -0700
        Re: Stack is slow than heap? Nephi Immortal <immortalnephi@gmail.com> - 2011-11-08 07:35 -0800
          Re: Stack is slow than heap? "io_x" <a@b.c.invalid> - 2011-11-08 18:17 +0100
            Re: Stack is slow than heap? Nephi Immortal <immortalnephi@gmail.com> - 2011-11-08 11:39 -0800
              Re: Stack is slow than heap? "io_x" <a@b.c.invalid> - 2011-11-09 03:42 +0100
                Re: Stack is slow than heap? "io_x" <a@b.c.invalid> - 2011-11-09 03:55 +0100
                  Re: Stack is slow than heap? "io_x" <a@b.c.invalid> - 2011-11-09 03:58 +0100
        Re: Stack is slow than heap? Cholo Lennon <chololennon@hotmail.com> - 2011-11-08 17:52 -0300
          Re: Stack is slow than heap? BGB <cr88192@hotmail.com> - 2011-11-09 00:09 -0700
            Re: Stack is slow than heap? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-11-09 17:33 +0000
              Re: Stack is slow than heap? Juha Nieminen <nospam@thanks.invalid> - 2011-11-10 06:44 +0000
                Re: Stack is slow than heap? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-11-10 20:14 +0000
                  Re: Stack is slow than heap? Juha Nieminen <nospam@thanks.invalid> - 2011-11-10 21:01 +0000
                    Re: Stack is slow than heap? Cholo Lennon <chololennon@hotmail.com> - 2011-11-10 18:55 -0300
                      Re: Stack is slow than heap? Juha Nieminen <nospam@thanks.invalid> - 2011-11-11 07:37 +0000
                        Re: Stack is slow than heap? gwowen <gwowen@gmail.com> - 2011-11-11 02:18 -0800
                    Re: Stack is slow than heap? Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-11-10 22:34 +0000
            Re: Stack is slow than heap? Paavo Helde <myfirstname@osa.pri.ee> - 2011-11-09 14:38 -0600
              Re: Stack is slow than heap? BGB <cr88192@hotmail.com> - 2011-11-09 15:30 -0700
    Re: Stack is slow than heap? "io_x" <a@b.c.invalid> - 2011-11-07 19:32 +0100
      Re: Stack is slow than heap? "io_x" <a@b.c.invalid> - 2011-11-07 19:50 +0100
        Re: Stack is slow than heap? Edek <edek.pienkowski@gmail.com> - 2011-11-07 20:10 +0100
    Re: Stack is slow than heap? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-08 03:00 -0800
      Re: Stack is slow than heap? Nephi Immortal <immortalnephi@gmail.com> - 2011-11-08 07:45 -0800
        Re: Stack is slow than heap? "Fred Zwarts \(KVI\)" <F.Zwarts@KVI.nl> - 2011-11-08 17:28 +0100
        Re: Stack is slow than heap? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-09 02:20 -0800
          Re: Stack is slow than heap? Werner <werasm@gmail.com> - 2011-11-09 03:03 -0800
            Re: Stack is slow than heap? Dombo <dombo@disposable.invalid> - 2011-11-09 20:16 +0100
              Re: Stack is slow than heap? Richard Damon <news.x.richarddamon@xoxy.net> - 2011-11-09 23:35 -0500

Page 2 of 2 — ← Prev page 1 [2]

#11352

On 11/9/2011 1:38 PM, Paavo Helde wrote:
> BGB<cr88192@hotmail.com>  wrote in news:j9d8vv$788$1@news.albasani.net:
>
>> 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.

[toc] | [prev] | [next] | [standalone]

#11304

"Nephi Immortal" <immortalnephi@gmail.com> ha scritto nel messaggio
news:3b85a1bb-7531-4d9c-9c18-77e93a5d52b7@r7g2000vbg.googlegroups.com...
I always agree that stack is very effectively fast to push built-in
type variables into stack and pop them out of it between function
calls.  Small stack size is very important.  I have no idea how big it
can hold hundreds or thousands of variables.

#this is io_x
#you have to ask it to the compiler
#or to the assembler

It is possible to overflow the stack size if you use too many buffers

#yes but it has to consume all stack size

or small arrays.  Hundreds or thousands of buffers or small arrays are
pushed into stack if you call 100 function calls before stack grows

#if you call 100 function as
#for(i=0; i<100; ++i) func(x);
#the stack grow as it is only one func() call.
#the stack grow to number of function call
#only if the function is recursive i.e. call itself

bigger fast.  Error assert message is triggered to report stack
overflow.

#in MS windows i found overflow of stack and seg fault
#only in case of phatological recursive functions e.g
#int  f(int  x){return  f(x);}

How big can stack hold on 32 bits machine?  Should it hold between
500 megabytes and 1 gigabytes of memory?

#for me it is too much; i think could be ok 1-20MB
#for to be jenerous

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

#4096

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

#an array of chars

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.

#it is the faster way to obtain memory i know
#it is just one instruction for obtain memory
#s-=memSize
#s point to a memSize space of memory
#and one instruction for free that memory
#s+=memSize where people call s "esp"
#it is the way to use memory [memory read/write faster than heap]
#because CPUs like
#function local use of memory [at last i think that]

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?

#i prefer use the stack for all it is not a static string
#initializated e.g  char a[]="this is a static string inizializated";
#that i prefer as global one
#the same of all data has need one initialization at start of the
#program
#as C/C++ compilers i presume

For example:

void foo( const char *dest )
{
char buffer[ 1024 ]; // pusb 1,024 bytes into stack
// char *buffer = g_buffer; // set pointer to buffer in global scope

char *pBuffer = buffer;
char *pDest = dest;

do
{
*pBuffer = *pDest;
++pBuffer;
++pDest;
#here i would write
#if(pBuffer-buffer>=1024) return error;
}
while( *pDest != ‘\0’ );

*pBuffer = ‘\0’;

// Create more buffers or small arrays and copy
// them into one buffer
// Do algorithm

cout << pBuffer << endl;
#i think would be "cout << buffer<<endl;"

// Pop all buffers and small arrays out of stack
// and exit function
}

Perhaps, you suggest to use heap in global scope.

// global scope
char *buffer = 0; // or you can use string class or vector class

int main()
{
buffer = new char[ 4096 ];

foo( buffer );

delete [] buffer;

// you can replace new / delete to string class or vector class
}

Please answer one question.  How big can stack hold up to 500
megabytes on 32 bits machine?

#it would be 501MB of stack...
#but it is not need 500MB for the stack
#it would need only for pathological recursive functions
#and for 500MB stack variables of some function [too much]
#e.g
#int f(int a){char big[500MB of space]; etc}
#i don't know if this is as above
#int f(int a){char big[500*1024*1024]; etc }
#TOO MUCH....

[toc] | [prev] | [next] | [standalone]

#11306

"io_x" <a@b.c.invalid> ha scritto nel messaggio
news:4eb82371$0$1391$4fafbaef@reader1.news.tin.it...
> #if you call 100 function as
> #for(i=0; i<100; ++i) func(x);
> #the stack grow as it is only one func() call.
> #the stack grow to number of function call
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> #only if the function is recursive i.e. call itself
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

the above is false
for example if
int  f0(int x){return  x-1;}
int  f1(int x){return f0(x);}
int  f2(int x){return f1(x);}

f2(3)
make grow the stack to number of function call
even if f2() is not recursive

but it is difficult to find such way to dispose
functions...

[toc] | [prev] | [next] | [standalone]

#11308

On 11/07/2011 07:50 PM, io_x wrote:
> "io_x"<a@b.c.invalid>  ha scritto nel messaggio
> news:4eb82371$0$1391$4fafbaef@reader1.news.tin.it...
>> #if you call 100 function as
>> #for(i=0; i<100; ++i) func(x);
>> #the stack grow as it is only one func() call.
>> #the stack grow to number of function call
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> #only if the function is recursive i.e. call itself
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> the above is false
> for example if
> int  f0(int x){return  x-1;}
> int  f1(int x){return f0(x);}
> int  f2(int x){return f1(x);}
>
> f2(3)
> make grow the stack to number of function call
> even if f2() is not recursive
>
> but it is difficult to find such way to dispose
> functions...

Two ways: inlining, that's one, but it might be limited in
depth, VC had some flags saying how many recursive calls to
inline.

Also C/C++ compilers do something called tail-call.
Tail-call replaces return-what-call-returns with
a jump (a machine goto). Obviously, there must be another return
somewhere eventually or an exception and this return
replaces the return-call->return; it is one of the
reasons why debugging optimised code or getting the
exception stack might not be very productive in C++.

In this way recursive algorithms can become iterative
or mixed in execution though.

Edek

[toc] | [prev] | [next] | [standalone]

#11318

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).

On Nov 7, 4:27 pm, Nephi Immortal <immortalne...@gmail.com> wrote:

>         I always agree that stack is very effectively fast to push built-in
> type variables

what about non-built in types? isn't any small type quick to push and
pop?

> into stack and pop them out of it between function
> calls.  Small stack size is very important.

why?

> I have no idea how big it
> can hold hundreds or thousands of variables.

depends on the implementation (this is the answer to most of your
questions)

>         It is possible to overflow the stack size if you use too many buffers
> or small arrays.

or one enormous array. Genrally speaking if you've got a lot of stuff
use dynamic (new/delete or a container) rather than automatic memory.

<snip>

> Error assert message is triggered to report stack overflow.

maybe. It depends on the implementation

<snip>

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

I've never been given this option!. I'd choose the smaller number if
1024 bytes were enough for my function. Wouldn't it be a good idea to
pick the correct number?

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

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

> Every time, function is called and it
> takes CPU time

not much. It probably isn't proportional to the buffer size.

> 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.

have you measured it?

>         What option do you have?  Do you prefer to create global variables

no. Global data is hardly ever a good idea.

> to
> hold buffer or small array into heap through reference or pointers
> between function calls can be faster?

how do you know your function is too slow? What is the buffer used
for? i/o?

<snip>

>         Please answer one question.  How big can stack hold up to 500
> megabytes on 32 bits machine?

I don't understand. This doesn't parse.

[toc] | [prev] | [next] | [standalone]

#11319

On Nov 8, 5:00 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
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 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.

>
> On Nov 7, 4:27 pm, Nephi Immortal <immortalne...@gmail.com> wrote:
>
> >         I always agree that stack is very effectively fast to push built-in
> > type variables
>
> what about non-built in types? isn't any small type quick to push and
> pop?
>
> > into stack and pop them out of it between function
> > calls.  Small stack size is very important.
>
> why?
>
> > I have no idea how big it
> > can hold hundreds or thousands of variables.
>
> depends on the implementation (this is the answer to most of your
> questions)
>
> >         It is possible to overflow the stack size if you use too many buffers
> > or small arrays.
>
> or one enormous array. Genrally speaking if you've got a lot of stuff
> use dynamic (new/delete or a container) rather than automatic memory.
>
> <snip>
>
> > Error assert message is triggered to report stack overflow.
>
> maybe. It depends on the implementation
>
> <snip>
>
> >         After you write a function, do you prefer to store one buffer to hold
> > 1,024 bytes or 4,096 bytes?
>
> I've never been given this option!. I'd choose the smaller number if
> 1024 bytes were enough for my function. Wouldn't it be a good idea to
> pick the correct number?
>
> > 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;
	I guess temporary buffer should hold sufficient 4,096 bytes or less.


>
> > Every time, function is called and it
> > takes CPU time
>
> not much. It probably isn't proportional to the buffer size.
>
> > 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.
>
> have you measured it?
>
> >         What option do you have?  Do you prefer to create global variables
>
> no. Global data is hardly ever a good idea.
>
> > to
> > hold buffer or small array into heap through reference or pointers
> > between function calls can be faster?
>
> how do you know your function is too slow? What is the buffer used
> for? i/o?
>
> <snip>
>
> >         Please answer one question.  How big can stack hold up to 500
> > megabytes on 32 bits machine?
>
> I don't understand. This doesn't parse.

[toc] | [prev] | [next] | [standalone]

#11321

"Nephi Immortal"  wrote in message 
news:2ec220c4-7264-4980-8802-57ad7c3c66eb@s7g2000yqa.googlegroups.com...
>
>On Nov 8, 5:00 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
>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 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.

Heap and stack are usually accessing the same memory. So access times are 
not different. Only allocation/release times are different. 
Allocating/releasing stack is usually somewhat faster.

> ...

>>
>> >         After you write a function, do you prefer to store one buffer 
>> > to hold
>> > 1,024 bytes or 4,096 bytes?
>>
>> I've never been given this option!. I'd choose the smaller number if
>> 1024 bytes were enough for my function. Wouldn't it be a good idea to
>> pick the correct number?
>>
>> > 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;
>I guess temporary buffer should hold sufficient 4,096 bytes or less.

It depends on what you want to do. If you want to output one line of text, 
then a buffer of about 100 characters may be sufficient. If you want to 
refresh a whole screen in one go, then it depends on the screen resolution 
and the possible values of one cell. A screen with a resolution of about 200 
x 100 and about 200 possible values per cell will need already a buffer of 
at about 20000 bytes.

> ... 

[toc] | [prev] | [next] | [standalone]

#11335

On Nov 8, 3:45 pm, Nephi Immortal <immortalne...@gmail.com> wrote:
> On Nov 8, 5:00 am, Nick Keighley <nick_keighley_nos...@hotmail.com>
> > On Nov 7, 4:27 pm, Nephi Immortal <immortalne...@gmail.com> 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 many times.

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>

[toc] | [prev] | [next] | [standalone]

#11336

On Nov 9, 12:20 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On Nov 8, 3:45 pm, Nephi Immortal <immortalne...@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#11346

Op 09-Nov-11 12:03, Werner schreef:
> On Nov 9, 12:20 pm, Nick Keighley<nick_keighley_nos...@hotmail.com>
> wrote:
>> On Nov 8, 3:45 pm, Nephi Immortal<immortalne...@gmail.com>  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.

[toc] | [prev] | [next] | [standalone]

#11353

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.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c++

csiph-web