Showing papers on "SISAL published in 1991"

The SISAL 2. 0 reference manual

Abstract: In this report we describe the SISAL 2.0 programming language. The project began in 1982 as a cooperative venture by Digital Equipment Corporation, the University of Manchester (England), Lawrence Livermore National Laboratory, and Colorado State University. The project`s goals evolved to become: Define a general-purpose functional language that can run efficiently on conventional and novel parallel architectures; Define a dataflow graph intermediate form independent of language and target architecture; Develop optimization techniques for high-performance applicative computing; Develop a thread management environment to support dataflow-style parallel computing on conventional shared-memory multiprocessors; Achieve sequential and parallel execution performance competitive with program written in conventional languages; and Validate the functional style of programming for large-scale scientific applications. The last three goals set SISAL apart from other efforts. We have shown that the dataflow approach can profitably be applied outside the classic dataflow world, without the use of specialized hardware. SISAL runs on uniprocessors, shared-memory multiprocessors, the Cray-X/MP, the Warp systolic processor as well as Manchester`s dataflow machine. Development continues for the Connection Machine and some experimental systems.

Arrays in Sisal

Abstract: Although Sisal (Streams and Iterations in a Single Assignment Language) is a general-purpose applicative language, its expected program domain is large-scale scientific applications. Since arrays are an indispensable data structure for such applications, the designers of Sisal included arrays and a robust set of array operations in the language definition. In this paper, we review and evaluate those design decisions in light of the first Sisal compilers and runtime systems for shared-memory multiprocessor systems. In general, array intensive applications written in Sisal 1.2 execute as fast as their Fortran equivalents. However, a number of design decisions have hurt expressiveness and performance. We discuss these flaws and describe how the new language definition (Sisal 2.0) corrects them.

Control flow extensions to the dataflow language SISAL

Abstract: The proponents of the dataflow programming model have been citing its advantages; exposing fine grain parallelism, freedom from side-effects, and synchronization based purely on data dependencies. Opponents of the model cite large overheads incurred in utilizing the fine grain parallelism, the lack of facilities to specify coarse grain parallelism, and lack of explicit control of the concurrent activities. More recently, there have been numerous proposals for combining some control flow concepts with the dataflow model. The authors' research differs from these primarily because the attempt to bring the dataflow language closer to more popular control flow based concurrent programming languages, while retaining the fundamental properties of dataflow models. Their main goal is to provide the programmer with mechanisms to define and control coarse grain concurrency. To this end, they have extended the SISAL language (for Sequent) by including fork, join and break constructs. >

A comparison of structure accessing techniques in IdA and SISAL on the CSIRAC II dataflow multiprocessor

Abstract: Describes the implementation of the functional language IdA on the CSIRAC II dataflow multiprocessor. IdA is a derivative of MIT's ID Nouveau language and CSIRAC II is a dataflow architecture which combines the features of static queued and dynamic dataflow architectures and as such is outside the generally accepted taxonomy. The non-strict implementation of structures in IdA exploits the overlap in the production and consumption of structures. This eliminates the unnecessary serialisation of the computation evidenced in the implementation of another functional language SISAL. To illustrate this, results for the numerical weather prediction code, Shallow, are presented for both IdA and SISAL formulations. These results show that for similar instruction counts a 39% reduction in runtime is obtained for the IdA implementation over the SISAL implementation in a representative scientific application. >