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

[tmoran@acm.org]

> If you can persuade programmers to use "par" unless they explicitly
> *need* sequential execution, a great many statements will be marked
> as concurrent.  Numeric codes will use "par" in the computational
> core, as well as outer layers of execution.
   When "virtual memory" was new some programmers thought about their
program's access patterns and found that VM was a great simplification.
Other programmers simply said "oh, good, I can write my program to
randomly access many megabytes, though the physical memory is only
a few hundred kilobytes."  Those programs were a disaster.   Nowadays,
of course, very few people write programs that don't in fact fit inside
physical memory.  I suspect we'll see a similar thing with multi-core:
some will carefully consider what they are doing and it will be good;
others will just say "oh, good, I can multiply an m x n and an n x p
matrix using m x p threads", and it will be bad.  Meanwhile the
hardware will develop to automatically do more and more hidden
concurrency.  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.
My $.02