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!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed00.sul.t-online.de!t-online.de!newsfeed.freenet.de!newsfeed01.chello.at!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Newsgroups: comp.lang.ada Subject: Re: GNAT compiler switches and optimization From: Georg Bauhaus In-Reply-To: <2jps04-ggi.ln1@newserver.thecreems.com> 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> <453bb145$0$5716$9b4e6d93@newsspool3.arcor-online.net> <2jps04-ggi.ln1@newserver.thecreems.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: # Message-ID: <1161562253.5362.82.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Date: Mon, 23 Oct 2006 02:10:53 +0200 NNTP-Posting-Date: 23 Oct 2006 02:08:39 CEST NNTP-Posting-Host: 53df5cce.newsspool1.arcor-online.net X-Trace: DXC=H8Zd=:]]PD>UoRk[hk2Wa4Fo<]lROoR1^YC2XCjHcb9Un@TI_aiEn2A:ho7QcPOV3]7`=QlWD1_8MIVlL^W]\V> X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:7147 Date: 2006-10-23T02:08:39+02:00 List-Id: On Sun, 2006-10-22 at 14:24 -0400, Jeffrey Creem wrote: > It sounds like you are running some different code and I'd be hestitant > to make any assertions about runtime for certain constructs without > seeing it since It is appended below. > 2) You mention something about just accessing first, middle and last of > your arrays so it really sounds like you really are just timing > allocations and and not actually really hitting the array indexing > (though hard to say without seeing the code). Yes, I had concentrated on just this question, asked by Thomas Krauss, about stack versus heap allocation. If a program is not frequently allocating and freeing arrays (or matrices, etc.), the the effects might be less of an issue, if they are an issue at all when there is no initialization. But I imagined allocation is just what is happening all the time if you have a function that computes matrices of varying sizes? OTOH, I find very different results on GNU/Linux (for which I only have a number of GNATs). Stack allocation appears to be consuming next to no time. (Commit on write? Just remembering an offset?) Below the following program, there is a patch that adds trivial initialization loops. With them, a comparison of stack vs heap on GNU/Linux seems in favor of the stack. I can't check this on Windows right now, though. with Ada.Calendar; with Ada.Text_IO; with Ada.Unchecked_Deallocation; procedure main is use Ada.Calendar, Ada; type LIST is array (NATURAL range <>) of BOOLEAN; for LIST'component_size use 8; -- for a "normal" array, not packed or other magic type LIST_PTR is access LIST; procedure free is new Ada.Unchecked_Deallocation (LIST, LIST_PTR); accu: BOOLEAN := false; -- The allocating functions read and write this variable -- using components of the local arrays. -- (This should prevent some optimizations.) function allocate(size: POSITIVE) return BOOLEAN; -- use a local `LIST` of length `size` function allocate_heap(size: POSITIVE) return BOOLEAN; -- use a pointer to a new `LIST` of length `size` function image(t: TIME) return STRING; -- the current time as a `STRING` value function allocate(size: POSITIVE) return BOOLEAN is done: LIST(1 .. size); -- pragma volatile(done); result: BOOLEAN; begin if done(size / 2) then result := false; end if; done(done'last) := accu and done(done'first); result := done(done'last) and done(done'first); return result; end allocate; function allocate_heap(size: POSITIVE) return BOOLEAN is done: LIST_PTR; result: BOOLEAN; begin done := new LIST(1 .. size); if done(size / 2) then result := false; end if; done(done'last) := accu and done(done'first); result := done(done'first) and done(done'first); Free(done); return result; end allocate_heap; function image(t: TIME) return STRING is year: YEAR_NUMBER; day: DAY_NUMBER; month: MONTH_NUMBER; sec: DURATION; begin split(t, year, month, day, sec); return YEAR_NUMBER'image(year) & MONTH_NUMBER'image(month) & DAY_NUMBER'image(day) & DURATION'image(sec); end image; start, finish: TIME; begin Text_IO.put_line("using a stack"); start := clock; for run in 1 .. 25 loop for k in 1 .. 2000 loop accu := allocate(5000 * k); end loop; end loop; finish := clock; Text_IO.put_line("from" & image(start) & " to" & image(finish) & " = " & DURATION'image(finish - start)); Text_IO.put_line("accu " & BOOLEAN'image(accu)); Text_IO.put_line("using a heap"); start := clock; for run in 1 .. 25 loop for k in 1 .. 2000 loop accu := allocate_heap(5000 * k); end loop; end loop; finish := clock; Text_IO.put_line("from" & image(start) & " to" & image(finish) & " = " & DURATION'image(finish - start)); Text_IO.put_line("accu " & BOOLEAN'image(accu)); end main; --- stack_use_testing.ada 2006/10/22 23:51:48 1.1 +++ stack_use_testing.ada 2006/10/22 23:52:12 @@ -33,2 +33,3 @@ begin + for k in done'range loop done(k) := false; end loop; if done(size / 2) then @@ -46,2 +47,3 @@ done := new LIST(1 .. size); + for k in done'range loop done(k) := false; end loop; if done(size / 2) then @@ -75,4 +77,4 @@ start := clock; - for run in 1 .. 25 loop - for k in 1 .. 2000 loop + for run in 1 .. 2 loop + for k in 1 .. 200 loop accu := allocate(5000 * k); @@ -90,4 +92,4 @@ start := clock; - for run in 1 .. 25 loop - for k in 1 .. 2000 loop + for run in 1 .. 2 loop + for k in 1 .. 200 loop accu := allocate_heap(5000 * k);