Re: Ada and OpenMP

[Brad Moore <brad.moore@shaw.ca>]

On 08/03/2013 4:36 PM, Randy Brukardt wrote:
> "Shark8" <onewingedshark@gmail.com> wrote in message
> news:9e0bbbdf-ccfa-4d4c-90af-2d56d46242b3@googlegroups.com...
>> On Thursday, March 7, 2013 8:42:15 PM UTC-7, Randy Brukardt wrote:
>>>
>>> In order for that to be the case, the pragma would have to make various
>>> constructs illegal in the loop and in the surrounding code (exception
>>> handlers, any code where one iteration of the loop depends on the next,
>>> erroneous use of shared variables). But a pragma shouldn't be changing
>>> the
>>> legality rules of the language. (And it's not clear this would really fix
>>> the problem.)
>>
>> Why would that have to change the semantics of the program: since there
>> would have
>> to be a non-implementation-defined code-generation method (for when the
>> pragma
>> was off) the compiler should just use that if those constructs are used.
>
> Mainly because 95% of Ada code is going to fail such tests; it would
> virtually never be able to use the fancy code.
>
> Take the OP's example, for example:
>
> for I in 1 .. MAX loop
>     A(I) := A(I) + 1; -- Can raise Constraint_Error because of overflow or
> range checks.
> end loop;
>
> This can be done in parallel only if (A) there is no exception handler for
> Constraint_Error or others anywhere in the program; or

I am working towards a new version of Paraffin to be released soon that 
handles exceptions in such loops (as well as a number of other features).

The technique though, is to have the workers catch any exception that 
might have been raised in the users code, and then call 
Ada.Exceptions.Save_Occurence to save the exception to be raised later.

Once all workers have completed their work before returning to let the 
sequential code continue on, a check is made to see if any occurrences 
were saved. If so, then Ada.Exceptions.Reraise_Occurrence is called, to
get the exception to appear in the same task that invoked the parallelism.

Testing so far indicates this seems to work well, maintaining the 
exception abstraction as though the code were being executed 
sequentially. Currently only the most recent exception is saved, so if
more than one exception is raised by the parallel workers, only one will
get fed back to the calling task, but I think thats OK, as that would 
have been the behaviour for the sequential case. Such an exception also 
sets a flag indicating the work is complete, which attempts to get other 
workers to abort their work as soon as possible. Also, under GNAT at 
least, this exception handling logic doesn't appear to impact 
performance. Apparently they use zero cost exception handling which 
might be why. I'm not sure what sort of impact that might have on other 
implementations that model exceptions differently. Hopefully, it 
wouldn't be a significant impact.

Brad

(B) pragma Suppress
> applies to the loop (nasty, we never, ever want an incentive to use
> Suppress); or (C) no exception handler or code following the handler can
> ever access A (generally only possible if A is a local variable, not a
> parameter or global). For some loops there would be a (D) be able to prove
> from subtypes and constraints that no exception can happen -- but that is
> never possible for increment or decrement operations like the above. These
> conditions aren't going to happen that often, and unless a compiler has
> access to the source code for the entire program, (A) isn't possible to
> determine anyway.
>
> And if the compiler is going to go through all of that anyway, it might as
> well just do it whenever it can, no pragma is necessary or useful.
>
> The whole advantage of having a "marker" here is to allow a change in the
> semantics in the error case. If you're not going to do that, you're hardly
> ever going to be able to parallelize, so what's the point of a pragma?
>
>                                         Randy.
>
>
>
>