Since the early days of logic programming, researchers in the field realized the potential for exploitation of parallelism present in the execution of logic programs. Their high-level nature, the presence of non-determinism, and their referential transparency, among other characteristics, make logic programs interesting candidates for obtaining speedups through parallel execution. At the same time, the fact that the typical applications of logic programming frequently involve irregular computations, make heavy use of dynamic data structures with logical variables, and involve search and speculation, makes the techniques used in the corresponding parallelizing compilers and run-time systems potentially interesting even outside the field. The objective of this paper is to provide a comprehensive survey of the issues arising in parallel execution of logic programming languages along with the most relevant approaches explored to date in the field. Focus is mostly given to the challenges emerging from the parallel execution of Prolog programs. The paper describes the major techniques used for shared memory implementation of Or-parallelism, Andparallelism, and combinations of the two. We also explore some related issues, such as memory management, compile-time analysis, and execution visualization.

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.

Execution of Prolog Machine on aBased on extending the sequential execution model of Prolog to include parallel execution, we present a method for OR-parallel execution of Prolog on a multiprocessor system. The method reduces the overhead incurred by parallel processing. It allows many processing elements (PEs) to process simultaneously a common branch of a search tree, and each of these PEs creates its local environment and selects a subtree for processing without communication. The run-time overhead is small: simple and efficient operations for selecting the proper subtree. Communication is necessary only when some PEs have exhausted their search spaces and there are others still searching for solutions. The method is able to utilize most of the technology devised for sequential implementation of Prolog. It is optimized for an architecture that supports broadcast copying.

No abstract

We present a garbage-collection algorithm, suitable for loosely-coupled multiprocessor systems, in which the processing elements (PEs) share only the communication medium. The algorithm is global, i.e., it involves all the PEs in the system. It allows space compaction, and it uses a system-wide marking phase to mark all accessible objects where a combination of parallel breadth-first/depthfirst strategies is used for tracing the object-graphs according to a decentralized credit mechanism that regulates the number of garbage collection messages in the system. The credit mechanism is crucial for determining the space requirement of the garbage-collection messages. Also a variation of this algorithm is presented for systems with high locality of reference. It allows each PE to perform first its local garbage collection and only invokes the global garbage collection when the freed space by the local collector is insufficient.

No abstract