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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: GNAT and Tasklets Date: Sat, 20 Dec 2014 10:03:12 +0100 Organization: cbb software GmbH Message-ID: 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> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: DnbLlTjuGCQpsiNtwqNvSg.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:24172 Date: 2014-12-20T10:03:12+01:00 List-Id: On Fri, 19 Dec 2014 19:39:22 -0500, Peter Chapin wrote: > Tasks are > good for large, relatively independent chunks of logic that need to > execute concurrently such as different control loops in an embedded > system. Not only embedded, it is any system dealing with asynchronous events, like when doing I/O. > However, when writing parallel code that will execute over highly > regular data structures such as large matrices, explicit tasks are just a > distraction. In such applications the existence of tasks is an > implementation detail, not a design element. Yes. The question is whether the programming paradigm built around a chain of imperative instructions is good for such code altogether. I am not arguing for graphical or functional languages. But I think that, possibly, we should look after decomposition in terms of special objects instead, like we did with protected objects in Ada 95. > Trying to use explicit tasks for parallel programming is a kind of > abstraction inversion: using a high level construct to implement some low > level functionality. Sure it is possible but the result is ugly and > inefficient. It is communication which makes that complex. The body of a tasklet or of a parallel loop etc is usually not the problem. Which is why I think that having it in an imperative manner does not solve it. I see it as a lots of very small chains of instructions (bodies) which need to be connected in some kind of mesh. The bodies themselves are of little interest in this kind of problem. The connections is what should be addressed. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de