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.1 required=5.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,2a34b7ad6c6a0774 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Efficiency of code generated by Ada compilers Date: Fri, 13 Aug 2010 20:34:00 -0500 Organization: Jacob Sparre Andersen Message-ID: References: <1jn1a4o.1dfllwo1uin3imN%csampson@inetworld.net> <1jn36d6.se2f0g1edjjnyN%csampson@inetworld.net> <61f149b9-00ff-40cd-9698-01e69fdc5c0f@v15g2000yqe.googlegroups.com> <12ce49e6-169e-4e35-b82f-27de0d9b1ceb@t20g2000yqa.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1281749643 14830 69.95.181.76 (14 Aug 2010 01:34:03 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sat, 14 Aug 2010 01:34:03 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-RFC2646: Format=Flowed; Original Path: g2news1.google.com!news4.google.com!proxad.net!feeder1-2.proxad.net!feed.ac-versailles.fr!news.ecp.fr!news.jacob-sparre.dk!pnx.dk!not-for-mail Xref: g2news1.google.com comp.lang.ada:13262 Date: 2010-08-13T20:34:00-05:00 List-Id: "Robert A Duff" wrote in message news:wcchbiytg9e.fsf@shell01.TheWorld.com... > Elias Salom�o Helou Neto writes: ... >>> Anyway, someone prematurely implied that I may be doing premature >>> optimization. The fact is that I do know, from profiling, how >>> important is _not_ to range check in my specific application, so I >>> will try to give you a "bottom line" of what have been said that >>> really matters to me. >>> >>> 1) You can, in more than one way, tell the compiler to suppress most >>> (any?) checks, but people do not advise to do so. Even if I say that I >>> do need that :( > > Even if it's true that it is "important _not_ to range check", > that does not necessarily mean that you need to suppress checks. > As Dmitry pointed out, many checks will be removed by the > compiler even if you don't suppress them -- it will remove the > ones it can prove will not fail. The only way to determine > whether that's good enough is to measure it, and/or look > at the machine code. > > As for the advice you mention, if it said "Never suppress checks", > it's bad advice. I think it was my comment that he was responding to. Bob has captured my intent perfectly; you probably won't need to Suppress range checks, because the compiler probably already will have removed them. But if you do need to, you can. >> ask for the suppression, but it does NOT mandate the compiler to >> actually >> skip such checks. ... > > Of course! That's true of all higher-level languages, including C. > Higher-level language never formally define what machine code gets > generated, nor how efficient it has to be -- there's no way to do so. > A C compiler is allowed by the C standard to do array bounds checking, > and I assure you that if such a C compiler exists, the checks are > FAR more expensive than for Ada. > > The Ada RM has some informal rules, called "Implementation Advice" > and "Implementation Requirements", and there's one in there > somewhere saying compilers really ought to skip the checks > when it makes sense. > > Don't worry, Ada compiler writers do not deliberately try > to harm their customers -- of course they actually skip the > checks when it makes sense. Note that it doesn't always make > sense, since some checks are done for free by the hardware. Again, I agree with Bob. All Ada compilers that I know of do suppress checks when the permission is given. But it is also the case that some checks might be made automatically by the underlying machine or in the runtime, and they might be very difficult or impossible to remove. For example, the integer divide instruction on the X86 traps if an attempt to divide by zero occurs. Suppressing this check would be rather expensive, as the compiler would have to provide some sort of map to the trap handler as to whether or not the check was suppressed at the point of the divide. Plus you would have to be able to restart after the divide (not all OSes provide this capability for trap handlers). So it is impractical on an X86 machine to suppress the zero divide check. A similar example occurs when suppressing storage checks on allocators. The allocator is going to be implemented by some sort of library routine, and it is that routine that makes the check. One could imagine passing a flag whether or not you want the check suppressed, but that would slow down all allocations -- so typically no way to eliminate the check is provided. OTOH, range checks take extra code on every processor that I've ever worked with, and compilers do everything that they can to avoid generating that extra code. So in practice, range checks are always suppressed when it is asked for. You have to keep in mind the difference between Ada as defined by the standard and particular Ada implementations. As Bob says, implementers don't make their compilers generate bad code if they don't have a good reason. But the standard (like all standards) give the implementers some flexibility to generate the best code for a given target. So some questions (including *all* questions about performance) have to be answered in the context of particular implementations (and often, particular code). "Ada" (or "C" for that matter) doesn't have performance characteristics; Ada implementations like GNAT or Janus or ObjectAda do. One more point: when you suppress checks in Ada, all you are doing is telling the compiler that "I guarentee that these checks will not fail". If they do fail, the program is what Ada calls erroneous -- and the code is allowed to do anything at all (including, as the saying goes, "erasing the hard disk" -- although I'm not aware of that ever actually happening on a protected OS like Windows or Linux. More likely, it would cause some sort of buffer overflow bug). That includes raising the exception that the check including. Since the OP is mostly interested in performance, this doesn't matter -- but it might in a safety-critical application, so it has to be defined in the Standard. Randy.