OR-parallel Prolog System Research Articles

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

AbstractNowadays, clusters of multicores are becoming the norm and, although, many or-parallel Prolog systems have been developed in the past, to the best of our knowledge, none of them was specially designed to explore the combination of shared and distributed memory architectures. In recent work, we have proposed a novel computational model specially designed for such combination which introduces a layered model with two scheduling levels, one for workers sharing memory resources, which we named a team of workers, and another for teams of workers (not sharing memory resources). In this work, we present a first implementation of such model and for that we revive and extend the YapOr system to exploit or-parallelism between teams of workers. We also propose a new set of built-in predicates that constitute the syntax to interact with an or-parallel engine in our platform. Experimental results show that our implementation is able to increase speedups as we increase the number of workers per team, thus taking advantage of the maximum number of cores in a machine, and to increase speedups as we increase the number of teams, thus taking advantage of adding more computer nodes to a cluster.

A team-based scheduling model for interfacing or-parallel prolog engines

Logic Programming languages, such as Prolog, offer a great potential for the exploitation of implicit parallelism. One of the most noticeable sources of implicit parallelism in Prolog programs is or-parallelism. Or-parallelism arises from the simultaneous evaluation of a subgoal call against the clauses that match that call. Nowadays, multicores and clusters of multicores are becoming the norm and, although, many parallel Prolog systems have been developed in the past, to the best of our knowledge, none of them was specially designed to explore the combination of shared and distributed memory architectures. Conceptually, an or-parallel Prolog system consists of two components: an or-parallel engine (i.e., a set of independent Prolog engines which we named a team of workers) and a scheduler. In this work, we propose a team-based scheduling model to efficiently exploit parallelism between different or-parallel engines running on top of clusters of multicores. Our proposal defines a layered approach where a second-level scheduler specifies a clean interface for scheduling work between the base or-parallel engines, thus enabling different scheduling combinations to be used for distributing work among workers inside a team and among teams.

Or-parallel Prolog on a distributed memory architecture

This paper discusses the design of Dorpp, an or-parallel Prolog system for distributed memory architectures. The problem of sharing the environment across a set of nodes that do not physically share memory is addressed in a novel manner by designing a Virtual Shared Memory (VSM) scheme to specifically meet the requirements of or-parallelism. The aim is to avoid the overheads of a general VSM scheme that would provide a stricter level of memory coherence than is actually required. The paper identifies the requirements for memory coherence in or-parallel Prolog, and describes how they can be met cheaply. Simulation results are presented and analyzed in order to highlight key aspects of the system's run-time behavior.

Aurora vs. Muse: a portability study of two or-parallel Prolog systems

Prolog programs have explicit parallelism, that is, parallelism which can be exploited by a machine with minimal user effort. Or-parallelism is one such form of parallelism, and is particularly useful in that it is present in the many Prolog applications where several alternatives need to be considered. Or-parallelism has been exploited successfully in several systems, and especially in the Aurora and Muse systems. In this paper we analyze the portability of these two parallel systems onto a commercial shared memory parallel computer, a Sun SPARCcenter 2000 with 8 processors, running the Solaris 2.2 Operating System. We also analyze both systems' performance for classical benchmark programs and for two large Prolog applications.

An application of an OR-Parallel Prolog system to phylogenetic analysis

In this paper we discuss an application of our OR-Parallel Prolog system to a search problem of importance in practice: the construction of phylogenetic trees. The use of a maximum likelihood method to construct such trees is based on concrete models of evolutional processes and is well-motivated statistically. However, the use of maximum likelihood methods has been hindered by the computational cost to calculate the likelihood of possible alternative trees (i.e. their confidence scores) at each search step for the optimal tree. To cope with this problem, we used OR-parallel Prolog as a “coordination language” to orchestrate the search for the optimal tree. A numerical computation written in C computed the likelihood of each alternative tree and a symbolic computation written in Prolog performed a parallel A* tree search. For constructing phylogenetic trees of bacterial organisms, our parallel algorithm allowed us to increase the size of the search space, allowing us to include nearly optimal as well as optimal intermediate trees in the search. Our priority mechanism reduced the generation of useless tasks and resulted in superlinear speedups in some cases.

Scheduling speculative work in MUSE and performance results

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.

Performance of Muse on switch-based multiprocessor machines

The Muse (multiple sequential Prolog engines) approach has been used to make a simple and efficient OR-parallel implementation of the full Prolog language. The performance results of the Muse system on bus-based multiprocessor machines have been presented in previous chapters, papers. This chapter paper discusses the implementation and performance results of the Muse system on switch-based multiprocessors (the BBN Butterfly GP1000 and TC2000). The results of Muse execution show that high real speedups can be achieved for Prolog programs that exhibit coarse-grained parallelism. The scheduling overhead is equivalent to around 8 -- 26 Prolog procedure calls per task on the TC2000. The chapter paper also compares the Muse results with corresponding results for the Aurora OR-parallel Prolog system. For a large set of benchmarks, the results are in favor of the Muse system.

Scheduling in or-parallel Prolog systems: Survey and open problems

Implementation of or-parallel Prolog systems offers a number of interesting scheduling problems. The main issues are the interaction between memory models and scheduling, ordering of multiple solutions, and scheduling of speculative work. The problems occur partly because of the design choices (e.g. the choice of a memory model), and partly because of the desire to maintain observational equivalence between parallel and sequential implementations of Prolog, while achieving high efficiency. In the first part of this paper a common framework for discussing scheduling in or-parallel systems is introduced, and also a collection of issues that must be addressed in such systems is presented. In the second part of the paper we survey a number of solutions to these problems comparing their efficiency whenever possible. We close the survey with a short discussion of open problems.

Comparing two parallel logic-programming architectures

The performances of two parallel logic-programming architectures, an OR-parallel Prolog system and an AND-parallel flat-guarded-Horn-clause system (FGHC), are compared. A description is given of how fast algorithms are developed on both OR-parallel and AND-parallel programming paradigms, as well as in both uncommitted-choice and committed-choice languages. To compare the systems, seven algorithms for solving the N-queens problem were executed, and their performances were measured on a Sequent Symmetry under the Aurora and KLIPS architectures. >