Path: ...!news.misty.com!weretis.net!feeder6.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: fir <fir@grunge.pl>
Newsgroups: comp.lang.c
Subject: Re: > fails. Because heaps are unlimited whilst stacks are not.
Date: Wed, 20 Mar 2024 17:57:37 +0100
Organization: i2pn2 (i2pn.org)
Message-ID: <utf4i0$2gkj1$1@i2pn2.org>
References: <uteqa1$2g5vi$1@i2pn2.org> <utf2fj$1j1tv$1@dont-email.me> <utf3vd$2gjrr$1@i2pn2.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 20 Mar 2024 16:57:36 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2642529"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="+ydHcGjgSeBt3Wz3WTfKefUptpAWaXduqfw5xdfsuS0";
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24
In-Reply-To: <utf3vd$2gjrr$1@i2pn2.org>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 4563
Lines: 91

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