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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.42.20.3 with SMTP id e3mr6603616icb.11.1418994087447; Fri, 19 Dec 2014 05:01:27 -0800 (PST) X-Received: by 10.140.87.68 with SMTP id q62mr35380qgd.8.1418994087416; Fri, 19 Dec 2014 05:01:27 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!h15no14204018igd.0!news-out.google.com!r1ni70qat.1!nntp.google.com!i13no637676qae.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Fri, 19 Dec 2014 05:01:27 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=87.91.37.131; posting-account=hya6vwoAAADTA0O27Aq3u6Su3lQKpSMz NNTP-Posting-Host: 87.91.37.131 References: <455d0987-734a-4505-bb39-37bfd1a2cc6b@googlegroups.com> <8277a521-7317-4839-b0b6-97f8155be1a4@googlegroups.com> <9e1d2b9f-1b97-4679-8eec-5ba75f3c357c@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <2d4fc21f-5739-4100-9551-959b6822c761@googlegroups.com> Subject: =?ISO-8859-1?Q?Re=3A_GNAT=EF=BF=BDand_Tasklets?= From: vincent.diemunsch@gmail.com Injection-Date: Fri, 19 Dec 2014 13:01:27 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:24147 Date: 2014-12-19T05:01:27-08:00 List-Id: Hello Randy, Thank you for your response. I find it a little bit confusing in fact. > There is no such thing as a "lightweight Ada task". The syntax is heavy, = the=20 > semantics is heavy (separate stack, exception handling, finalization,=20 > termination), and as a correlary, the implementation is heavy. Have you heard of Ravenscar ? The idea is to restrict tasking to a simple s= ubset that is both predictable, therefore easy to set up right, and light to impl= ement. I am pretty sure, that local tasks could be restricted a lot and yet be ver= y useful. And tasks with very limited synchronization, without rendez-vous, are easy = to manage. > >Finaly, I really hope that the new version of the langage will keep Ada= =20 > >simple ... > That ship sailed with Ada 95, if it ever was true at all. So what ? We will continue to make it more and more complex ? Isn't it poss= ible to stop that trend and try to do better ? =20 > Besides, you confuse the appearance of simple (that is simple to use, sim= ple=20 > to learn) with simple in language terms. When I say "simple", I simply means "simple in langage terms". For me a com= piler is a tool that allows us to generate machine code, without the difficulty o= f using assembly langage. That's why it brings simplicity. And I know well that a c= ompiler is complex : parsing, AST=A0expansion, type evaluation, code generation, al= l this=20 requires a lot of theatrical work. I only have the feeling that compilers a= re still lacking theoretical grounding upon tasking, and therefore are not able to d= eal with it in a useful way. > Similarly, > for I in parallel 1 .. 10 loop > ... > end loop; >=20 > looks and feels simple, even though what would have to happen under the= =20 > covers to implement that is anything but simple. We agree on that point :-). > You are still thinking way too low-level. Creating a parallel program sho= uld=20 > be as easy as creating a sequential one. There should (almost) be no spec= ial=20 > constructs at all. Ideally, most programs would be made up of parallel lo= ops=20 > and blocks, and there would be hardly any tasks (mainly to be used for=20 > separate conceptual things). That's funny ! Really are you serious ? Ada have created the task abstracti= on to deal with parallelism, and for me it is an abstraction, that can be impl= emented by different ways, depending on the compiler, the OS but also the way it is= used=20 inside the program. First you are telling me that it is too difficult for a= compiler to implement this abstraction in an other way than a heavy OS thread, because = it=20 would be to complex to automatically find simple cases allowing reduce task= ing, and because a runtime library using mixed tasking would be to difficult to = write. And strongly disagree to both arguments :=20 1. the Ravenscar profile is a counter example, and using aspects or pragma = should=20 allow us to make useful restrictions on local tasks 2. the Paraffin library shows clearly that we can have mixed tasking, for i= t can be used in parallel to tasks.=20 And after, that you pretend seriously that a compiler should be able to fin= d by its=20 own parallelism in the program ! It seems to me a major contradiction ! No, creating a parallel program is far more complex than creating a sequent= ial one, and until we have a compiler so smart to do this, I prefer to rely on explicit tasking. =20 > Writing a task correctly is a nearly impossible job, especially as it isn= 't=20 > possible to statically eliminate deadlocks and race conditions. It's not= =20 > something for the "normal" programmer to do. We surely don't want to put= =20 > Ada's future in that box -- it would eventually have no future (especiall= y=20 > if very-many-core machines become as common as some predict). See Linear Temporal Logic and Model Checking based on that logic. It is the foundation of concurrency. But to make parallel computation, we really don't need such complexity. > In any case, there won't be any major upgrade of the Ada language for at= =20 > least another 5 years. The upcoming Corrigendum (bug fix) has few new=20 > features and those are all tied to specific bugs in the Ada 2012. So I=20 > wouldn't wait for language changes to bail you out; Brad's libraries are = the=20 > best option for now. Fine. > Also please note that language enhancements occur through a process of=20 > consensus. Most of the ARG has to agree on a direction before it gets int= o=20 > the language standard. That is why I am taking time to discuss on this forum. > You should have noted by now that pretty much everyone who has answered= =20 > here has disagreed with your position.=20 No I haven't noticed. I had the feeling that at least Dimitry and Brad had = were sensible to some of my points. But even if it was the case, that doesn't me= an that=20 I went wrong :-) Montesquieu said "The less you think, the more people agre= e with you" :-). Kind regards, Vincent