Re: Efficiency of code generated by Ada compilers

[anon@att.net]

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

In <i44rqb$efe$1@munin.nbi.dk>, "Randy Brukardt" <randy@rrsoftware.com> writes:
>"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.
>


If a program uses the pragma Suppress or Restrictions, it just means that 
the author is required to insert data verification where the program needs 
it.

And in the case of integer math most CPUs do provide error checking that 
most OS trap and in some cases allow the program to provide the error 
handling.  Like in the case of divide-by-zero, which most CPU trap and 
allow most OS like Linux or windows to handle.  And these OS provides 
links for the program to bypass the OS default action.  Sometime it is 
easier to allow a secondard task to handler the hardware check than to 
insert checks with in the ptogram code.

Because why should a program verity and reverify a object such as a number 
each time that object is passed into a routine or a package.  The Suppress 
check can be used to reduce the code size as well as speeding up the 
executions.

And in the case of integer math the cpu does provide error check that 
most OS trap and in some cases allow the program to provide error 
handling.  Like in the case of divide-by-zero, which most CPU trap and 
allow most OS like Linux or windows to handle.  And these OS provides 
links for the program to bypass the OS default action.

Also, no program or OS can provide all check for any system or program. 
An example is in the rare case where a CPU or memory is in error how do 
you check that the system CPU or code memory while the program is running. 
So, any and all programs can and with time will result in erroneous 
executions as the hardware fails which is not predictable. Ada RM allows 
for this in RM 1.1.5 (9, 10).  So, any and all programs can become 
erroneous.