Enterprise lets developers write sequential code and then graphically express the parallelism in their applications using an analogy to a business organization. The system automatically converts the application to run on a network of workstations. Because the (sequential) code that calls the parallel procedures is independent of these procedures, programmers can adapt applications to varying numbers and types of processors without rewriting their code. Enterprise's analogy between program

more »

... ure and organizational structure eliminates inconsistent terminology (pipelines, masters, slaves, and so on) and introduces a consistent terminology based on assets. Jonathan Schaeffer is an associate professor of computer science at the University of Alberta. His research interests include parallel programming environments and algorithms, and heuristic search. He received a PhD and MMath from the University of Waterloo, and a BS from the University of Toronto. He is a member of the IEEE, ACM, and AAAI. Duane Szafron is an assistant professor of computer science at the University of Alberta. His research interests include object-oriented computing, programming environments, and user interfaces. He received a PhD from the University of Waterloo, and an MS and BS from the University of Regina. Ian Parsons is a doctoral candidate at the University of Alberta. His research interests include parallel programming environments for distributed memory applications. He received an MS (in 1992) and a BS (in 1991) in computing science from the University of Alberta, and a BS in chemistry from the University of Western Ontario in 1978. Greg Lobe is works for Bell Northern Research in Ottawa. His research interests include object-oriented and parallel programming. He received his MS and BS in computing science from the University of Alberta in 1993 and 1989 respectively. Designing, implementing, and testing distributed software is considerably more difficult than for comparable sequential software. There are efficient parallel algorithms for a large class of problems, but finding the right one can be only a small part of the implementation cost. Writing distributed software is also complicated by problems not found in the sequential environment, including synchronization, deadlock, communication, fault tolerance, heterogeneous computers and operating systems, and the complexity of debugging and testing programs that may be nondeterministic due to concurrent execution. Harnessing the power of a network of machines poses additional problems: The available processors available and their capabilities can vary from one execution to another; high communication costs can restrict the types of parallelism that can be implemented efficiently, and many developers do not want to become experts in networking or low-level communication protocols to gain the advantages of an application's potential parallelism. A few systems account for these problems, but programmers also need a system that can produce distributed software quickly, economically and reliably. The system must help developers bridge the complexity gap between distributed and sequential software without extensive training. Our system -Enterprise -is a programming environment for designing, coding, debugging, testing, monitoring, profiling, and executing programs for distributed hardware. Developers using Enterprise do not deal with low-level programming details such as marshalling data, sending/receiving messages, and synchronization. Instead, they write their programs in C, augmented by new semantics that allow procedure calls to be executed in parallel. Enterprise automatically inserts the necessary code for communication and synchronization. However, Enterprise does not choose the type of parallelism to apply. The developer is often the best judge of how parallelism can be exploited in a particular application, so Enterprise lets the programmer draw a diagram of the parallelism using a familiar analogy that is inherently parallel: a business organization, or enterprise, which divides large tasks into smaller tasks and allocates assets to perform those tasks. These assets correspond to techniques used in most large-grained parallel programs -pipelines, master/slave processes, divide-and-conquer, and so on -and the number and kinds of assets used determine the amount of parallelism. For example, an individual performs a task sequentially, but four individuals can perform four similar tasks concurrently. A department can subdivide a task among components that can then perform the subtasks concurrently. An assembly or processing line can start a second task as soon as the first component of that line has passed the first task to the second component.