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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,56525db28240414a X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.224.138.146 with SMTP id a18mr1369842qau.6.1343314442596; Thu, 26 Jul 2012 07:54:02 -0700 (PDT) Received: by 10.66.85.162 with SMTP id i2mr1788906paz.30.1343314335645; Thu, 26 Jul 2012 07:52:15 -0700 (PDT) Path: a15ni105485768qag.0!nntp.google.com!q21no16293048qas.0!news-out.google.com!b9ni60415685pbl.0!nntp.google.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!border6.newsrouter.astraweb.com!news.astraweb.com!border6.a.newsrouter.astraweb.com!ramfeed-1.ams.xsnews.nl!feed.xsnews.nl!border-1.ams.xsnews.nl!newsfeed.straub-nv.de!news.swapon.de!news.glorb.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Keean Schupke Newsgroups: comp.lang.ada Subject: Re: Efficient Sequential Access to Arrays Date: Tue, 24 Jul 2012 01:21:19 -0700 (PDT) Organization: http://groups.google.com Message-ID: <8712c264-3ce9-4e2b-ad26-4d7c2c2cb9d6@googlegroups.com> References: <01983f1c-f842-4b1f-a180-bcef531dad4c@googlegroups.com> <87ipdf4vh6.fsf@mid.deneb.enyo.de> <87394j3ag6.fsf@mid.deneb.enyo.de> NNTP-Posting-Host: 82.44.19.199 Mime-Version: 1.0 X-Trace: posting.google.com 1343118080 22968 127.0.0.1 (24 Jul 2012 08:21:20 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 24 Jul 2012 08:21:20 +0000 (UTC) In-Reply-To: <87394j3ag6.fsf@mid.deneb.enyo.de> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=82.44.19.199; posting-account=T5Z2vAoAAAB8ExE3yV3f56dVATtEMNcM User-Agent: G2/1.0 X-Received-Bytes: 2882 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-07-24T01:21:19-07:00 List-Id: On Sunday, 22 July 2012 19:41:29 UTC+1, Florian Weimer wrote: > * Keean Schupke: >=20 > > What is the best way to do that? The program uses extensive inlining > > and optimisation, so individual functions are hard to find in the > > output. By the time its compiled its about a single 32k function. >=20 > -gnatG shows you Ada-like code which is passed to the compiler > middle-end, and -fdump-tree-all writes files showing the results of > individual passes. At the moment my conclusion is with the current state of the compiler, you = cannot match the performance of the relative addressing version of this alg= orithm with indexed addressing.=20 Maybe compiler technology will improve (but that's not useful right now), a= nd maybe there's a better algorithm (but I don't know what it is). So for the moment it looks like I am going to stick with the relative addre= ssing as the solution that best addresses the project goals. It seems that for simple cases the belief that the compiler can optimise ar= ray indexing to be just as fast as pointer arithmetic is true, but it does = not appear to be the case for all algorithms. Certainly I seem to have one = of the cases where it is not true. As all the most common operations are su= pported by the data structures I am using in O(1) time, I don't hold out mu= ch hope of finding a faster algorithm more suited to indexed addressing. Cheers, Keean.