🚀 go-pugleaf

Ian Hardy writes about a system called ANTS which he is developing,

> "allowing client programs running on computers on a connected network
> to make remote procedure calls to the Transputer system, which then
> acts as a compute server to the network."

We are doing something similar. We have a network of Sun Workstations,
one of which hosts a 25-transputer box called `Marvin'. This machine is
programmed entirely in 3L Parallel C. We have added protocols into the
afserver to allow tasks in the transputer networks to:

(a) spawn additional unix processes in the host machine and obtain
    connections to the stdin and stdout of those processes, and

(b) create a socket and attempt to connect to a socket bound to a server
    process elsewhere in the Sun network.

At present the client/server relationship we use is the "opposite way
round" to the one I think Ian Hardy has in mind. The transputer network
is the client, the Suns offer services. At present two key services are
image acquisition, and robot-arm-wiggling. (We do machine vision).

For our next development we intend to reverse this client/server
relationship; Marvin will become a "feature tracking geometry server" for
the Suns on the network.

The point is, it is still an order of magnitude harder for us to write
code which effectively exploits a box of transputers than it is to
write code on the Sun. So, you only put the really computationally intensive
stuff on there. Good interprocess communications (whether it be via an RPC
type interface as Ian proposes, or a more occammy message passing style)
are necessary for this approach, both within the transputer network and
within the workstation LAN. 

For us, learning to use the *entire* network as a computational resource
is making life steadily more productive.

Chris Brown, A.I. Vision Research Unit, Sheffield University 
(chris@aivru.sheffield.ac.uk)