Jump over left menu
Article in Issue 14 of the Engineering Computing Newsletter
When the SERC/DTI Engineering Applications of Transputers Initiative started in 1987 the T800, floating point, transputer was not yet available. It was possible to buy off-the-shelf transputer arrays with T414s (a tribute to the ease with which the design of complete hardware systems can be achieved), but it was not possible to buy much off-the-shelf software. Application codes were written in Occam or not at all, and we all loved to learn (or was it learned to love?) Inmos's Transputer Development System (TDS). We stepped into the unknown of parallel programming like Victorian explorers, that is, with very little equipment to help us. The resulting macho image was perhaps satisfying and, for some of us, perhaps it still is. But most users do not want to be macho - they want to be helped, helped to use their existing codes and existing skills, and helped with high level tools which provide performance at minimum effort. There is no doubt that a year or eighteen months ago, potential transputer users were put off by the lack of tools.
Luckily, the transputer market has proven to be big enough to encourage firms to provide tools, and the situation has changed rapidly over the past year. This article attempts to summarise the current situation realistically and to look a few months into the future (it seems impossible to see further ahead than that with any reliability).
Most users still have small arrays hosted by a PC; for these there was no operating system a year ago, but TDS provided what was (and is) a very usable closed environment, with an idiosyncratic user interface commendable for its brevity (single key depressions for everything) rather than its memorability (key assignments failed to survive version upgrading). We also got the Folding Editor, which most of us actually like a lot. However Inmos soon found why a closed environment is hard to maintain; it is difficult to port to new environments, hence the Stand-alone Toolkit, which deals with host (eg MSDOS) format files and provides an unbundled compiler, loader and configurer. The new Inmos Toolkit (TDT) is very usable indeed, with much better multi-language capabilities; we would reckon it is fairly mature.
Larger systems need a full-blooded operating system and that has to have a Unix user interface (because the market-place says so). Manufacturers are not blind, and the necessary work has been going on with severed alternatives now being marketed:
- MeikOS, for the Meiko Computing Surface, is at the beta release stage. It offers true multiuser access with hardware memory protection provided on the larger Surfaces. Each user gets a copy of MeikOS, which basically sits on a dedicated single transputer backed by a bare array.
- Trans-Idris is marketed by Real Time Systems for a variety of systems and has been adopted (and we believe extended) by Parsys for the Supernode machines. The first release, also now in beta release form, provided single user access only. The system is semi-distributed: Idris normally sits on one or a few transputers and provides access to a bare patch of workers and/or processes sitting under ldris, as specified.
- The two systems above are important in providing Unix on the two best known large systems.
Other suppliers have started from scratch to design truly distributed operating systems for MIMD
architectures. These are also now becoming available:
- Helios, probably the best known at the moment, is the standard OS for the new Atari Transputer Workstation, but is available for other systems too, including those that are PC-hosted.
- Sun-VCS is marketed by Meiko and integrates with SunOS for its In-Sun Surface, and is (claimed to be - we have not checked in detail) highly compatible with MeikOS, making the Sun workstations nice companions to the Surface.
Other operating systems are known to be under development, eg the Esprit-funded Supernode 2 project has a start-from-scratch OS as part of its development programme. Hence, once the current offerings mature (ie, go from beta release to usable - probably only a few months), we will be faced by too many rather than too few operating systems. Given the quite similar architecture of all systems, we expect to see a shakedown over the next few years, with one or more players retiring hurt.
Languages and Compilers
Fortran and C
There has been similar progress with the provision of compilers. There are now multiple vendors of reliable C and Fortran compilers, with 3L being probably the most widely used. The 3L parallel compilers are self-supporting (ie do not need TDT), robust and provide explicit support for parallelism. They are not however optimising compilers and do not generate code as good as that given by Occam (the speed factor can be two or higher). Meiko Fortran is similar in robustness and efficiency, and is also available under Helios. lnmos is understood to have an optimising Fortran compiler almost ready, which should produce. better code, but already the situation for applications programmers is much more satisfactory than it was a year ago. You can write applications in standard Fortran77 or C (plus, as a minimum, calls to system routines to pass data to other processors), without even hearing the word Occam.
There is also a surprisingly wide spread of other languages available. We list the most important:
- Ada: Alsys has now validated its Ada compiler in native mode on a single T800 (and there is a cross-compiler hosted on a VAX too). This is strictly a single-transputer implementation; tasks will not be spread between processors. You can write for an array in Ada though, just as in Fortran, by passing data via library routines. Providing true multi-processor Ada is difficult on any local memory machine and we do not expect to see an extended compiler for a year or so yet.
- Pascal: Those who succumbed to the Pascal bandwagon need not climb off yet; 3L Parallel Pascal is available and is a perfectly reasonable implementation.
- Others: Also available for a single Transputer are: Modula 2; Lisp; Prolog; Standard ML; Basic (and why not?). These are newer products and we have no direct experience with them, but it is clear that transputer users are now relatively well served with standard serial languages.
Aids to Producing Parallel Software
All of the above serial languages can be used to code for a transputer array, provided that the programmer arranges to send and receive data between processors via library routine calls. We look here at which higher-level aids arc currently available:
By general agreement the most tedious feature of coding for current arrays is the need to explicitly route messages intended for a remote processor, using explicit message passing on intervening processors. This need is inherent in the current Occam implementation (though not in the language definition) and in all other languages if these are coded for bare arrays. Several suppliers now can manage the through-routing for you, provided you program within their environment:
- Meiko provide, in CS Tools, full through-routing support for Fortran and C (and probably other languages too). Programs written in this environment can be linked and will work without change on any topology array.
- Helios also provides automatic through-routing as part of the operating system. (A current question, with no unanimous answer, is whether the through-routing facility should be in the operating system or, as in CS Tools, in the linker.)
On a vector processor we have become used to coding primarily in a standard serial language with no vector syntax, and letting the compiler (perhaps with a bit of help from loop re-arrangements or compiler directives) vectorise the code by itself; vectorising compilers have indeed become quite good. So far, no parallelising compiler for transputer arrays exists; there is a project within Supernode 2 to produce one (by System Software Factors), but this is several years away from fruition.
The simplest route to parallelism, in the absence of automatic parallelisation , is to make calls to a library of parallel routines. Two general purpose libraries have reached the market so far, from TopExpress and from Liverpool University (marketed by NA Software Ltd). They arc not yet very extensive in their coverage. Liverpool, with NAG, are extending the latter library as part of Supemode 2 (Mark 2 is scheduled for about the end of the year).
An Image Processing Library is now being marketed by Quintek Ltd.
Other Automatic Speedup Aids
There is a place for software able to speed up single processor code. The simplest such aid is a library of assembler routines. Both TopExpress and NA Software market such libraries, which can show speedups compared to the equivalent Fortran code of factors of 3 or more (factors of over 20 in isolated cases). Significant speedups (factors of about 1.5 to 2) are even obtainable compared with Occam.
System Software Factors also markets FLOLIB. This is a source to source translator, which will analyse and (where it can) restructure a Fortran program, inserting calls to a library of assembler routines to achieve painless speedups. A library from Liverpool is marketed with the 3L Fortran version of FLOLIB, and speedups of a factor of 3 for a complete program have been measured in favourable cases (and no speedup at all in other cases). There should be a steady development of FLOLIB towards a fully autoparallelising tool.
Support for Particular Parallel Paradigms
Both Helios and MeikOS provide software tools to make producing at least simple parallel programs easy. In particular, the processor farm paradigm (single server, multiple client is an alternative jargon) lends itself to automation, and is well supported. Surprisingly many applications can make use of this technique effectively.
Language Support for Parallelism
There is a dichotomy between those who want to use a conventional language, with as few (preferably zero) additions as possible, and those who would like explicit parallel constructs in the languages provided. As noted above, Meiko Fortran and most versions of C provide no new syntax; suppon for message passing is via library routines. Occam of course provides one mechanism which supports the full range from fine to coarse grained parallelism. With 3L Fortran, the description of the parallelism is provided by the user in a separate file using a configuration language. Should we use it? Unless the configuration language becomes standard, and widely implemented, it also reduces portability.
Other products also support parallelism via different routes:
- Strand88: provides a Prolog-like language environment which aims to make writing parallel algorithms very easy. It shows signs of becoming popular for new and suitable applications. Recently it has been extended to support linking with both Fortran and C. Strand also runs on a variety of other platforms as well as Transputers (eg Intel Hypercube and Sequent).
- Express: provides a layer on top of a standard operating system, with facilities aimed at making program conversion very easy (it helps new code development too). Again, the system should find a significant market.
- GENESYS II: based on the US-funded Trollius 2.0, is a run time environment available for a Sun-hosted system from Transtech Systems Ltd.
No software development environment is complete without good debugging facilities. TBUG, from 3L, Express and GENESYS II all provide useful debugging aids. We are also aware of a number of other activities which will greatly improve the current situation.
Another problem with transputer arrays has been the lack of applications software available, which is a problem with all new processors, of course. But an encouraging amount is now reaching the market. We mention some of the useful packages of which we are aware, with apologies to those we omit through ignorance:
The Serial NAG Fortran Library
This is available for a single Transputer under Inmos (3L) Fortran (all 750+ routines) and represents an extremely useful adjunct to the parallel libraries. For the Occam user, a set of 50+ high level Occam-callable routines is marketed by TopExpress.
Graphics and Windows
GKS, the NAG Graphics Library, Xwindows and WFS (from Nexus) are all now available, in addition to the widely used BOO7-compatible primitives provided by Inmos. Quintek also markets a graphics library aimed at producing graphics on a PC screen for those who do not have a transputer graphics board.
Glim and Genstat
These are statistics packages from NAG; a single transputer port of Glim (Generalised Linear Modelling) has been completed, while the general statistical package Genstat should be available with six months.
Finite Element Software
Transputer arrays are well suited to fast Finite Element calculations. This is a broad field, and no one package is yet available which will cover all Finite Element needs, but commercial Finite Element Method (FEM) software is available from Rockfield Software for some classes of problem, while at least two suppliers of general purpose FEM packages are known to be studying full ports. Supemode 2 also contains a Finite Element software component.
Here we degenerate to listing a few products known to be available:
- Predict!: a fast spreadsheet and simulation package
- TEX: a favourite (especially with mathematicians) typesetting package.
- The Transputer Initiative Library: a collection of mainly public domain software covering a wide range of applications, and available from the Sheffield Transputer Support Centre.
The software situation for transputer arrays has been transformed over the past year.
There is now a reasonable level of support for programmers and a growing level of applications software. We expect this growth in support to continue. Known commercial UK and EEC funded projects make this certain. This must be good news for users, whether current or potential; as the market expands everyone benefits.
If you require more information on the software mentioned in this article, on any other aspects of Transputers or the SERC/DTI Engineering Applications of Transputers Initiative, contact the Coordinator in the Informatics Department at Rutherford Appleton Laboratory .