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: =?iso-8859-1?Q?GNAT=A0and?= Tasklets Date: Fri, 19 Dec 2014 21:56:39 +0100 Organization: cbb software GmbH Message-ID: References: <1r2ziulc78imb$.ad6zx5upic6s$.dlg@40tude.net> 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:24162 Date: 2014-12-19T21:56:39+01:00 List-Id: On Fri, 19 Dec 2014 20:45:49 +0000 (UTC), Georg Bauhaus wrote: > "Dmitry A. Kazakov" wrote: >> On Fri, 19 Dec 2014 09:42:52 -0700, Brad . In image processing when doing it by >> segments, you need to sew the segments along their borders, practically in >> all algorithms. That makes parallelization far more complicated to be >> handled by such a blunt thing as parallel loop. > > Conclusions drawn from one example > are fallacious here, Exactly. Doing something on image pixels independently is such a fallacious example. > as I am sure you > know well. Take some other algorthm like > Inverting all pixels, or anything written > for parallel APL, or R. Anything whose > parts need not be run on a full machine > with I/O layers and active control. Parallel loop is useless for symmetric and vectorized processing. >> It won't, because a big number library will use the heap or a shared part >> of the stack which will require interlocking and thus will either be marked >> as "impure", so that the compiler will not try to parallelize, or else will >> make the compiler to use locks, which will effectively kill parallelism. > > All the aliasing analysis explored at > SofCheck/AdaCore and considerations > regarding purity and experience gained > when developing the Spark language > based on Ada should be a good basis for > describing aspects of subprograms > that are candidates for parallel execution? How that changes anything? You either access heap from concurrent threads or not. If you do you have to lock. Copying portions of heap into local memory and running transactions on the heap is a non-starter. That is. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de