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 18:11:05 +0100
Organization: i2pn2 (i2pn.org)
Message-ID: <utf5b7$2gloe$1@i2pn2.org>
References: <uteqa1$2g5vi$1@i2pn2.org> <utf2fj$1j1tv$1@dont-email.me> <utf3vd$2gjrr$1@i2pn2.org> <utf4i0$2gkj1$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 17:11:03 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="2643726"; 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: <utf4i0$2gkj1$1@i2pn2.org>
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 5278
Lines: 104

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