Re: GNAT and Tasklets

["Randy Brukardt" <randy@rrsoftware.com>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:yjrnhk0w8gjd.k6ht3uh7raiw.dlg@40tude.net...
> On Fri, 19 Dec 2014 10:40:03 +0000 (UTC), Georg Bauhaus wrote:
>
>> <vincent.diemunsch@gmail.com> 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.

Because it's about medium-grained parallelism rather than the impractical 
fine-grained parallelism or the heavy-weight of Ada tasks.

> 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.

Not really true in practice -- it's rare that a compiler can prove 
independence of anything but the simplest entities (which are too cheap to 
benefit from optimization). Common-subexpression elimination is hard and 
rarely does anything.

Additionally, 1.1.4(18) is taken to mean that "arbitrary order" means any 
possible sequential order, but NOT a parallel order. Thus parallel execution 
is only allowed in cases that (almost) never happen in practice (large, 
independent expressions).

One of the reasons for having parallel blocks and loops is to signal to the 
compiler and reader that parallel execution IS allowed, even though it might 
not be an allowed sequential order.

> 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.

I agree with you vis-a-vis fine-grained parallelism. The overhead would kill 
you.

But the reason for parallel loops and blocks is to make expensive subprogram 
calls (or other decent-sized chunks of code) in parallel without writing a 
massive amount of overhead. That is not allowed in Ada today because of 
issues with exception handling and rules like 1.1.4(18).

While
     for i in parallel 1 .. 1000 loop
         A := A + I;
     end loop;
would be madness to execute in parallel, the more realistic
     for I in parallel 1 .. 1000 loop
         A := A + Expensive_Function(I);
    end loop;
probably makes sense. It's the latter that we're interested in.

                                               Randy.