After introduction of Prolog programming language, many reseachers concentrated their attention to the possibily of turning sequential Prolog interpreter into parallel once in order to speedup applications.
This is an interesting area because Prolog allow implicit parallelism, so any code annotation are necessary.
Another key-point of this article if the fact that SLD-derivations are not suitable for non-terminating programs (infinite failure) but using another derivation strategy we can assure the termination of a logic program (under certains circumnstances) .
Earlier Prolog engine when compute a predicate just encountered, din’t remember the c.a.s. calculated, and so this is a waste of computer resouce. Tabling is the response to this problem.
The Wam is a data structure (stack) necessary to the evaluation of Prolog programs and is widely used in every Prolog engine..
It can be represented as:
PDL : area used for unification process. Trail : array of address that points to variables memorized into heap or local stack resetted upon backtracking. Stack : containts environments and choice points . Heap : Memorize variables than can’t be stored in the stack. Code area : contains instruction for wam and Prolog compiled code.
In this model, each worker mantains its own copy of the environment in which it can write without causing binding conflicts.
When a variable is bound, the binding is stored in the private environment of the worker doing the binding.
When a idle worker picks work from another worker, it copies all the stacks from the sharing worker. As a consequence, each worker can carry out execution exactly like a sequential system, requiring very little synchronization.
Copying stacks is made efficient using the incremental copying technique.
The idea of incremental copying is
based on the fact that the idle
worker could have already traversed
a part of the seach tree that is
common to the sharing worker, and
thus it does not need to copy this
part of stacks.
N2 N5 N3 N4 N1 Q P Node without alternatives Node with alternatives Alt 1 Alt 2 Alt 3 Alt 1 Alt 2 Alt 3
Or-Parallelism within Tabling (OPT) is the model introduced by the autors that allow concurrent execution of all available alternatives.
This model is formed by a set of indipendent tabling engine that may share different common branches of the search tree during execution. So, each worker can be considered a sequential tabling engine that fully implement the tabling operations above mentioned.
The or-parallel component is triggered to allow synchronized access to the shared parts of the execution tree, in order to get new job when a worker runs out of alternatives to exploit.
In the OPT model a worker can keep its nodes private until reaching a sharing point. This is a key issue in reducing parallel overhead. They remark that it is common in or-parallel works to say that work is initially private, and that is made public after sharing.
Worker suspension is a common characteristic of Or-P and Tabling. In the former because of side effects, a worker must wait until another worker terminate his job. In the second, arise when a node ask for evaluation of a tabled predicate but in the table this no answer just calculated.
Worker are allowed to concurrently read and update the predicate table. To do so, workers need to be able to lock the table. Finer locking allows more parallelism while coarser locking has less overheads.
Now, we are able to analyze what are the execution times of engines considered above (YapOr, YapTab, OPTYap) with respect to Yap, the sequential engine for Prolog programs and respect XSB system, the well know engine for tabling processing.
First of all, we can see the performance and speedup of non-tabled programs. In this way, they have measured the overhead introduced by the model when running programs that do not take advantage of the particular extension.
In the XSB case, execution times are worst than Yap due to the overhead for managing tabling and or-parallelism (10%, 5%, 17%).
For a complete analysis of performance, they had considered also tabled programs, in order to see if the YapTab engine is good.
Linear speedup are obtained in five of seven programs considered (that represent the usual programs) but in two cases, the sequential version is faster than the parallel. This behaviour is not caused because workers became idle and start seaching for work, as usually happens with parallel execution of non-tabled programs, but there is a lot of the contention to access that work.