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' 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:
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.
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. Inmos 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:
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:
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 Supernode 2 (Mark 2 is scheduled for about the end of the year).
An Image Processing Library is now being marketed by Quintek Ltd.
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.
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.
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; support 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:
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:
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.
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.
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.
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. Supernode 2 also contains a Finite Element software component.
Here we degenerate to listing a few products known to be available:
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.
