Efficient Stream/Array Processing in Logic Programming Languages

Takashi Chikayama

Efficient Stream/Array Processing in Logic Programming Languages

Abstract

The Concurrent Prolog predicate for merging n input streams is investigated, and a compilation technique tor getting its efficient code is presented. Using the. technique, data are transferred with a .delay independent of n. Furthermore, it is shown that the addition and the removal of an input stream can be done within an average time of 0(1). The predicate for distributing data on an input stream to fa output streams can also be. realized as efficiently as n-ary merge. The compilation technique for the distributt predicate can further be applied to the implementation of mutable arrays thaf allow constant-time accessing and updating. Although the efficiency stated above could be achieved by a sOphisticated compiler, the codes should be provided directly by the system to get rid of the bulk ot source programs and the time required to compile them. 1 INTRODUCTION When we implement a large-scale distributed system in a parallel logic programming language such as Concurrent Prolog (Shapiro 1983) and PARLOG (Clark and Gregory 1984), the performance of the system will be influenced significantly by how efficiently streams as. interprocess communication channels can be merged and distributed. This paper deals with implementation techniques of the predicates that merge many input streams and those which distribute data on a single input stream into multiple output streams. The language we chose for the following discussions is Concurrent Prolog. However, the results obtained are applicable also to PARLOG. For readers unfamiliar with Concurrent Prolog, an outline of Concurrent Prolog is described in Appendix I. This paper focuses on implementation on conventional sequential computers. Of course, to demonstrate the viability of Concurrent Prolog on parallel computers, the scope of discussion cannot be limited to sequential computers. However, even on a parallel architecture, it would be very likely for each processor to deal with multiple processes for the following reasons. First, the number of processes a user can create should not be limited to the number of processors available. Second, even if a lot of processors are available, the best way to allocate two processes which communicate intensively with each other

Delta Prolog is a logic programming language extending Prolog with constructs for sequential and parallel composition of goals, interprocess communication and synchronization, and external non-determinism. We present sequential and parallel search strategies for the language, based on the notion of derivations space. They rely upon distributed backtracking, a mechanism supporting the coordinated execution of multiple communicating Delta Prolog processes in their joint search for the solutions to a given problem. Then we describe an execution environment for Delta Prolog based on an abstract machine and discuss implementation issues for distributed memory Transputer-based multiprocessors. 1 INTRODUCTION Delta Prolog (P) is a parallel extension to Prolog inspired by Monteiro's Distributed Logic. The theory of Distributed Logic (Mon83], Mon86]) extends Horn Clause Logic (HCL) with constructs for the speci cation of distributed systems. As a distinctive feature, the P model relies on the programmer to specify the sequentiality constraints and the desirable parallelism existing in each problem, together with the corresponding communication schemes (PP84], PMCA86], PMCA88], CFP89b], CFP89a]). The presentation is organized as follows. In section 2, we discuss the programming model and give an example. A discussion of the P sequential and parallel execution models is made in section 3. Then, in section 4, we discuss implementation issues of the parallel execution models and outline the implementation on a Transputer-based distributed memory multi-computer (Meiko Computing Surface). Finally, in section 5, we present some conclusions and current work. 2 THE PROGRAMMING MODEL In this section we discuss the P language, focusing on the programming model, the language syntax and semantics, and give an example. 2.1 Language constructs A P program is a sequence of clauses of the form: H :-G 1 ;. .. ; G n :(n 0): H is a Prolog goal and each G i may be either a Prolog or a P goal. The latter are either split, event, or choice goals, described below. The comma is the sequential composition operator. Declaratively, the truth of goals in P is time-dependant, so H is true if G 1 ;. .. ; G n are true in succession (see section 2.2 below). Operationally, to solve goal H is to solve successively goals G 1 ;. .. ; G n. An important aspect is that a P program without P goals is a Prolog program, and so P is a true extension to Prolog. 2.1.1 Split goals Split goals are of the form S 1 ==S 2 , where // is a right associative parallel composition operator and S 1 and S 2 are arbitrary P goal expressions. To solve S 1 ==S 2 is to solve S 1 and S 2 within concurrent processes. Declaratively, S 1 // S 2 is true i S 1 and S 2 are jointly true. The abstract execution models for the language do not require that the processes solving these two goals share memory. So if S 1 and S 2 share logical variables, the variables must be uni ed whenever both processes terminate. Failure to unify those variables, failure to solve S 1 or S 2 , or failure of a subsequent goal and backtracking into the split goal, trigger distributed backtracking. Distributed backtracking extends the backtrack-based strategy of sequential Prolog systems as required to deal with concurrent processes. 2.1.2 Event goals Event goals are of the form X?E : C or X!E : C, where X is a term (the message), ? and ! are in x binary predicate symbols (the communication modes), E is bound to a Prolog atom (the event name), and C is a goal expression (the event condition), which can not evaluate P goals. Two event goals, e.g. X?E : C and X!E : C, are complementary i they have the same event name, and di erent communication modes (i.e. one of type ? and the other of type !). If C and D are the atom true, we write X?E and X!E. The two event goals execute successfully i X and Y unify and the conditions C and D evaluate to true. An event is the outcome of the successful resolution of a pair of complementary event goals. An event goal can only be said to be true when it has been successfully solved with its complementary goal. Thus the declarative semantics of P states that a goal is true for some combinations of sequences of events. An event goal, like X?E : C, suspends until a complementary event goal, like Y !E : D, is available in a concurrent process. When they are simultaneously available, their joint resolution may be intrepreted as a two-way exchange of messages followed by uni cation of X and Y and evaluation of conditions C and D. This form of rendezvous mechanism is a generalization of Hoare's and Milner's synchronous communication (Hoa85], Mil80]) as it takes advantage of term uni cation for exchanging messages. The only signi cance of the communication modes ! and ? is that they are complementary in the

Log In

Efficient Stream/Array Processing in Logic Programming Languages

Sign up for access to the world's latest research

Abstract

Related papers

Related topics