Parallel computers with non-parallel file systems find limited by the performance of the processor running the file system. We have designed and implemented a parallel file system called Bridge that eliminates this problem by spreading both data and file system computation over a large number of processors and disks. To assess the effectiveness of Bridge we have used it as the basis of a parallel external merge sort, an application requiring significant amounts of interprocessor communication and data movement. A detailed analysis of this application indicates that Bridge can profitably be used on configurations in excess of one hundred processors with disks. Empirical results on a 32-processor implementation agree closely with the analysis, providing us with a high degree of confidence in this prediction. Based on our experience, we argue that file systems such as Bridge will satisfy the 1/0 needs of a wide range of parallel architectures and applications.

Parallel computers with non-parallel le systems are limited by the performance of the processor running the le system. We have designed and implemented a parallel le system called Bridge that eliminates this problem by spreading both data and le system computation over a large number of processors and disks. To assess the e ectiveness of Bridge we have used it to implement several data-intensive applications, including a parallel external merge sort. The merge sort is a particularly demanding application; it requires signi cant amounts of interprocessor communication and data movement. A detailed analysis of this application indicates that Bridge can pro tably be used on con gurations in which disks are attached to more than 150 processors. Empirical results on a 32-processor implementation agree with the analysis, providing us with a high degree of con dence in this prediction. Based on our experience, we argue that le systems such as Bridge will satisfy the I/O needs of a wide range of parallel architectures and applications. Index Terms|Bridge, parallel le systems, analysis of algorithms, disk striping, external sorting, mergesort, multiprocessor speedup.

High-performance parallel computers require high-performance file systems. Exotic I/O hardware will be of little use if file system software runs on a single processor of a many-processor machine. We believe that cost-effective I/O for large multiprocessors can best be obtained by spreading both data and file system computation over a large number of processors and disks. To assess the effectiveness of this approach, we have implemented a prototype system called Bridge, and have studied its performance on several data intensive applications, among them external sorting. A detailed analysis of our sorting algorithm indicates that Bridge can profitably be used on configurations in excess of one hundred processors with disks. Empirical results on a 32-processor implementation agree with the analysis, providing us with a high degree of confidence in this prediction. Based on our experience, we argue that file systems such as Bridge will satisfy the I/O needs of a wide range of parallel architectures and applications.

A parallel file system called Bridge that distributes each file across multiple storage devices and processors has been designed and prototyped. The approach is based on the notion of an interleaved file, in which consecutive logical blocks are assigned to different physical nodes. Naive programs are able to access files just as they would with a conventional file system, while more sophisticated programs can export pieces of their code to the processors managing the data, for optimum performance. Early analytical and experimental results indicate that Bridge will deliver good parallel speedup for configurations in excess of 32 nodes with disks. High performance is achieved by exporting the I/O-related portions of an application into the processors closest to the data. A pair of applications that illustrate this technology is presented. General issues in the design of algorithms for Bridge are discussed.< >

: Elmwood is an object-oriented, multiprocessor operating system designed and implemented as a group project at the University of Rochester. An Elmwood object, consisting of code and data, represents an instance of an abstracts data type. Only the code associated with an object may access its data; interaction between objects is via remote procedure call. Access to an object requires that the caller provide an appropriate logical object name, which denotes a kernel-protected pair containing an object reference and a context value. Elmwood provides only basic mechanisms for protection and synchronization; the object itself supplies and interprets the context value, thereby implementing its own policies for protection and synchronization. We describe the Elmwood design, and multiprocessor implementation for the BBN Butterfly Parallel Processor, and our experiences in building a functionally-complete operating system as a group project in four months.

In intensive work over a four-week period in the summer of 1986, seven problems were studied and implemented on the Butterfly. The problems were Inspired by various capabilities in computer vision, and were proposed as benchmarks for a DARPA worksho{' on parallel architectures. They were: convolution and zero-crossing detectlOn for edges, edge tracking, connected component labeling, hough transform, three computational geometry problems (convex hull, voronoi diagram, and minimum spanning tree), three-dimensional visibility calculations, subgraph isomorphism and minimum cost path calculation. BPRs 10,11, and 14 are detailed reports on three of the problems. BPR13 contains the conclusions of the study and writeups of the work not covered in other BPRs. This work was supported in part by the Defense Advanced Research Projects Agency U.S. Army Topographic Labs under grant number DACA76-85-C-0001 and in part by the National Science Foundation under grant number DCR-8320136.