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!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!fx09.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: =?windows-1252?Q?GNAT=A0and_Tasklets?= References: <8277a521-7317-4839-b0b6-97f8155be1a4@googlegroups.com> <9e1d2b9f-1b97-4679-8eec-5ba75f3c357c@googlegroups.com> <478c81f9-5233-4ae1-a3eb-e67c4dbd0da1@googlegroups.com> In-Reply-To: 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: 1419007372 68.145.219.148 (Fri, 19 Dec 2014 16:42:52 UTC) NNTP-Posting-Date: Fri, 19 Dec 2014 16:42:52 UTC Date: Fri, 19 Dec 2014 09:42:52 -0700 X-Received-Bytes: 5430 X-Received-Body-CRC: 3289535154 Xref: news.eternal-september.org comp.lang.ada:24151 Date: 2014-12-19T09:42:52-07:00 List-Id: On 14-12-19 04:01 AM, Dmitry A. Kazakov wrote: > On Fri, 19 Dec 2014 10:40:03 +0000 (UTC), Georg Bauhaus wrote: > >> wrote: >> >>> It would be interesting to do a little survey on existing code using tasking. >>> I have the impression that only tasks at Library level do rendez-vous and >>> protected object synchronisation, and local tasks, most of the time, are >>> limited to a rendez-vous with their parent task at the beginning or at >>> the end. So maybe we should put restrictions on local tasks, so that we >>> can map them to jobs. >> >> Won't the parallel loop feature be providing >> for this kind of mini job: > > Parallel loop is useless for practical purposes. It wonders me why people > wasting time with this. For multicore, the idea is to make better use of the cores when doing so will improve performance. To the best of my knowledge all frameworks and language enhancements in other languages all have some concept of a parallel loop. (eg. OpenMP, Cilk, TBB) Just because a loop can be parallelized doesn't mean it should be, the gains of the parallelism need to be greater than the overhead introduced to inject the parallelism. For example, a loop to do image processing such as darkening the color of all pixels in a large image might benefit from parallelism. Also, the number of iterations does not need to be large to see parallelism benefits. for I in parallel 1 .. 10 loop Lengthy_Processing_Of_Image (I); end loop; > > They could start with logical operations instead: > > X and Y > > is already parallel by default. AFAIK nothing in RM forbids concurrent > evaluation of X and Y if they are independent. Same with Ada arithmetic. > E.g. > > A + B + C + D > > So far no compiler evaluates arguments concurrently or vectorizes > sub-expressions like: > > A > B + > C + > D + > > Because if they did the result would work slower than sequential code. It > simply does not worth the efforts with existing machine architectures. > The compiler should be able to make the decision to parallelize these if there is any benefit to doing so. Likely the decision would be to *not* parallelize these, if A, B, C, and D are objects of some elementary type.. But it depends on the datatype of A, B, C, and D. Also A, B, C, and D might be function calls, not simple data references, and these calls might involve lengthy processing, in which case, adding parallelism might make sense. Or, if these are objects of a Big Number library with infinite precision, you might have an irrational number with pages of digits each for numerator and denominator. Performing math on such values might very well benefit from parallelism. We looked at being able to explicitly state parallelism for subprograms, (parallel subprograms), but found that syntax was messy, and there were too many other problems. We are currently thinking a parallel block syntax better provides this capability, if the programmer wants to explicitly indicate where parallelism is desired. eg. Left, Right, Total : Integer := 0; parallel Left := A + B; and Right := C + D; end parallel; Total := Left + Right; or possibly allow some automatic reduction Total : Integer with Reduce := 0; parallel Total := A + B; and Total := C + D; end parallel; Here, two "tasklets" would get created that can execute in parallel, each with their local instance of the Total result (i.e. thread local storage), and at the end of the parallel block, the two results are reduced into one and assigned to the actual Total. The reduction operation and identity value used to initialize the local instances of the Total could be defaulted by the compiler for simple data types, but could be explicitly stated if desired. eg. Total : Integer with Reduce => (Reducer => "+", Identity => 0) := 0; parallel Total := A + B; and Total := C + D; end parallel; Brad