The muse approach to Or-parallel prolog

Abstract

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.

A Tabling Implementation Based on Variables with Multiple Bindings

“…This has been recognized in early work [19]. The similarity between Or-Parallel and tabling using complex trail and stack management (e.g., implementations of the SRI model [20] and SLG-WAM) and those relying on copying (e.g., CHAT and the MUSE [21]) have been mentioned elsewhere [11]. However, to the best of our knowledge, variable access has remained largely untouched in all tabling systems, when, from an abstract point of view, making a variable access different values depending on the environment (e.g., the sid global flag) which the variable is seeing is a fundamental operation.…”

High Level Thread-Based Competitive Or-Parallelism in Logtalk

“…A number of approaches have been proposed to tackle this problem (see e.g [1]). Arguably, the two most successful ones are environment copying, as implemented in the Muse [7] and YapOr [8] systems, and binding arrays, as implemented in the Aurora system [9]. In the environment copying model, each worker maintains its own copy of the environment (stack, heap, trail, etc) in which it can write without causing binding conflicts.…”

“…The Prolog compilers that implement the standardization proposal allow dynamic predicates to be instead declared thread local. 7 Thread-local dynamic predicates are intended for maintaining threadspecific state or intermediate results of a computation. A thread local predicate directive tells the system that the predicate may be modified using the built-in assert and retract predicates during execution of the program but, unlike normal shared dynamic data, each thread has its own clause list for the predicate (this clause list is empty when a thread starts).…”

On the Implementation of an Or-Parallel Prolog System for Clusters of Multicores

“…And-Parallelism stems from the parallel evaluation of subgoals in a clause, while or-parallelism results from the parallel evaluation of a subgoal call against the clauses that match that call. Arguably, or-parallel systems, such as Aurora (Lusk et al 1988) and Muse (Ali and Karlsson 1990), have been the most successful parallel Prolog systems so far. Intuitively, the least complexity of or-parallelism makes it more attractive and productive to exploit than and-parallelism, as a first step.…”

“…However, practice has shown that a main difficulty is how to efficiently represent the multiple bindings for the same variable produced by the or-parallel execution of alternative matching clauses. One of the most successful or-parallel models that solves the multiple bindings problem is environment copying, which has been efficiently used in the implementation of or-parallel Prolog systems both on shared memory (Ali and Karlsson 1990;Rocha et al 1999) and distributed memory (Villaverde et al 2001;Rocha et al 2003) architectures.…”