Muse (Multi-sequential Prolog engines) is a simple and efficient approach to Or-parallel execution of Prolog programs. It is based on having several sequential Prolog engines, each with its local address space, and some shared memory space. It is currently implemented on a 7-processors machine with local/shared memory constructed at SICS, a 16-processors Sequent Symmetry, a 96-processors BBN Butterfly I, and a 45-processors BBN Butterfly II. The sequential SICStus Prolog system has been adapted to Or-parallel implementation. Extra overhead associated with this adaptation is very low in comparison with the other approaches. The speed-up factor is very close to the number of processors in the system for a large class of problems.The goal of this paper is to present the Muse execution model, some of its implementation issues, a variant of Prolog suitable for multiprocessor implementations, and some experimental results obtained from two different multiprocessor systems.

Muse is a simple and efficient approach to Or-parallel implementation of the full Prolog language. It is based on having multiple sequential Prolog engines, each with its local address space, and some shared memory space. It is currently implemented on a number of bus-based and switch-based multiprocessors. The sequential SICStus Prolog system has been adapted to Or-parallel implementation with very low extra overhead in comparison with other approaches. The Muse performanhce results are very encouraging in absolute and relative terms. The Muse execution model and its performance results on two different multiprocessor machines for a parallel version of Prolog, named Commit Prolog, have been presented in previous papers. This paper discusses supporting the full Prolog language and describes mechanisms being developed for scheduling Or-parallelism in Muse. It also presents performance results of the Muse implementation on Sequent Symmetry after supporting full Prolog. The results show that the extra overhead associated with supporting the full Prolog language is negligible.

Work which may later be pruned is called speculative work. In this paper we present and evaluate a simple and efficient strategy, used in the Muse OR-parallel Prolog system, for better scheduling of speculative work. The strategy concentrates workers on the leftmost available work in the Prolog tree as'long as there exists enough parallelism, thus emulating the sequential Prolog execution as much as possible. This strategy therefore makes it less probable that unnecessary work is executed. A new cut scheme that reduces the amount of speculative work is also presented. The performance results of our strategy are compared with the performance results of similar strategies implemented in the Aurora OR-parallel Prolog system. The comparison shows that our strategy performs quite well.

No abstract

No abstract