We are developing Munin y , a system that allows programs written for shared memory multiprocessors to be executed e ciently on distributed memory machines. Thus, Munin overcomes the architectural limitations of shared memory machines, while maintaining their advantages in terms of ease of programming. A unique characteristic of Munin is the mechanism by which the shared memory programming model is translated to the distributed memory hardware. This translation is performed by r u n time software, with the aid of semantic hints provided by the user. Each shared data object is supported by a memory coherence mechanism appropriate to the manner in which the object is accessed. This paper focuses on Munin's memory coherence mechanisms, and compares our approach to previous work in this area.

We are developing Munin, a system that allows programs written for shared memory multiprocessors to be executed efficiently on distributed memory machines. Munin attempts to overcome the architectural limitations of shared memory machines, while maintaining their advantages in terms of ease of programming. Our system is unique in its use of loosely coherent memory, based on the partial order specified by a shared memory parallel program, and in its use of type-specific memory coherence. Instead of a single memory coherence mechanism for all shared data objects, Munin employs several different mechanisms, each appropriate for a different class of shared data object. These type-specific mechanisms are part of a runtime system that accepts hints from the user or the compiler to determine the coherence mechanism to be used for each object. This paper focuses on the design and use of Munin's memory coherence mechanisms, and compares our approach to previous work in this area.t In Norse mythology, Munin (Memory) was one of two ravens perched on Odin's shoulder. Each day, Munin would fly across the world and bring back to Odin knowledge of man's memory. Thus, the raven Munin might be considered the world's first distributed shared memory mechanism.

During a bulk data transfer over a high speed network, there is a high probability that the next packet received from the network by the destination host is the next packet in the transfer. An optimistic implementation of a bulk data transfer protocol takes advantage of this observation by instructing the network interface on the destination host to deposit the data of the next packet immediately into its anticipated final location. No copying of the data is required in the common case, and overhead is greatly reduced.Our optimistic implementation of the V kernel bulk data transfer protocols on SUN-3/50 workstations connected by a 10 megabit Ethernet achieves peak process-to-process data rates of 8.3 megabits per second for l-megabyte transfers, and 6.8 megabits per second for 8-kilobyte transfers, compared to 6.1 and 5.0 megabits per second for the pessimistic implementation.When the reception of a bulk data transfer is interrupted by the arrival of unexpected packets at the destination, the worst-case performance of the optimistic implementation is only 15 percent less than that of the pessimistic implementation.Measurements and simulation indicate that for a wide range of load conditions the optimistic implementation outperforms the pessimistic implementation.

During a bulk data transfer over a high speed network, there is a high probability that the next packet received from the network by the destination host is the next packet in the transfer. An optimistic implementation of a bulk data transfer protocol takes advantage of this observation by instructing the network interface on the destination host to deposit the data of the next packet immediately into its anticipated final location. No copying of the data is required in the common case, and overhead is greatly reduced.Our optimistic implementation of the V kernel bulk data transfer protocols on SUN-3/50 workstations connected by a 10 megabit Ethernet achieves peak process-to-process data rates of 8.3 megabits per second for l-megabyte transfers, and 6.8 megabits per second for 8-kilobyte transfers, compared to 6.1 and 5.0 megabits per second for the pessimistic implementation.When the reception of a bulk data transfer is interrupted by the arrival of unexpected packets at the destination, the worst-case performance of the optimistic implementation is only 15 percent less than that of the pessimistic implementation.Measurements and simulation indicate that for a wide range of load conditions the optimistic implementation outperforms the pessimistic implementation.

No abstract