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: a07f3367d7,aba1514f4a1fc450,start X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.66.72.73 with SMTP id b9mr1660753pav.9.1345990835167; Sun, 26 Aug 2012 07:20:35 -0700 (PDT) Path: t10ni62970945pbh.0!nntp.google.com!npeer03.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!news.snarked.org!newsfeed.news.ucla.edu!ihnp4.UCSD.Edu!nntp.ucr.edu!solaris.cc.vt.edu!news.vt.edu!newsfeed-00.mathworks.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Bill Findlay Newsgroups: comp.arch,comp.lang.ada Subject: Re: Have the Itanium critics all been proven wrong? Date: Wed, 22 Aug 2012 23:35:18 +0100 Message-ID: References: <632eec054470aafb59e98744e950ea8b@dizum.com> Mime-Version: 1.0 X-Trace: individual.net 3QGhv/pl7+oHl3ZOTSM78Av72MyizoYe4R4rX2A/a+cGo02mwk8JyBM3pjDl/4CjBA Cancel-Lock: sha1:WU5QcpEWaviBCjXudwKCULMgMtI= User-Agent: Microsoft-Entourage/12.33.0.120411 Thread-Topic: Have the Itanium critics all been proven wrong? Thread-Index: Ac18r2Dff8NVgiFRTUqvVWblEJtY2wEBwcWv X-Received-Bytes: 3496 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: 2012-08-22T23:35:18+01:00 List-Id: Following up my own post ... On 17/08/2012 20:34, in article CC545B6F.1BA11%yaldnif.w@blueyonder.co.uk, "Bill Findlay" wrote: > On 17/08/2012 20:17, in article k0m5c3$t6t$1@dont-email.me, "Stephen Fuld" > wrote: > >> On 8/17/2012 2:05 AM, Nomen Nescio wrote: >>> The point of Ada is safety and runtime checks. That is provided through >>> intensive compilation and an engineered runtime system. In a bare metal Ada, >>> there is a limit to what safety it can provide and the runtime checks will >>> introduce overhead over C. Otherwise Bill is arguing that there is a free >>> lunch, and we see that can't very well be. >> >> I don't think he is arguing for a free lunch, just a relatively low cost >> one. Note that, as has been repeatedly pointed out, things like C's poor >> aliasing limits prevent some optimizations that other languages allow. >> So while there is a cost to the additional run time checks (the >> compilation stuff doesn't cost at run time), there are some advantages >> to using other languages too. And if the cost is relatively small, it >> may be worth the cost for the gain in security, reliability, etc. > > Runtime security is not the same thing as runtime checks. The magnitude of the checking "overhead" has been called into question. Should it 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. 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 -> faster code! Another program of mine, an assembler of about 10KSLOC, runs 1% faster with default checking than it does with checking completely suppressed. Such are the vagaries of performance measurement with modern CPUs. So for some programs, at least, the overhead due to runtime checking is down near the noise level. -- Bill Findlay with blueyonder.co.uk; use surname & forename;