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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,7767a311e01e1cd X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!news4.google.com!news2.volia.net!npeer.de.kpn-eurorings.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Sun, 22 Oct 2006 20:02:24 +0200 From: Georg Bauhaus Organization: elsewhere User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: GNAT compiler switches and optimization References: <1161341264.471057.252750@h48g2000cwc.googlegroups.com> <9Qb_g.111857$aJ.65708@attbi_s21> <434o04-7g7.ln1@newserver.thecreems.com> <4539ce34$1_2@news.bluewin.ch> <453A532F.2070709@obry.net> <9kfq04-sgm.ln1@newserver.thecreems.com> <1161517716.455743.223200@b28g2000cwb.googlegroups.com> In-Reply-To: <1161517716.455743.223200@b28g2000cwb.googlegroups.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <453bb145$0$5716$9b4e6d93@newsspool3.arcor-online.net> NNTP-Posting-Date: 22 Oct 2006 19:58:30 CEST NNTP-Posting-Host: 4b0639bc.newsspool3.arcor-online.net X-Trace: DXC=_9Z^kC<6[2WHigV@eW57PQMcF=Q^Z^V3X4Fo<]lROoRQgUcjd<3m<;RHgaNXL43oaSPCY\c7>ejVXdNPVV9WjfQRV?Hi7BWI7VT X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:7136 Date: 2006-10-22T19:58:30+02:00 List-Id: tkrauss wrote: > That takes the memory from the stack rather than the heap though, no? > I assume there is a compiler switch to increase the stack size so the > code wouldn't die, but is that the "normal" way of allocating > memory? I'm trying to not look like _too_ much of an Ada neophyte :) > I just tested a similar thing using two different compilers. A function that uses a local array of a size determined by a function parameter. The result was that - GNAT may trigger constraint errors when the array size exceeds some limit. The documentation tells the compiler user that this is an operating system issue and should be addressed at this level IIUC. (Does this comment apply in this case?) - ObjectAda had no problem with local arrays of the same tens of millions of components. I've measured performance by calling the function many times with different Size parameters for the array. This has consistently shown that on this platform, GNAT code takes about at least twice as much time as OA code. (The time is not affected by -O?.) Using an allocator "new Big_Array(1 .. Size)" and an instance of Unchecked_Deallocation in place of simple variable allocation has two effects. - The execution time of ObjectAda code almost does not change. This lets me suspect that OA isn't necessarily using the primary stack for local variables. Indeed, the assembly listing shows calls on rts_ss_allocate (for the local array variable) versus rts_allocate (for an array allocator). The RTS function rts_ss_allocate is the link_name of the function System.RTS.TGT.Sec_Stack_Pkg.Allocate from the ObjectAda RTS. - The "GNAT heap version" performs about 2-3 times faster than the "GNAT stack version". (GNAT code that uses "new" instead of a simple local variable performs minimally to just slightly faster than the OA code using "new".) So there is a major difference in execution speed of programs that compute larger matrices if you use GNAT and simple array variables, but not allocators. Execution speed does not differ significantly using at least one other compiler (ObjectAda). I think that's a pity when seen from a "just Ada" perspective. There is one more thing (allocators) you have to think about if you want speed for local array variables when using GNAT. Windows x86, GNAT GPL 2006, and OA 8.2 U15. The first, middle and last element of the array are referenced. Pragma volatile has been tried, too.