HARDYID@kirk.vax.aston.ac.uk (03/08/90)
There have been a few interesting messages recently on this net on the question 'where are the workstations?', to which I would ask the question 'do we need a Transputer based workstation?'. I am on this net and am therefore a strong believer in the Transputer (and even Occam!) so why am I asking such a question? well I'll attempt to explain myself. Multiple Transputer systems are clearly capable of providing a very impressive processing performance at a very competitive price when processing certain algorithms. However this does not make them suitable as the basis of a general purpose computer system, not everything can take advantage or indeed needs the power of a multiple Transputer system. Forcing people to port those parts of an application that cannot benefit from Transputer style parallelism, as well as those parts that can, adds to the expense/difficulty involved in developing Transputer Applications. Transputers are good at processing but bad at running a conventional operating system. This is mainly due to the lack of any support for a memory management unit, therefore DMA and memory protection are not possible. This would make it difficult to implement a conventional workstation, with support for multiple processes (jobs) and multiple users. Yes I know about Helios! a nice operating system, but I'm not convinced that it gets around these problems in a safe, consistent and efficient manner. The solution (?!!):- use your Transputers in conjunction with an already existing general purpose computer system. You then only need to port those parts of an application that can take advantage of the Transputers. Nor do you need a complicated operating system or to develop/buy dedicated peripheral devices such as displays (or less this is the area that your intending to speed-up by using Transputers!) The Transputers can then be used either as a co-processor to a host computer or (much more interestingly) as a 'compute' server on a network. Unfortunately the standard TDS, toolkit and other software development tools do not allow for the flexible co-operation of processes running on the Transputers with processes on the host. One solution is the CD-TSE (Cresco Data - Transputer Software Environment) for Transputers hosted in an Apollo workstation. This allows a program running on the workstation to initiate processing on the Transputers through a remote procedure call mechanism and for the two systems to communicate with each other using communication channels. Trollius and the related Genesys (from Transtech) operating systems also look interesting in this respect (does anyone know of any good references on these that are available in the UK?). I agree with the sentiments expressed by Thomas Donaldson that the investigation of suitable algorithms for use with the Transputers is important. The tools needed for software development with Transputers are well understood algorithm structures not operating systems!. These should allow efficient software to be easily produced (or at least provide a basis on which performance of a system can be reasoned about before it is implemented). If possible such structures should generate software that is independent of the number of processors and of their interconnection topology. This will allow the construction of software that can be easily used on different systems. One structure that has been shown to offer significant promise in this respect is the 'Processor Farm'. I am developing a system called ANTS (Aston Networked Transputer System). This uses a Transputer system hosted by an Apollo DN3000 workstation and the CD-TSE software. Apollo's Network Computing System (NCS) is used to allow 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. On the Transputer system a modified version of the processor farm paradigm is used that allows multiple calls to be processed simultaneously. This is important if the system is to be used as a true network resource. The penalty paid for this is that the services provided by the system must be 'trusted', as multiple jobs will be processed on the same processor. I have a prototype system working that demonstrates the potential, efficient - near linear speedup and even allocation of resources to active calls. In summary, why not use Transputers for what they are good at; processing - not providing an operating system (680X0's, 860X86's, Sparcs, i860's.....etc. are very good at this!). Use Transputers as a component of a general purpose computing system not as a general purpose computing system! --------------------------------------------------------------------- Ian Hardy hardyid@uk.ac.aston.clust Dept.Computer Science, Tel: 021-359 3611 Ext. 4272 Aston University, Birmingham, B4 7ET --------------------------------------------------------------------- The above are my own opinions, I don't expect everyone to agree with them!!.
nick@lfcs.ed.ac.uk (Nick Rothwell) (03/08/90)
In article <6404.9003072153@prg.ox.ac.uk>, HARDYID@kirk writes: >There have been a few interesting messages recently on this net on the >question 'where are the workstations?' What about the Cogent XTM? >Ian Hardy Nick. -- Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!nick ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ A prop? ...or wings? A prop? ...or wings? A prop?
chris@aivru.sheffield.ac.uk (Chris Brown) (03/09/90)
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)
srm@cacs.usl.edu (Seshagiri Rao Myneni) (03/19/90)
In article <2686@castle.ed.ac.uk> nick@lfcs.ed.ac.uk (Nick Rothwell) writes: >In article <6404.9003072153@prg.ox.ac.uk>, HARDYID@kirk writes: >>There have been a few interesting messages recently on this net on the >>question 'where are the workstations?' > >What about the Cogent XTM? > Yah ! Cogent XTM is a Transputer T-800(?) based Workstation. It is available even in Japan (as Cogent XLNT). I am working on a Cogent XTM for our Robotic Arm Simulations. It's performance is also good! >>Ian Hardy > > Nick. >-- >Nick Rothwell, Laboratory for Foundations of Computer Science, Edinburgh. > nick@lfcs.ed.ac.uk <Atlantic Ocean>!mcvax!ukc!lfcs!nick >~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ ~~ > A prop? ...or wings? A prop? ...or wings? A prop? Seshu. ------------------------------------------------------------------------------ Seshagiri Rao Myneni e-mail address: 908 Lamar, # 108 1. srm@gator.cacs.usl.edu Lafayette, LA 70501 2. srm@swamp.cacs.usl.edu USA. Phone # (318) 235-6183. Off 231-5779.