Re: > fails. Because heaps are unlimited whilst stacks are not.

fir wrote:

fir wrote:

bart wrote:

On 20/03/2024 14:02, fir wrote:
>

i know somewhat how it looks like in win32 :
>
generally the addres space aplication have os from 0x0000 0000 to
0x7fff ffff - which is only 2 gigabytes
>
(hovever i like it and still prefer writing my windows programs on
win32 than win 64, 2 gigabytes of ram is enough for me)
>
your program is by default placed at 0x0040 0000 (which is 4MB from
start of adres space)..

>
That's no longer the case with 64-bit machines, not if you use products
like gcc. This program:
>
   #include "stdio.h"
   int main(void) {
       printf("%p\n", main);
   }
>
displays 00007ff64a931591 when compiled with gcc. Even on 32-bits using
`gcc -m32`, it shows 0076155c.
>

>
at least this is what i know
>
>
the stack in turn is betwwwen your app start that +4MB and the
starting point, im not exactly syre but its probably something about
+3M down do +1M approximatelly
>
stack could be set to bigger in your exe heder your exe has 9may be
modified by -something switch in gcc comandline) and i not tested it
afair (or rather tested but forgot the strict conclusions) but i dont
se nthing specially wrong even in setting this stack to 100 MB
>
2 MB by default is silly and if you have 10 GB of ram putting 100 MB
for stack is not even a waste becouse if it is not used it only
consumes "logical" ram pages afair but reall ram is not even attached

>
I don't think using a giant stack just one for the benefit of one
badly-designed function in one library inside a big application is a
good approach.
>

>
but you call this function badly designed becouse it can overflow stack
>
- if it cant it is not badly designed then (unles you say on something
other)
>
this recursion in fact is not badly designed imo - you only need to be
aware of constraints of data you used it to (and if you care of
constraints of your code you could also somewhat care of constraints on
data)
>
its suboptimal as to speed but i wouldnt cal it "badly designed"
>
as i said in another thread the error may be to declare stack size,
it not necessarely need to be declared maybe - then you use stack until
the ram will end - as today people use normal ram, nearly none
application is ready to situatuion that ram ends and heap alocations
fail..so with stack may be tha same
>
>
>

Maybe the routine is never called. Or it's called once then never called
again but the stack is now committed.
>
Your floodfill routine uses 48 bytes per call (with my compiler; it
varies). To floodfill all the pixels in a 3000x4000 pixel image for
example, would need nearly 600MB of stack, and would involve calls
nested 12 million deep.
>
>

>
there was an shortcut in it you dont need to pass the 2 colors in calls
so i think it rather should use int x int y and ret adress it is 12
bytes (on 32 bit, i compile 32 bit only)
>

>
i wouldnt say its badly designed but for sure its kinda brute-force
but not in kinds of like cpu and iterations (like counting milion
objects collisions with another milion objets) but more bruteforce in
stack usage - but brute force methods are so nice..they just dont work
becouse of big numbers
>
possibly there may be written a method of thi recolorisation wich uses
50 bytes of ram, but here i wonder if use even 300 Mb of ram for a blink
of an eye time is not standable

also not how this call queue (ir it would be in c strict runtime (by strict runtime i mean this what is compiled-in by compiler like inside a program, not a runtime library) )would improve things
with this call queue pixel in one generation just spawns a 1-pixel thin border around it - then in next generation it spawns another thin border - and the ram consuption if im not wrong is limited to this older border that is processed and the newer wjich is spawned so even for 10000x10000 image the ram consumption should be small
they dhould do it in sixties