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: 103376,c4cb2c432feebd9d X-Google-Thread: 1094ba,c4cb2c432feebd9d X-Google-Thread: 101deb,15c6ed4b761968e6 X-Google-Attributes: gid103376,gid1094ba,gid101deb,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Thu, 25 May 2006 11:25:36 -0500 Message-ID: <4475DA61.3080001@comcast.net> Date: Thu, 25 May 2006 12:25:05 -0400 From: Bob Lidral User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada,comp.lang.fortran,comp.lang.pl1 Subject: Bounds Check Overhead [was: Re: Ada vs Fortran for scientific applications] References: <0ugu4e.4i7.ln@hunter.axlog.fr> <%P_cg.155733$eR6.26337@bgtnsc04-news.ops.worldnet.att.net> <6H9dg.10258$S7.9150@news-server.bigpond.net.au> <1hfv5wb.1x4ab1tbdzk7eN%nospam@see.signature> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.63.32.141 X-Trace: sv3-efZl+rxJ5wjyjEI1eTmZs95Lwo5+uKqT59YFAkBqj4iczSJHtYfrV2XdbLKD9kyPb6pUHuKG7P3rZLx!G6HyihR1aN/a9QuYMUlA4s6HEfp7AmHtHhEDjeAmh32tVEZme9pET8dLaTibLRI6 X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.32 Xref: g2news2.google.com comp.lang.ada:4464 comp.lang.fortran:10248 comp.lang.pl1:1709 Date: 2006-05-25T12:25:05-04:00 List-Id: Dr. Adrian Wrigley wrote: > [...] > The adverse consequences of exceeding bounds can be seen to > outweigh the (usually) modest costs in code size and performance that > even mature code should ship with checks enabled, IMO. > Compilers generally should be shipped with the 'failsafe' > options on by default. > -- > Adrian > Certainly the adverse consequences of exceeding bounds can be high -- as can the adverse consequences of using invalid pointer values. And with 64-bit (or even 32-bit) architectures and paging, code size is not as much of an issue as it has been for earlier architectures and memory management technologies. However, the performance hit of including explicit bounds checking can be significant -- especially for code with extremely short loops that are executed a lot of times. It's not just the size of the bounds check code compared with the size of the rest of the loop. The size of the bounds check code can increase the size of the loop enough to alter page usage and bounds checking can also mess up hardware branch prediction optimization. Granted, there are ways to optimize bounds checking for loops, including moving the bounds check out of the loop when possible. Before enabling universal array bounds checking for production code I'd recommend benchmarking the performance with and without the checks enabled to determine the real performance cost. Bob Lidral lidral at alum dot mit dot edu