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

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

On Wed, 07 Mar 2007 21:18:51 +0100, Pascal Obry wrote:

> I don't see the point of PAR which create dynamically threads all the
> time. A waste of time! The T tasks above can be reused during all the
> application lifetime if necessary.

???

PAR says "these statements can be done in any order, or concurrently".
It does not require threads to be created - that's entirely outside
the scope of the language.

One implementation might run the code sequentially on a CPU.
The compiler might spot code rearrangement, or common subexpressions
not guaranteed in sequential code.

Another implementation might convert simple statements into
combinatorial netlists for dynamic instantiation in an FPGA.
Complex statements would be handled another way

Another might run code sequentially if the number of instructions
were below a threshold.  Above that threshold, the statements are
run sequentially if the average execution time is below a threshold
or there are currently fewed threads than processors.

Yet another might assign a thread statically to each concurrent statement
and build a software pipeline of processes to move data.  This way,
thread creation and destruction is eliminated, and data locality
may be improved.

There are other distinct alternatives.

It's not the language construct that would waste the time, but the
inappropriate implementation.

Dmitry wrote:
> If so, then what would be the contribution of PAR? One important
> proposition is that there is no any use in PAR running absolutely
> independent code. So the question arise, what *exactly* PAR does with:

The contribution is the very lightweight syntax and semantics.
One extra keyword, to permit a wide choice of implementations,
parallel, serial, hardware, pipeline, threaded etc. 

PAR is ideal for the common case of running absolutely independent code!
--
Adrian