Re: PAR (Was: Embedded languages based on early Ada)

["Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk>]

On Tue, 06 Mar 2007 02:01:33 +0000, Dr. Adrian Wrigley wrote:
<snip>

Thank you for your intelligent input on this.

Martin, Randy:

I chose "par" and "all" simply because that reflects Occam and the
previously suggested "for all" loop.

"parallel" would make a lot of sense:

parallel
   CookDinner;
   DoTaxReturn;
   BookHoliday;
end;

would allow execution in separate tasks, or sequential execution in
any order.

for I in Data'range parallel loop
   Transform (Data (I));
end loop;

would allow reordered or concurrent loop execution.

Ray:
> I would strongly discourage this practice. Getting sequential programs
> correct is hard enough. Parallel programs are vastly more difficult and
> subtle.

Sequential and parallel programs can easily exceed a programmer's
analyitical limits and comprehension.  Hardware designers are used to
thinking about concurrent operation.  Concurrency involving independent
operating units without communication is often straightfoward.
There is no communication to screw up - data are read in parallel and
combined serially.  This a very common and useful type.

In my opinion, "par" and "seq" were technically successful in Occam,
and many of the difficult and subtle problems are absent from the
above code because the concurrent units *cannot* address each other.
These parallel constructs are simpler and more restricted than Ada
tasks.  The point of "par" is that the restrictions eliminate concerns
over control flow.  The issue is checking for erroneous data flow
(eg accidental concurrent updates).  The compiler should warn when
this appears to be a hazard.

> It is only 2nd class because our brains our wired that way, at least in
> terms of how we know how to program.

But breaking down programs into sequential steps is a skill which
has to be learned.  So many other things have concurrency - mathematics,
physics, hardware.

> The point is to choose one way or the other, and to have the source be
> clear about that decision.

That is *almost* what I am saying.  Mark the obviously concurrent bits
as concurrent.  Mark the rest as sequential.  Assume the compiler will
choose true concurrenct execution sensibly.

tmoran:
> If programmers think of "par" as "I've carefully analyzed
> this algorithm and it may be run in parallel" that's good.  If they
> think of "par" as "I want you to run this in parallel", I think that
> would be a bad mindset.  Explicit Ada tasks are more like the latter.

precisely my point.  Writing code with "par" is a fairly simple
transition from sequential coding.  Once you've had a bit of practice,
writing robust parallel code is pretty easy, and most blocks are
clearly parallel or clearly not parallel.  You need to pay a bit more
attention to what is pure and what isn't. (much easier than tasks!)

Randy:
I'm a big fan of declaring functions as pure, and it is disappointing
to me that Ada still can't do this.  A function declared pure should
permit reordering of invocation and memoization etc.  It doesn't have
to be pure, technically (I support the "user beware" version), but
compilers should warn of impure behaviour - perhaps a pragma to
reject impurity would help.  Things like invocation counts or
debugging statements usually break the purity of a function.
I don't know how procedures should be addressed.

The meta-compiler approach is interesting, and rather like what I
suggested earlier about a new language, permiting fine-grain
concurrency, suitable for hardware and software, similar to
a rebranded/renamed Ada.

The problem with an Ada intermediate is that you can't easily translate
programs with "par" into a language without.  There is no
realistic work-around or simulation of the execution behaviour of par. 
Par says "create a thread if it looks appropriate at this moment".
The expectation is that this generates the appropriate concurrent
call instruction.  Maybe some major compiler hacking and special
directives could patch something together, like Cilk does for C.

One aspect of this discussion is the inaccessability of fine-grain
concurrency to either a harware developer or a software developer.
As a processor designer, I can see how to implement concurrent
calls and concurrent memory access - but doing this does not help
run any existing code.  As a programmer, I can see where my code
is logically concurrent, but the language denies me this expressiveness,
and my processor doesn't support it.  Some leadership is needed!

Thanks.
--
Adrian