Re: Occam-Tau anyone???

["P.H.Welch" <P.H.Welch@xxxxxxxxxx>]

Hi,

I've been speed reading the recent mailings and find them hard to absorb!
I may have observations about priority to make when I get some time ...

Meanwhile, David wrote:
> The occam-pi language is an over-extended version of occam
> with no formal specification. Some of the novel features have no
> efficient implementation in message-passing distributed memory
> machines.

We have only ever presented occam-pi as a language *experiment*.
We wanted to fold in basic ideas from the pi-calculus, taking care to
merge it smoothly with the occam-CSP model.  We have found the dynamics
introduced really useful for large-scale complex systems modelling
(especially for studying emergence and how to manage it) - stronger than
"useful" in fact, probably essential for understanding and designing
our systems.  We freely admit that the occam-pi syntax for mobility
does not fit that well with occam2 - but that is one of things my talk
at CPA 2012 (lightly) explored.

Re. formal specification: I'm fairly sure this can be done.  At Tony
Hoare's 70th. birthday workshop, Tony told how to do pi-calculus things in
CSP and Robin Milner did the reverse!  At least, that's my recollection.
Bill Roscoe also addresses channel mobility in his recent book.

The barrier syncs in occam-pi (basic CSP events) have also turned out
to be crucial for our modelling.  They could have been supported easily
by the transputer ... *except* for David's good concern about efficient
implementation across transputers (message-passing distributed memory).

However, *all* the occam-pi extensions have very efficient implementation
on shared memory multicore.  We even worked out a super-fast resolution
of CSP external choice over events on which any side could withdraw that
is linear in the number of events offered by each process (although we've
not put that into occam-pi yet, only JCSP).  Again, this fast resolution
only works for shared memory multicore.

The complex systems we have built (in our CoSMoS project with York
and others) typically run to tens of thousands of processes, with the
networks (i.e. processes/channels/barriers) dynamically being created
and with ever-changing topology.  One runs to 40 million plus processes.
Distribution on to message-passing distributed memory then becomes needed
and we hack it (since we have no efficient built-in way to support this) -
but the hacks (experiments) work.  Original transputers had no transparent
mechanism for channel communication between arbitrary transputers in
the network, so similar hacks were written (some turning into general
message-routing libraries).  The usefulness of this was so great that
the final transputer eventually did provide that transparent mechanism
(VCR plus router chips).  I see no reason why hardware support could
not, one day,  provide efficient distributed memory support for most
(maybe all) of the occam-pi ideas.  :)

> I've been working on language issues for quite a while now -
> mainly looking at how we can really get value out of thousands
> of processors.

David: whatever happened to the architecture designs you were floating
in the early to mid 1990s?  A sea (cloud?) of processors, routers and
memory nodes with intelligence for message combination, two-phase
randomised routing and supporting a unified memory address space
physically distributed (in non-contiguous chunks) over the memory nodes.
Such an architecture would be scaleable and provide what appears to be
shared memory with uniform access from all processors.  occam-pi would
run rather well there.

> So my suggestion is that we start form occam2, and look at what
> we need to add from occam3 and occam-pi. What is essential?

Agreed: occam-pi is an experiment and not everything may turn out to
be right or useful.  But occam-pi, unlike occam3, has actually been
implemented and used!  ;)

> Not sure how best to do this but I'd like to see it happen. I'd be
> happy to host a meeting.

Standing by,

Peter.