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!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: GNAT and Tasklets Date: Wed, 17 Dec 2014 16:18:41 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <455d0987-734a-4505-bb39-37bfd1a2cc6b@googlegroups.com> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1418854722 6240 24.196.82.226 (17 Dec 2014 22:18:42 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Wed, 17 Dec 2014 22:18:42 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: news.eternal-september.org comp.lang.ada:24079 Date: 2014-12-17T16:18:41-06:00 List-Id: wrote in message news:f9828477-a98e-4795-803d-5926aa7a1fdb@googlegroups.com... ... >I am rather surprised that you made a distinction between creating tasks >and parallelism. I agree that the goal of parallelism is to increase CPU >usage and therefore make the program run faster. For me creating tasks is >the Ada way of implementing parallelism. And it is a sound way of doing it >since compilers, as far as I know, are not really able to find automaticaly >parallelism in a program. Moreover using things like state machines to >create parallelism is to complex for a programmer and needs the use of a >dedicated langage. So tasks are fine. No, tasks are *not* fine. They are far too heavy-weight for the average programmer (or even the one that wants to accomplish something fast). And it is far too easy to introduce race conditions or deadlocks into them. On top of which (as Brad notes), the optimal parallelism structure depends on the actual OS/hardware that you run on. You surely don't want to have to encode that into your program and redo it everytime you find out about a better way to work on a particular target. For a lot of uses, what you want is a parallel block or loop that eliminates the implicit sequential behavior. In that case, the compiler can execute the code in parallel or sequentially depending on the actual execution environment. But to make that easy *and* safe, there have to be restrictions on what you can put into such constructs. That's what the group of four are looking at (and I would, if I could spare the time). Tasks are good for separating relatively large and loosely related jobs. They work great for dealing with web server requests, for instance, because the requests don't need to talk to each other and just need to do whatever they do. They're not a very good way to split up a single calculation, because the granularity is almost certainly going to be too coarse (not enough parallelism) or too fine (too much overhead), and they're too inflexible to be able to change that on the fly. Randy.