comp.lang.ada
 help / color / mirror / Atom feed
From: "Randy Brukardt" <randy@rrsoftware.com>
Subject: Re: Efficiency of code generated by Ada compilers
Date: Fri, 13 Aug 2010 20:34:00 -0500
Date: 2010-08-13T20:34:00-05:00	[thread overview]
Message-ID: <i44rqb$efe$1@munin.nbi.dk> (raw)
In-Reply-To: wcchbiytg9e.fsf@shell01.TheWorld.com

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 5123 bytes --]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message 
news:wcchbiytg9e.fsf@shell01.TheWorld.com...
> Elias Salom�o Helou Neto <eshneto@gmail.com> 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.








  reply	other threads:[~2010-08-14  1:34 UTC|newest]

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-06 20:21 Efficiency of code generated by Ada compilers Elias Salomão Helou Neto
2010-08-06 20:24 ` (see below)
2010-08-06 23:14 ` Shark8
2010-08-07  7:53 ` Dmitry A. Kazakov
2010-08-10 13:52   ` Elias Salomão Helou Neto
2010-08-10 14:24     ` Shark8
2010-08-10 14:28     ` Shark8
2010-08-10 15:01     ` Robert A Duff
2010-08-10 15:14       ` Yannick Duchêne (Hibou57)
2010-08-10 18:32         ` Robert A Duff
2010-08-10 15:10     ` Georg Bauhaus
2010-08-10 15:32     ` Dmitry A. Kazakov
2010-08-10 22:26     ` Randy Brukardt
2010-08-20  7:22       ` Yannick Duchêne (Hibou57)
2010-08-08 14:03 ` Gene
2010-08-08 15:49   ` Robert A Duff
2010-08-08 17:13     ` Charles H. Sampson
2010-08-08 18:11       ` Dmitry A. Kazakov
2010-08-08 20:51       ` Robert A Duff
2010-08-08 22:10         ` (see below)
2010-08-08 22:22           ` Robert A Duff
2010-08-09  4:46         ` Yannick Duchêne (Hibou57)
2010-08-09  5:52         ` J-P. Rosen
2010-08-09 13:28           ` Robert A Duff
2010-08-09 18:42             ` Jeffrey Carter
2010-08-09 19:05               ` Robert A Duff
2010-08-10 10:00                 ` Jacob Sparre Andersen
2010-08-10 12:39                   ` Robert A Duff
2010-08-09 19:33             ` Yannick Duchêne (Hibou57)
2010-08-09 21:42               ` Robert A Duff
2010-08-10 12:26         ` Phil Clayton
2010-08-10 12:57           ` Yannick Duchêne (Hibou57)
2010-08-10 14:03             ` Elias Salomão Helou Neto
2010-08-10 14:27               ` Yannick Duchêne (Hibou57)
2010-08-10 22:50                 ` anon
2010-08-10 23:28                   ` Yannick Duchêne (Hibou57)
2010-08-10 23:38                     ` Yannick Duchêne (Hibou57)
2010-08-11  7:06                       ` Niklas Holsti
2010-08-11 11:58                         ` anon
2010-08-11 12:37                           ` Georg Bauhaus
2010-08-11 13:13                         ` Robert A Duff
2010-08-11 23:49                           ` Randy Brukardt
2010-08-10 14:31               ` Shark8
2010-08-11  7:14               ` Charles H. Sampson
2010-08-11  6:42         ` Charles H. Sampson
2010-08-08 22:35     ` tmoran
2010-08-09 13:53       ` Robert A Duff
2010-08-09 17:59         ` tmoran
2010-08-09 19:36           ` Yannick Duchêne (Hibou57)
2010-08-09 21:38             ` Robert A Duff
2010-08-11  7:42       ` Charles H. Sampson
2010-08-11 13:38         ` Robert A Duff
2010-08-12  7:48           ` Charles H. Sampson
2010-08-12  8:08             ` Ludovic Brenta
2010-08-12 17:10               ` Charles H. Sampson
2010-08-12 18:06                 ` Jeffrey Carter
2010-08-11 18:49         ` Simon Wright
2010-08-12  7:54           ` Charles H. Sampson
2010-08-12  8:36             ` Dmitry A. Kazakov
2010-08-12 11:04             ` Brian Drummond
2010-08-12 19:23             ` Simon Wright
2010-08-12 20:21               ` (see below)
2010-08-13 15:08                 ` Elias Salomão Helou Neto
2010-08-13 15:10                   ` Elias Salomão Helou Neto
2010-08-13 18:01                     ` Georg Bauhaus
2010-08-13 19:52                       ` Robert A Duff
2010-08-14  9:44                         ` Georg Bauhaus
2010-08-13 20:22                     ` Robert A Duff
2010-08-14  1:34                       ` Randy Brukardt [this message]
2010-08-14  7:18                         ` anon
2010-08-13 21:57                     ` Jeffrey Carter
2010-08-13 22:37                       ` Yannick Duchêne (Hibou57)
2010-08-13 22:43                         ` Yannick Duchêne (Hibou57)
2010-08-13 23:29                         ` tmoran
2010-08-14  0:02                           ` Yannick Duchêne (Hibou57)
2010-08-14  0:16                             ` (see below)
2010-08-14 10:47                             ` Brian Drummond
2010-08-14 13:58                               ` Yannick Duchêne (Hibou57)
2010-08-15  0:23                                 ` Brian Drummond
2010-08-14 14:51                               ` (see below)
2010-08-15  0:58                                 ` Brian Drummond
2010-08-15  1:58                                   ` (see below)
2010-08-15 10:31                                     ` Brian Drummond
2010-08-13 15:37                   ` Dmitry A. Kazakov
2010-08-16 13:29                     ` Elias Salomão Helou Neto
2010-08-16 14:09                       ` Dmitry A. Kazakov
2010-08-18 14:00                         ` Elias Salomão Helou Neto
2010-08-18 16:38                           ` Dmitry A. Kazakov
2010-08-19 18:52                             ` Elias Salomão Helou Neto
2010-08-19 19:48                               ` Dmitry A. Kazakov
2010-08-13 16:58                   ` (see below)
2010-08-14 16:13                   ` Charles H. Sampson
2010-08-16 13:45                     ` Elias Salomão Helou Neto
2010-08-15 12:32 ` Florian Weimer
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox