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: 
 border2.nntp.dca1.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!news-2.dfn.de!news.dfn.de!news.uni-stuttgart.de!news.enyo.de!.POSTED!not-for-mail
From: Florian Weimer <fw@deneb.enyo.de>
Newsgroups: comp.lang.ada
Subject: Re: C versus Ada (once again :-)), was: Re: F-22 ADA Programming
Date: Tue, 04 Nov 2014 14:42:50 +0100
Message-ID: <87wq7b3wv9.fsf@mid.deneb.enyo.de>
References: <a510f410-56ea-46a6-9f3c-021a2389b936@googlegroups.com>
 <m2jvqm$qpc$2@dont-email.me>
 <dfa977d6-1458-4d8a-b226-15a759e321d6@googlegroups.com>
 <220f97ab-9aa2-4961-b140-2b271c3ab99a@googlegroups.com>
 <slrnm4ulto.nrc.lithiumcat@nat.rebma.instinctive.eu>
 <m2on9t$tv6$1@dont-email.me>
 <99759c3f-a35f-4745-a8fd-2fb6ab6fb1aa@googlegroups.com>
 <m2p0g5$4d0$1@dont-email.me>
 <48dc1630-8e7d-4e29-8bdd-53d74932d9d0@googlegroups.com>
 <m2pakq$99g$1@dont-email.me>
 <88a7f98c-55c2-4b5f-8a9d-c8b7512781c8@googlegroups.com>
 <m2ptm9$h8a$2@dont-email.me>
 <pgdzu6hi3mcu.kx0szqbevtow$.dlg@40tude.net>
 <m2r7k7$2m2$2@dont-email.me>
 <50cacb19-5d0b-4dbe-b91b-0b3b462913d6@googlegroups.com>
 <m2tnoi$j1q$4@speranza.aioe.org>
 <07d0ad94-160b-4873-ba1b-403e8c0bc420@googlegroups.com>
 <m2vlg9$onb$1@dont-email.me> <m31iit$74m$1@dont-email.me>
 <874mugsbhl.fsf@mid.deneb.enyo.de> <STS5w.353302$Hb3.343492@fx03.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Trace: news.enyo.de 1415108570 13986 192.168.18.20 (4 Nov 2014 13:42:50 GMT)
X-Complaints-To: news@enyo.de
Cancel-Lock: sha1:xFr4OLw3sqSCklbywqDK+0yYOM4=
Xref: number.nntp.giganews.com comp.lang.ada:190321
Date: 2014-11-04T14:42:50+01:00
List-Id: <comp.lang.ada>

* Shark8:

>> If you are trying to parallelize your programs for performance
>> reasons, Ada (as standardized) is not such a nice language anymore
>> because it lacks a modern memory model (which reflects the variations
>> of existing hardware) and access to various forms of atomic
>> instructions with well-defined properties.
>>
>
> Isn't the atomic instruction thing properly recognized as platform
> dependent?

The actual implementation is platform-dependent, but the C11 memory
model abstracts over it.  You use the <stdatomic.h> functionality
which you need to implement your parallel algorithm, and the C
implementation will select something matching for the target
architecture (either an exact match, or a stronger (and slower)
variant).

> If that's the case, then should it be part of Ada, or would
> it be acceptable to have a machine-language (e.g. System.Machine_Code)
> insert for handling it in the implementation part of some package?

It's difficult to get that right because it needs a lot of knowledge
of the target architecture and its variations.  If you stick to the
C11 memory model (or C++11 variant, they are supposed to be
compatible), you only need to learn that, and the C implementation
will map it to the hardware.

> (Would such atomic instructions need to be incorporated at the
> Run-time level?)

Some systems need kernel calls for certain barriers, yes.  But Ada
code needs to issue these barriers today, so support already has to be
present.

The main challenge is to expose weaker (and therefore more efficient)
synchronization primitives.