The AI Ltd solution to the problems of programming parallel computer systems
The operations director of AI Ltd, David Catton, opted to assess parallel computing systems for the benefit of delegates at the UK Computer Measurement Group conference in Glasgow last week. He began by explaining that the desire for ever greater computer power has attracted attention to the bottleneck of a single, sequential processor. Sticking plaster remedies presently include clusters of mainframes, or the construction of parallel hardware from lots of personal computers. The difficulty with these remedies, according to Catton, is that there are no programming languages and tools specifically developed for parallel processing, meanwhile in a Catch 22 situation that data centre managers are unlikely to write-off their current investment in applications software. Thus, as Catton sees it, the constraint to going parallel is more one of software assessment than hardware assessment. Some parallel computers on the market at the moment run programs in parallel but only on one processor at a time, whereas for maximum speed several processors need to co-operate to solve a single problem, with the program spreading processes over all those processors. To this end stretched versions of existing sequential languages such as Fortran have been produced with explicit parallelising constructs added. In development terms, Catton believes this illustrates how far software design is lagging behind the design of parallel hardware. This is clearly a problem to which he has devoted much time and thought, as he outlined what such software must look like. It must be portable between different processor architectures and configurations; it must be able to interface and integrate with existing sequential languages; and it must also have a concurrent structure that implies a declarative style that does not contain go to instructions.
Hursley Park
The other problem with parallel processing is that it is part of our culture to think and act sequentially, therefore parallel software must make it easy for the programmer to express the parallelism inherent in any solution, and have a programming language that makes the parallelism effective in the resultant code. Catton suggested that the software supplier meet these requirements by producing a standard library routine in collaboration with the machine supplier to map the virtual topology onto the machine’s physical topology thereby giving the programmer control over optimising the way the code is run. In this way, a programmer can code, debug, validate and compile an application program targetted at delivery on a hardware platform possibly having thousands of processors with complete security on a single processor workstation. Catton explained that such parallel program design is supported by Streams and Concurrent Objects. Streams are a simple construct recently introduced into programming languages which express communication between computations running concurrently on different processors; while Concurrent Objects extend the ideas of object-oriented programming (CI No 1,160) into the world of parallel and distributed processing. And how does Catton know so much about all this? Well, it just so happens that AI Ltd has developed a general purpose programming system for concurrent computers called Strand88 which, surprise, surprise, conforms to all the requirements Catton outlined. It is available now for Sun Microsystems Inc Sun-3 and Sun-4 series workstations, Atari ATW Transputer workstations, Transputer plug-in boards under the Helios operating system, Intel iPSC/2, and System V.386 workstations. Catton also said that IBM has expressed interest in the product and that he believes there is something relevant astir at Hursley Park.
20 Ways to Avoid an Upgrade
Mainframe vendors should take note that Adrian Shewan, Capacity Management Consultant with SPS Education Ltd addressed a packed meeting of delegates at the UK Computer Measurement Group conference, all eager to learn 20 ways to avoid an upgrade. Shewa
n’s thoughts on the subject were prompted by the October 1987 stockmarket crash, which engendered computing budget reductions in many companies. Every cloud has a silver lining, however, and Shewan wants to spread the gospel among capacity planners that there is a do-nothing option. Its all just a question of managing existing resources or, if necessary, using an alternative supply such as a bureau service. There are also a number of service options the capacity planner can consider. For example, service level agreements can be renegotiated to change customer expectations, so that if service level objectives are not being met, Shewan argues, the objectives should be changed to produce a marginally lower quality of service. Another service option is to change or limit application functionality. Shewan gave the examples of DB2 and SQL being used like sawn-off shotguns, with the 3090 used as if it was a personal computer. His advice? Don’t give them those transactions to play with. Service should also be limited to the service levels agreed, according to the Shewan philosophy, for if a consistent service of three second response time can be given, then no better response time should ever be delivered or the upgrade rot will set in. Other recommended ways of dodging an upgrade will probably be familiar to capacity planners. There is the tactic of deferring a decision until the next budget year, the elimination of unnecessary workloads, and the adjustment of the frequency of execution of some business applications and support activities. A particularly popular idea which was met with peals of delegate laughter was the delicate proposition that people going round measuring things was very resource-intensive and led to a decline in service; therefore if people would stop collecting records and comparing things using large databases, overheads would be significantly reduced. The trendiest way to avoid an upgrade has to be the implementation of the Japanese Just In Time planning and control, but Shewan’s parting shot was probably closest to the mark. Namely that the easiest way for a capacity manager to avoid an upgrade was to resign. – Katy Ring
Content from our partners
