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,d2fe8ae54035f25f X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.181.12.35 with SMTP id en3mr9551314wid.2.1356798736909; Sat, 29 Dec 2012 08:32:16 -0800 (PST) Path: i11ni328047wiw.0!nntp.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Bill Findlay Newsgroups: comp.lang.ada Subject: Re: A couple of quick questions Date: Sat, 29 Dec 2012 16:32:22 +0000 Message-ID: References: <195201b7-c447-4580-aeb4-1c2329ee45e0@googlegroups.com> <0387724a-7fd2-4317-ba16-d3322dd0fdec@googlegroups.com> <87zk0xkucv.fsf@mid.deneb.enyo.de> Mime-Version: 1.0 X-Trace: individual.net YQg3F/HqTRLjMaY7fcbpiQxetf/lRTUR1awIEi7fHMEMl/6U56rn3yPb/1LwB4+gyW Cancel-Lock: sha1:ycS1Wlh2i+Qj4CXlhKjjDoLxVd8= User-Agent: Microsoft-Entourage/12.33.0.120411 Thread-Topic: A couple of quick questions Thread-Index: Ac3l4hO658eDqD+RNE6qQXMkOl4ZVA== Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: 2012-12-29T16:32:22+00:00 List-Id: On 29/12/2012 16:15, in article ea507393-d4ff-4451-b1e8-4d055da9b794@googlegroups.com, "Shark8" wrote: > On Saturday, December 29, 2012 4:47:44 AM UTC-6, Florian Weimer wrote: >> * Dufr: >> >>> Is the efficiency of the compiled code by penalized in any way by >>> the putative bloat of the language? >> >> [...] Run-time checks (such as overflow checks and array bounds >> checks) are typically bloat which increases instruction cache pressure >> and decreases effective execution speed. > > But you're doing Ada a bit of a disservice here: Ada compilers are typically > smart enough to omit range-checks where the value can be guaranteed as valid, > such as "FOR Index IN Array'Range Loop [...]", no check is needed because the > type of Index guarantees that it is valid. Indeed. Should the checking "overhead" be prohibitive in special cases, a selection of particular checks can be suppressed over well-defined scopes. However, the real cost is often surprisingly small. Here is some actual data, rather than speculation. My KDF9 emulator is about 20KSLOC. Compiled with all runtime checking disabled, it runs 1.25% faster than when compiled with default checking. That is 1.25 PERCENT faster, not 1.25 TIMES. 8-) Interestingly, if I do not suppress absolutely all checks, but enable them for "non-inner loop" modules, it runs a further 1.25% faster than when completely unchecked. More checks, but faster execution! Another program of mine, an assembler of about 10KSLOC, runs about 1% faster with default checking than it does with checking completely suppressed! Such are the vagaries of performance with modern CPUs. So for some programs, at least, the overhead due to runtime checking is down at the measurement noise level. >> Code for abort deferral is >> automatically inserted by the compiler and slows down the program, >> even if no asynchronous transfer of control ever occurs. Then use: pragma Restrictions(No_Abort_Statements); -- Bill Findlay with blueyonder.co.uk; use surname & forename;