From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,123c40d62c632159 X-Google-Attributes: gid103376,public From: Laurent Guerby Subject: Re: Stack based allocation vs. Dynamic allocation Date: 2000/05/31 Message-ID: <86og5m7aig.fsf@acm.org>#1/1 X-Deja-AN: 629590004 References: X-Trace: front6m.grolier.fr 959803019 21038 194.158.111.170 (31 May 2000 19:56:59 GMT) Organization: Club-Internet (France) NNTP-Posting-Date: 31 May 2000 19:56:59 GMT Newsgroups: comp.lang.ada Date: 2000-05-31T19:56:59+00:00 List-Id: Dale Stanbrough writes: > I've fixed the code, and added in a few extras. I have compared various > variations of the code (in C and in Ada), the results follow... [...] Note that the Ada versions is not really comparable with the C version since you have array bound safety in Ada (I guess the compiler removed the checks) and not in C. I'm surprised the Ada heap version is faster than the C one since GNAT calls the system malloc (hmmm it might be a GNU malloc vs Solaris malloc issue if you're using FSU threads). Also you can have more fun by having the size of the local array variable being a function of i, since there is no C stack based equivalent (GNU C has it as a language extension though). The only problem with stack based allocation is in a 32 bits address space multi threaded application context where you might have big arrays, you have then an unsolvable problem with thread stack size. On the software I'm working on, we had to move some stack based (dynamic) array to the heap (with controlled types for automatic deallocation) for this reason. -- Laurent Guerby