8. Conclusions 5.2.4 Overhead in Exec() 5.2.5 " System Call " Overhead 6. Evaluation 7. Future Work 5.2.1 Overhead in Fork() 5.2.2 Overhead in Copyin() and Copyout() 5.2.3 Rpc Latency 5.2 Current Performance Problems

15 drafts of the paper. Special thanks to John Ousterhout for providing the modified benchmark and for technical assistance and guidance. Beside additional development, it would be useful to conduct research using the Sprite server. For example, it would be interesting to compare the performance of the Sprite server with the performance of a similar server that uses Mach IPC for remote device access or for process migration [13]. Porting Sprite to Mach was a mixed success. On the one hand, it greatly reduced the amount of machine-dependent code in Sprite, which should make Sprite much easier to port to new hardware. The asynchronous interfaces provided by Mach require some unpleasant complexity in the Sprite server, but this complexity is manageable. On the other hand, the server is almost unusably slow, even after a couple months of tuning, and it appears that much work is still needed to bring performance within striking distance of the native system. At least one third of the performance gap results from the distributed nature of Sprite. However, the slowdown is not primarily due to RPC latency or throughput problems. Rather, it is due to the Sprite server's heavy use of an external pager, plus problems such as Sprite's inability to use mapped files to avoid copy overhead. The lesson here seems to be that there is more to high-performance distributed systems than fast communication, and although Mach shows promise as a general platform for distributed computing, it still has some serious shortcomings. For some problems (e.g., copy-on-write for external pagers) it should be possible to fix Mach, but in other cases (e.g., use of mapped files for performance), it may be necessary to redesign the distributed system instead. If one asks whether it is worth porting an existing system to run on top of Mach, the answer seems to be " it depends. " For a research system like Sprite, with its small development community, increased portability seems attractive enough to warrant a large one-time porting and tuning effort. On the other hand, a large commercial vendor, particularly a hardware vendor that would have to do its own Mach ports, would probably be better off to spend the time redesigning internal interfaces. There are other potential advantages to running on Mach, such as interoperability with different environments, but portability by itself seems inadequate justification to convert existing code to use Mach. The sources for …