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!.POSTED!not-for-mail
From: Paul Rubin <no.email@nospam.invalid>
Newsgroups: comp.lang.ada
Subject: Re: How to get Ada to ?cross the chasm??
Date: Fri, 11 May 2018 12:50:49 -0700
Organization: A noiseless patient Spider
Message-ID: <87k1sat1ie.fsf@nightsong.com>
References: <1c73f159-eae4-4ae7-a348-03964b007197@googlegroups.com>
	<pc8l7e$km5$1@franka.jacob-sparre.dk> <87in88m43h.fsf@nightsong.com>
	<cd866ee8-ad4d-489e-a38b-d8e5f5d4af00@googlegroups.com>
	<87efiuope8.fsf@nightsong.com> <pcdagp$7pn$1@franka.jacob-sparre.dk>
	<87lgd1heva.fsf@nightsong.com> <pcg54t$gul$1@franka.jacob-sparre.dk>
	<87zi1gz3kl.fsf@nightsong.com> <pciqcd$ou1$1@franka.jacob-sparre.dk>
	<878t8x7k1j.fsf@nightsong.com> <fl7t0uF410rU1@mid.individual.net>
	<87fu342q1o.fsf@nightsong.com> <fleiqiFjhprU1@mid.individual.net>
	<87mux9645j.fsf@nightsong.com> <fljn0oFnugqU1@mid.individual.net>
	<8736yz18e4.fsf@nightsong.com>
	<e47585a0-8bb0-46c2-82be-140b189643e8@googlegroups.com>
	<pd4gmg$koe$1@dont-email.me> <87mux62it0.fsf@nightsong.com>
	<flm7hdFainiU1@mid.individual.net>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org;
 posting-host="4776ca6b408eab45c2cc0c9a5f8c8c74";
	logging-data="3256"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX19CUCtlzeUUN37kRKDqXK1j"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)
Cancel-Lock: sha1:hRj96DKys59wIEMkcdAI1k3aVJ8=
	sha1:ogv0DxNM1xMiqanM2v/SnwfE+Lk=
Xref: reader02.eternal-september.org comp.lang.ada:52284
Date: 2018-05-11T12:50:49-07:00
List-Id: <comp.lang.ada>

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> 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.

Sure, that's the point.  That explains the 1.3x slowdown and also
explains why it is worth it.

> 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,

Yes, but constructions that express the same programmer intent are not
semantically the same between the two languages.  Particularly a[i] is a
checked reference in Ada and unchecked in C, and similarly a+b is (or
should be) a checked integer addition in Ada, but it's UB in C in the
case of overflow.  

> 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 :-))

Heh, understandable about C, but can I interest you in Haskell for some
new projects ;-)?

> 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

If you mean the index is in an int range type, then the Ada compiler
should have to make a range check every time you modify the index,
unless it can statically prove that the new value is in range.  So
you've just moved the check from one place to another.

> Another Ada win could come from access types with null exclusion.

True.

> The CodePeer analysis tool from AdaCore is a compromise. It can be
> used to prove that no run-time checks will fail

Oh that sounds interesting.  I didn't know about it.