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!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!peer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!fx28.iad.POSTED!not-for-mail From: Brad Moore User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: GNAT?and Tasklets References: <455d0987-734a-4505-bb39-37bfd1a2cc6b@googlegroups.com> <8277a521-7317-4839-b0b6-97f8155be1a4@googlegroups.com> <9e1d2b9f-1b97-4679-8eec-5ba75f3c357c@googlegroups.com> <2d4fc21f-5739-4100-9551-959b6822c761@googlegroups.com> In-Reply-To: <2d4fc21f-5739-4100-9551-959b6822c761@googlegroups.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 68.145.219.148 X-Complaints-To: internet.abuse@sjrb.ca X-Trace: 1419011186 68.145.219.148 (Fri, 19 Dec 2014 17:46:26 UTC) NNTP-Posting-Date: Fri, 19 Dec 2014 17:46:26 UTC Date: Fri, 19 Dec 2014 10:46:26 -0700 X-Received-Bytes: 9000 X-Received-Body-CRC: 1475492909 Xref: news.eternal-september.org comp.lang.ada:24155 Date: 2014-12-19T10:46:26-07:00 List-Id: On 14-12-19 06:01 AM, vincent.diemunsch@gmail.com wrote: > 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 >> semantics is heavy (separate stack, exception handling, finalization, >> termination), and as a correlary, the implementation is heavy. > > Have you heard of Ravenscar ? I presume this is tongue in cheek, or perhaps you were unaware that Randy is the editor for the RM standard work. I can assure you that Randy would be well familiar with Ravenscar. He would have had to type that word many times, let alone discuss it and understand it in great detail at ARG meetings. :-) The idea is to restrict tasking to a simple subset > that is both predictable, therefore easy to set up right, and light to implement. > I am pretty sure, that local tasks could be restricted a lot and yet be very useful. > And tasks with very limited synchronization, without rendez-vous, are easy to > manage. I think both Randy and I would say that while tasks in Ravenscar might involve a simpler run-time model than the general case, they can still be considered to be far too heavy to consider where each "tasklet" is given its own task. That's a key point. If the goal of this is speed, then ultimately you want to use the lightest weight possible construct available, so that the overhead of introducing parallelism is as small as possible. This means more things can be parallelized. Tasks have too many semantics that you cannot just eliminate with restrictions. It doesn't mean that an implementation cant use tasks (or OS threads) as a basis for implementing parallelism, because it certainly can work as evidenced in Paraffin, but we dont want to mandate in the standard that the underlying mechanism be tasks, if better alternatives exist. In Ravenscar, the simplicity helps the real-time analysis, but there still are a lot of semantics and overhead associated with tasks that are still present even in Ravenscar. Ravenscar and real-time is not about having faster tasks. Its about being able to statically guarantee that tasks will meet their deadlines. > >>> Finaly, I really hope that the new version of the langage will keep Ada >>> 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 possible > to stop that trend and try to do better ? Complexity is in the eye of the beholder. Adding parallelism support for example, makes the language more complex, but might make adding parallelism more simpler to the programmer who wants to do that sort of thing. To the compiler writer though, it likely involves more than a fair bit of work. > >> Besides, you confuse the appearance of simple (that is simple to use, simple >> to learn) with simple in language terms. > > When I say "simple", I simply means "simple in langage terms". For me a compiler > is a tool that allows us to generate machine code, without the difficulty of using > assembly langage. That's why it brings simplicity. And I know well that a compiler > is complex : parsing, AST expansion, type evaluation, code generation, all this > requires a lot of theatrical work. I only have the feeling that compilers are still > lacking theoretical grounding upon tasking, and therefore are not able to deal > with it in a useful way. > >> Similarly, >> for I in parallel 1 .. 10 loop >> ... >> end loop; >> >> looks and feels simple, even though what would have to happen under the >> 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 should >> be as easy as creating a sequential one. There should (almost) be no special >> constructs at all. Ideally, most programs would be made up of parallel loops >> and blocks, and there would be hardly any tasks (mainly to be used for >> separate conceptual things). > > That's funny ! Really are you serious ? Ada have created the task abstraction > to deal with parallelism, Tasks were designed to support concurrency, which is broader than parallelism. They are useful for coarse grained parallelism, but too low-level for fine grained parallelism, such as parallel loops, etc. and for me it is an abstraction, that can be implemented > by different ways, depending on the compiler, the OS but also the way it is used > inside the program. This certainly is true, but all the ways one implements tasks needs to support the semantics described in the RM. Randy will also agree because he has actually written an Ada compiler, and his implementation is quite different than say, the GNAT compiler. 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 > would be to complex to automatically find simple cases allowing reduce tasking, > and because a runtime library using mixed tasking would be to difficult to write. > And strongly disagree to both arguments : > 1. the Ravenscar profile is a counter example, and using aspects or pragma should > allow us to make useful restrictions on local tasks > 2. the Paraffin library shows clearly that we can have mixed tasking, for it can be > used in parallel to tasks. > And after, that you pretend seriously that a compiler should be able to find by its > own parallelism in the program ! It seems to me a major contradiction ! If the compiler has enough static knowledge of the program, for example that there are no data races or blocking operations, and it knows how much executable code is being parallelized, then the compiler likely is better than the human in deciding where and how parallelism should occur in many or most cases. Brad > > No, creating a parallel program is far more complex than creating a sequential > one, and until we have a compiler so smart to do this, I prefer to rely on > explicit tasking. > >> Writing a task correctly is a nearly impossible job, especially as it isn't >> possible to statically eliminate deadlocks and race conditions. It's not >> something for the "normal" programmer to do. We surely don't want to put >> Ada's future in that box -- it would eventually have no future (especially >> 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 >> least another 5 years. The upcoming Corrigendum (bug fix) has few new >> features and those are all tied to specific bugs in the Ada 2012. So I >> wouldn't wait for language changes to bail you out; Brad's libraries are the >> best option for now. > > Fine. > >> Also please note that language enhancements occur through a process of >> consensus. Most of the ARG has to agree on a direction before it gets into >> 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 >> here has disagreed with your position. > > 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 mean that > I went wrong :-) Montesquieu said "The less you think, the more people agree with you" :-). > > Kind regards, > > Vincent >