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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: How to get Ada to ?cross the chasm?? Date: Fri, 11 May 2018 21:59:56 +0300 Organization: Tidorum Ltd Message-ID: References: <1c73f159-eae4-4ae7-a348-03964b007197@googlegroups.com> <16406268-83df-4564-8855-9bd0fe9caac0@googlegroups.com> <87o9i2pkcr.fsf@nightsong.com> <87in88m43h.fsf@nightsong.com> <87efiuope8.fsf@nightsong.com> <87lgd1heva.fsf@nightsong.com> <87zi1gz3kl.fsf@nightsong.com> <878t8x7k1j.fsf@nightsong.com> <87fu342q1o.fsf@nightsong.com> <87mux9645j.fsf@nightsong.com> <8736yz18e4.fsf@nightsong.com> <87mux62it0.fsf@nightsong.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net 9+v8jG8bFc9LrE+LxYO+BAB2BVh5iecthPYEyDwwlKAYPsxIGq Cancel-Lock: sha1:AZ+gwY0SPrZRlQ279l86s3XPpKo= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: <87mux62it0.fsf@nightsong.com> Xref: reader02.eternal-september.org comp.lang.ada:52281 Date: 2018-05-11T21:59:56+03:00 List-Id: On 18-05-11 20:39 , Paul Rubin wrote: > "Jeffrey R. Carter" writes: >> Correct C is usually slower than correct Ada that does the same thing, >> because an Ada compiler can optimize away many checks that will be >> left in the C because it's too much effort to manually prove that they >> will never fail. > > Going by the Alioth shootout and by the Unzip-Ada program discussed here > recently, Ada = 1.3x slower sounds about right to me. I suspect that if one would look deeply into the C versions of such benchmark programs, one would find non-portability (= undefined behaviour), and that writing the C in a really portable and well-defined form might increase the execution time. But I have no proof. Robert Dewar used to say that when some Ada source code is _really_ semantically equivalent to some C source code, GNAT is expected to produce the same machine code for the Ada as GCC/C produces for the C, or at last not slower code. I don't much care about small speed differences; I find C programming so painful and disgusting that I would no longer willingly undertake any C project. (I am of pensionable age, so I can get out of the rat-race when I want to, and focus on my own Ada projects :-)) > I don't think the Ada compiler can prove that much safety by itself > (maybe a little bit involving aliases) that a C compiler can't. If one uses specific array index types, as good Ada style requires, an Ada compiler can trivially omit many array bounds checks for which a bounds-checking C compiler would have to use a global data-flow and variable-value analysis to prove that the check could be omitted. Another Ada win could come from access types with null exclusion. > SPARK is a different story, but that > ramps up the development effort to a new level. The CodePeer analysis tool from AdaCore is a compromise. It can be used to prove that no run-time checks will fail, but it is not as constraining as SPARK, I believe. On the other hand, it may require more manual assistance in the form of contracts added to the Ada source. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ .