Programming the Connection Machine by Using the Metaobject

Total Page:16

File Type:pdf, Size:1020Kb

Programming the Connection Machine by Using the Metaobject Programming the Connection Machine by using the Metaob ject Proto col Lothar Hotz Gerd Kamp Universitat Hamburg Fachb ereich Informatik Bo denstedtstrasse Hamburg Germany email hotzinformatikunihamburgde In this pap er we demonstrate how the Metaob ject Proto col of the Common Lisp Ob ject System can b e used to program the Connection Machine In this approach metaob ject classes which are resp onsible for internal representations of instances map instances to pro cessors in various ways With these classes parallel structures are implemented to form a language which allows an easy usage of a parallel machine INTRODUCTION A widely used approach to join ob jectoriented OO programming and parallel com puters consists in identifying an ob ject as a main source of parallelism or concurrency Ob jects or actors guardians communicate by messaging ie sending messages to each other Such active ob jects may run concurrently if they reside on dierent pro cessors Examples for systems following this approach are describ ed in Besides ob jects and messages OO programming supplies additional features that may b e used for program ming parallel computers These features eg found in the Common Lisp Ob ject System CLOS are generic functions multiple inheritance metho d combination and the metaob ject proto col In this pap er we showhow CLOS can b e used to program massively parallel computers MPCs esp ecially the Connection Machine CM Our goal is to hide anykindof explicit parallel syntax to the user by extending an already wellknown language with less change of its syntax If we can dene a set of appropriate data structures whose op erations are internally parallelized and whose userinterface is within the scop e of the language the user is not puzzled ab out explicitly thinking or programming in parallel terms These data structures are manifested in a set of large ie numerous elements complex structures such as matrices lists sets relations and graphs with appropriate op erations on them us our goal is to design eg multiplication graph traversion transitivehull union Th a language of complex data structures called DisGraL distributed graph language and join these structures that are problemoriented machineindep endent commonly usable and parallelizable with appropriate op erations In a rst approach we concentrate on data parallel machines like the CM b ecause they have a nature dierent from controloriented languages detailed knowledge of the machines architecture are necessary to program them Thus complex structures and their op erations are realized by data parallel algorithms The interface b etween such abstract data structures and their data parallel realization is implemented via the metaob ject proto col This is a way to op en languages up allowing users to adjust the design and implementation of a programming language to suit their particular needs In particular in a subset of CLOS is dened and extended with facets dynamic slots etc by using the metaob ject proto col of CLOS MOP In a similar waywe extend PCL Portable CommonLo ops a p ortable version of CLOS to supply data mappings to the CM ie known distributions of ob jects eg are supp orted by our extensions Thus we showhow the MOP can b e used to implementaninterface b etween CLOS and the CM This interface is given by language features which smo othly t in the syntax of CLOS Thus no additional explizit parallel constructs must b e known to a user of these extensions In this sense the pap er describ es how to bridge the gap between low level machinedep endent more or less ecient parallel algorithms and high level abstract applications We are not concerned with improving sp ecic algorithms or solving a sp ecic problem on a parallel machine in an ecientway Thus neither eciency results are presented nor parallel algorithms are describ ed However we assume that there exist ecient parallel algorithms and that there are applications that should b e solved with parallel machines We rst give a short overview of terms used Section After a short description of levels of abstraction for a more detailed view of them we refer to we present the develop ed metaob ject classes for handling massively parallel constructs These classes are used to implement complex structures as describ ed and illustrated with a short example in Section Finally in Section we discuss some other approaches THE CM OO PROGRAMMING AND THE MOP ely parallel single instruction multiple data The connection machine CM is a massiv SIMD computer consisting of up to K pro cessors To the user the parallel pro cessing unit app ears as an extension of the normal environment of a standard sequential computer such as a Sun Lisp is a data parallel extension of Common Lisp for the CM The data parallel extensions of Lisp include a large numb er of functions and macros and one imp ortant abstraction the parallel variable or pvar A pvar is a variable that has a separate value for each pro cessor in the CM Besides widely used OO features like classes slots data elds of classes inheritance and instances the data stores of slot values of a sp ecic class we fo cus on metaob ject classes and proto cols Classes whichcontrol representation of instances of classes are called metaob ject classes With them a programmer gets access to the internal repre sentation of language constructs The sp ecication of interacting ob jects is manifested in a collection of generic functions called proto col Proto cols are sp ecializable mo diable interfaces b etween ob jects CLOS is implemented in CLOS ie all features of CLOS eg classes generic functions are represented as instances of predened classes named standard metaob ject classes These instances are called metaob jects The b ehavior of these metaob jects and thus of CLOS is describ ed with proto cols These proto cols describ e sp ecic p oints of the CLOS implementation to b e changed by a programmer For example the instance allo cation proto col sp ecies that al locateinstance is called when an instance is allo cated Because these functions are generic functions they can b e sp e cialized as in an ordinary OO program The language implementation itself is structured as an OO program Thus extensions can b e made by sub classing standard metaob ject classes to sp ecialized metaob ject classes These classes extend or override predened language b ehavior eg to access a pro cessor element and not an element of an array when a slot value is refered to In Section we describ e the mo dication of the instance allo cation proto col Changing the implementation of a programming language mightlook ugly and susp ect but it is not when doing it in a p ortable way Because the proto cols are summarized in the quasi standard of the MOP see all implementations of CLOS using it will understand changes of CLOS To the user programmer of a such mo died CLOS the extensions are part of the language and clearly integrated in the syntax and semantics of the language LEVELS OF ABSTRACTION To clarify our view of parallel languages we describ e levels of abstraction and languages see also The usefulness of separating lowlevel parallel constructs from high level problem oriented constructs is also discussed in other pap ers like We extend Lisp with PCL to get an OO interface to the data parallel CM Furthermore we de ne classes and metaob ject classes to map data to parallel machines This level is called CLOS With this extension classes and op erations for regular structures like vector ma trix set and irregular structures are dened Irregular structures suchas relation graph tree and list change dynamically and are not constant in size or are arbitrarily distributed Thus it is not p ossible to map these structures onetoone to regular internal constructs However it is p ossible to implementsuch structures on the CM Op erations on irregular structures are dened on the entire structure not on single ob jects Our approachintegrates these structures and op erations in a set of classes and metho ds that aL The main issue with DisGraL is the need to dene problems in terms is called DisGr of complex structures and op erations ie the programmer do es not think in parallel or sequential structures but in complex ones DisGraL is the basis for a to ol for implement ing various Articial Intelligence AI applications such as vision neural nets and the selection problem on parallel computers In Section wegive one example which gives a short insight of the to ol CLASSES AND METAOBJECT CLASSES FOR THE CM In this section we present one class and three sp ecialized metaob ject classes one of them is used to implement the complex structure relationclass see Section These classes describ e distinct mappings of instances ie data holding structures of OO lan guages to pro cessors reecting our data parallel approach They are part of CLOS As mentioned ab ove the instance allo cation proto col is sp ecialized by these classes The standard proto col sp ecies that al locateinstance results in an array for storing slot values By indicating slots to b e not CLOS slots but parallel ones the standard proto col do es no longer allo cate storage on the sequential machine Instead storage is allo cated on the CM by a sp ecialized metho d for al locateinstancewhich uses LISP functions The distribution can b e done in various ways dep ending on the desired data distribution pvarp erinstanceclass This class is an ordinary CLOS class Each instance of this class represents one pvar The pvar is allo cated during initialization of a new in a) pvar-per-instance-classb)
Recommended publications
  • Application of TRIE Data Structure and Corresponding Associative Algorithms for Process Optimization in GRID Environment
    Application of TRIE data structure and corresponding associative algorithms for process optimization in GRID environment V. V. Kashanskya, I. L. Kaftannikovb South Ural State University (National Research University), 76, Lenin prospekt, Chelyabinsk, 454080, Russia E-mail: a [email protected], b [email protected] Growing interest around different BOINC powered projects made volunteer GRID model widely used last years, arranging lots of computational resources in different environments. There are many revealed problems of Big Data and horizontally scalable multiuser systems. This paper provides an analysis of TRIE data structure and possibilities of its application in contemporary volunteer GRID networks, including routing (L3 OSI) and spe- cialized key-value storage engine (L7 OSI). The main goal is to show how TRIE mechanisms can influence de- livery process of the corresponding GRID environment resources and services at different layers of networking abstraction. The relevance of the optimization topic is ensured by the fact that with increasing data flow intensi- ty, the latency of the various linear algorithm based subsystems as well increases. This leads to the general ef- fects, such as unacceptably high transmission time and processing instability. Logically paper can be divided into three parts with summary. The first part provides definition of TRIE and asymptotic estimates of corresponding algorithms (searching, deletion, insertion). The second part is devoted to the problem of routing time reduction by applying TRIE data structure. In particular, we analyze Cisco IOS switching services based on Bitwise TRIE and 256 way TRIE data structures. The third part contains general BOINC architecture review and recommenda- tions for highly-loaded projects.
    [Show full text]
  • Metaobject Protocols: Why We Want Them and What Else They Can Do
    Metaobject protocols: Why we want them and what else they can do Gregor Kiczales, J.Michael Ashley, Luis Rodriguez, Amin Vahdat, and Daniel G. Bobrow Published in A. Paepcke, editor, Object-Oriented Programming: The CLOS Perspective, pages 101 ¾ 118. The MIT Press, Cambridge, MA, 1993. © Massachusetts Institute of Technology All rights reserved. No part of this book may be reproduced in any form by any electronic or mechanical means (including photocopying, recording, or information storage and retrieval) without permission in writing from the publisher. Metaob ject Proto cols WhyWeWant Them and What Else They Can Do App ears in Object OrientedProgramming: The CLOS Perspective c Copyright 1993 MIT Press Gregor Kiczales, J. Michael Ashley, Luis Ro driguez, Amin Vahdat and Daniel G. Bobrow Original ly conceivedasaneat idea that could help solve problems in the design and implementation of CLOS, the metaobject protocol framework now appears to have applicability to a wide range of problems that come up in high-level languages. This chapter sketches this wider potential, by drawing an analogy to ordinary language design, by presenting some early design principles, and by presenting an overview of three new metaobject protcols we have designed that, respectively, control the semantics of Scheme, the compilation of Scheme, and the static paral lelization of Scheme programs. Intro duction The CLOS Metaob ject Proto col MOP was motivated by the tension b etween, what at the time, seemed liketwo con icting desires. The rst was to have a relatively small but p owerful language for doing ob ject-oriented programming in Lisp. The second was to satisfy what seemed to b e a large numb er of user demands, including: compatibility with previous languages, p erformance compara- ble to or b etter than previous implementations and extensibility to allow further exp erimentation with ob ject-oriented concepts see Chapter 2 for examples of directions in which ob ject-oriented techniques might b e pushed.
    [Show full text]
  • C Programming: Data Structures and Algorithms
    C Programming: Data Structures and Algorithms An introduction to elementary programming concepts in C Jack Straub, Instructor Version 2.07 DRAFT C Programming: Data Structures and Algorithms, Version 2.07 DRAFT C Programming: Data Structures and Algorithms Version 2.07 DRAFT Copyright © 1996 through 2006 by Jack Straub ii 08/12/08 C Programming: Data Structures and Algorithms, Version 2.07 DRAFT Table of Contents COURSE OVERVIEW ........................................................................................ IX 1. BASICS.................................................................................................... 13 1.1 Objectives ...................................................................................................................................... 13 1.2 Typedef .......................................................................................................................................... 13 1.2.1 Typedef and Portability ............................................................................................................. 13 1.2.2 Typedef and Structures .............................................................................................................. 14 1.2.3 Typedef and Functions .............................................................................................................. 14 1.3 Pointers and Arrays ..................................................................................................................... 16 1.4 Dynamic Memory Allocation .....................................................................................................
    [Show full text]
  • Abstract Data Types
    Chapter 2 Abstract Data Types The second idea at the core of computer science, along with algorithms, is data. In a modern computer, data consists fundamentally of binary bits, but meaningful data is organized into primitive data types such as integer, real, and boolean and into more complex data structures such as arrays and binary trees. These data types and data structures always come along with associated operations that can be done on the data. For example, the 32-bit int data type is defined both by the fact that a value of type int consists of 32 binary bits but also by the fact that two int values can be added, subtracted, multiplied, compared, and so on. An array is defined both by the fact that it is a sequence of data items of the same basic type, but also by the fact that it is possible to directly access each of the positions in the list based on its numerical index. So the idea of a data type includes a specification of the possible values of that type together with the operations that can be performed on those values. An algorithm is an abstract idea, and a program is an implementation of an algorithm. Similarly, it is useful to be able to work with the abstract idea behind a data type or data structure, without getting bogged down in the implementation details. The abstraction in this case is called an \abstract data type." An abstract data type specifies the values of the type, but not how those values are represented as collections of bits, and it specifies operations on those values in terms of their inputs, outputs, and effects rather than as particular algorithms or program code.
    [Show full text]
  • Common Lisp Object System Specification 3. Metaobject Protocol
    Common Lisp Object System Specification 3. Metaobject Protocol This document was written by Daniel G. Bobrow, Linda G. DeMichiel, Richard P. Gabriel, Sonya E. Keene, Gregor Kiczales, and David A. Moon. Contributors to this document include Patrick Dussud, Kenneth Kahn, Jim Kempf, Larry Masinter, Mark Stefik, Daniel L. Weinreb, and Jon L White. CONTENTS CONTENTS ................................................... ............ 3–2 Status of Document ................................................... ........... 3–5 Terminology ................................................... ................ 3–6 Introduction ................................................... ................ 3–7 Class Organization in the CLOS Kernel ............................................... 3–9 The Classes in the CLOS Kernel ................................................... 3–10 standard-class ................................................... ............ 3–11 forward-referenced-class ................................................... ..... 3–11 built-in-class ................................................... ............. 3–11 structure-class ................................................... ............ 3–12 funcallable-standard-class ................................................... .... 3–12 standard-slot-description ................................................... .... 3–12 standard-class-slot-description ................................................... 3–12 standard-method ................................................... .......... 3–12
    [Show full text]
  • Data Structures, Buffers, and Interprocess Communication
    Data Structures, Buffers, and Interprocess Communication We’ve looked at several examples of interprocess communication involving the transfer of data from one process to another process. We know of three mechanisms that can be used for this transfer: - Files - Shared Memory - Message Passing The act of transferring data involves one process writing or sending a buffer, and another reading or receiving a buffer. Most of you seem to be getting the basic idea of sending and receiving data for IPC… it’s a lot like reading and writing to a file or stdin and stdout. What seems to be a little confusing though is HOW that data gets copied to a buffer for transmission, and HOW data gets copied out of a buffer after transmission. First… let’s look at a piece of data. typedef struct { char ticker[TICKER_SIZE]; double price; } item; . item next; . The data we want to focus on is “next”. “next” is an object of type “item”. “next” occupies memory in the process. What we’d like to do is send “next” from processA to processB via some kind of IPC. IPC Using File Streams If we were going to use good old C++ filestreams as the IPC mechanism, our code would look something like this to write the file: // processA is the sender… ofstream out; out.open(“myipcfile”); item next; strcpy(next.ticker,”ABC”); next.price = 55; out << next.ticker << “ “ << next.price << endl; out.close(); Notice that we didn’t do this: out << next << endl; Why? Because the “<<” operator doesn’t know what to do with an object of type “item”.
    [Show full text]
  • Subtyping Recursive Types
    ACM Transactions on Programming Languages and Systems, 15(4), pp. 575-631, 1993. Subtyping Recursive Types Roberto M. Amadio1 Luca Cardelli CNRS-CRIN, Nancy DEC, Systems Research Center Abstract We investigate the interactions of subtyping and recursive types, in a simply typed λ-calculus. The two fundamental questions here are whether two (recursive) types are in the subtype relation, and whether a term has a type. To address the first question, we relate various definitions of type equivalence and subtyping that are induced by a model, an ordering on infinite trees, an algorithm, and a set of type rules. We show soundness and completeness between the rules, the algorithm, and the tree semantics. We also prove soundness and a restricted form of completeness for the model. To address the second question, we show that to every pair of types in the subtype relation we can associate a term whose denotation is the uniquely determined coercion map between the two types. Moreover, we derive an algorithm that, when given a term with implicit coercions, can infer its least type whenever possible. 1This author's work has been supported in part by Digital Equipment Corporation and in part by the Stanford-CNR Collaboration Project. Page 1 Contents 1. Introduction 1.1 Types 1.2 Subtypes 1.3 Equality of Recursive Types 1.4 Subtyping of Recursive Types 1.5 Algorithm outline 1.6 Formal development 2. A Simply Typed λ-calculus with Recursive Types 2.1 Types 2.2 Terms 2.3 Equations 3. Tree Ordering 3.1 Subtyping Non-recursive Types 3.2 Folding and Unfolding 3.3 Tree Expansion 3.4 Finite Approximations 4.
    [Show full text]
  • Balancing the Eulisp Metaobject Protocol
    Balancing the EuLisp Metaob ject Proto col x y x z Harry Bretthauer and Harley Davis and Jurgen Kopp and Keith Playford x German National Research Center for Computer Science GMD PO Box W Sankt Augustin FRG y ILOG SA avenue Gallieni Gentilly France z Department of Mathematical Sciences University of Bath Bath BA AY UK techniques which can b e used to solve them Op en questions Abstract and unsolved problems are presented to direct future work The challenge for the metaob ject proto col designer is to bal One of the main problems is to nd a b etter balance ance the conicting demands of eciency simplicity and b etween expressiveness and ease of use on the one hand extensibili ty It is imp ossible to know all desired extensions and eciency on the other in advance some of them will require greater functionality Since the authors of this pap er and other memb ers while others require greater eciency In addition the pro of the EuLisp committee have b een engaged in the design to col itself must b e suciently simple that it can b e fully and implementation of an ob ject system with a metaob ject do cumented and understo o d by those who need to use it proto col for EuLisp Padget and Nuyens intended This pap er presents a metaob ject proto col for EuLisp to correct some of the p erceived aws in CLOS to sim which provides expressiveness by a multileveled proto col plify it without losing any of its p ower and to provide the and achieves eciency by static semantics for predened means to more easily implement it eciently The current metaob
    [Show full text]
  • 4 Hash Tables and Associative Arrays
    4 FREE Hash Tables and Associative Arrays If you want to get a book from the central library of the University of Karlsruhe, you have to order the book in advance. The library personnel fetch the book from the stacks and deliver it to a room with 100 shelves. You find your book on a shelf numbered with the last two digits of your library card. Why the last digits and not the leading digits? Probably because this distributes the books more evenly among the shelves. The library cards are numbered consecutively as students sign up, and the University of Karlsruhe was founded in 1825. Therefore, the students enrolled at the same time are likely to have the same leading digits in their card number, and only a few shelves would be in use if the leadingCOPY digits were used. The subject of this chapter is the robust and efficient implementation of the above “delivery shelf data structure”. In computer science, this data structure is known as a hash1 table. Hash tables are one implementation of associative arrays, or dictio- naries. The other implementation is the tree data structures which we shall study in Chap. 7. An associative array is an array with a potentially infinite or at least very large index set, out of which only a small number of indices are actually in use. For example, the potential indices may be all strings, and the indices in use may be all identifiers used in a particular C++ program.Or the potential indices may be all ways of placing chess pieces on a chess board, and the indices in use may be the place- ments required in the analysis of a particular game.
    [Show full text]
  • CSE 307: Principles of Programming Languages Classes and Inheritance
    OOP Introduction Type & Subtype Inheritance Overloading and Overriding CSE 307: Principles of Programming Languages Classes and Inheritance R. Sekar 1 / 52 OOP Introduction Type & Subtype Inheritance Overloading and Overriding Topics 1. OOP Introduction 3. Inheritance 2. Type & Subtype 4. Overloading and Overriding 2 / 52 OOP Introduction Type & Subtype Inheritance Overloading and Overriding Section 1 OOP Introduction 3 / 52 OOP Introduction Type & Subtype Inheritance Overloading and Overriding OOP (Object Oriented Programming) So far the languages that we encountered treat data and computation separately. In OOP, the data and computation are combined into an “object”. 4 / 52 OOP Introduction Type & Subtype Inheritance Overloading and Overriding Benefits of OOP more convenient: collects related information together, rather than distributing it. Example: C++ iostream class collects all I/O related operations together into one central place. Contrast with C I/O library, which consists of many distinct functions such as getchar, printf, scanf, sscanf, etc. centralizes and regulates access to data. If there is an error that corrupts object data, we need to look for the error only within its class Contrast with C programs, where access/modification code is distributed throughout the program 5 / 52 OOP Introduction Type & Subtype Inheritance Overloading and Overriding Benefits of OOP (Continued) Promotes reuse. by separating interface from implementation. We can replace the implementation of an object without changing client code. Contrast with C, where the implementation of a data structure such as a linked list is integrated into the client code by permitting extension of new objects via inheritance. Inheritance allows a new class to reuse the features of an existing class.
    [Show full text]
  • Data Structures Using “C”
    DATA STRUCTURES USING “C” DATA STRUCTURES USING “C” LECTURE NOTES Prepared by Dr. Subasish Mohapatra Department of Computer Science and Application College of Engineering and Technology, Bhubaneswar Biju Patnaik University of Technology, Odisha SYLLABUS BE 2106 DATA STRUCTURE (3-0-0) Module – I Introduction to data structures: storage structure for arrays, sparse matrices, Stacks and Queues: representation and application. Linked lists: Single linked lists, linked list representation of stacks and Queues. Operations on polynomials, Double linked list, circular list. Module – II Dynamic storage management-garbage collection and compaction, infix to post fix conversion, postfix expression evaluation. Trees: Tree terminology, Binary tree, Binary search tree, General tree, B+ tree, AVL Tree, Complete Binary Tree representation, Tree traversals, operation on Binary tree-expression Manipulation. Module –III Graphs: Graph terminology, Representation of graphs, path matrix, BFS (breadth first search), DFS (depth first search), topological sorting, Warshall’s algorithm (shortest path algorithm.) Sorting and Searching techniques – Bubble sort, selection sort, Insertion sort, Quick sort, merge sort, Heap sort, Radix sort. Linear and binary search methods, Hashing techniques and hash functions. Text Books: 1. Gilberg and Forouzan: “Data Structure- A Pseudo code approach with C” by Thomson publication 2. “Data structure in C” by Tanenbaum, PHI publication / Pearson publication. 3. Pai: ”Data Structures & Algorithms; Concepts, Techniques & Algorithms
    [Show full text]
  • 1 Abstract Data Types, Cost Specifications, and Data Structures
    Parallel and Sequential Data Structures and Algorithms — Lecture 5 15-210 (Fall 2012) Lecture 5 — Data Abstraction and Sequences I Parallel and Sequential Data Structures and Algorithms, 15-210 (Fall 2012) Lectured by Guy Blelloch — 11 Septermber 2012 Material in this lecture: - Relationship between ADTs, cost specifications and data structures. - The sequence ADT - The scan operation: examples and implementation - Using contraction : an algorithmic technique 1 Abstract Data Types, Cost Specifications, and Data Structures So far in class we have defined several “problems” and discussed algorithms for solving them. The idea is that the problem is an abstract definition of what we want in terms of a function specification, and the algorithms are particular ways to solve/implement the problem. In addition to abstract functions we also often need to define abstractions over data. In such an abstraction we define a set of functions (abstractly) over a common data type. As mentioned in the first lecture, we will refer to the abstractions as abstract data types and their implementations as data structures. An example of an abstract data type, or ADT, you should have seen before is a priority queue. Let’s consider a slight extension where in addition to insert, and deleteMin, we will add a function that joins two priority queues into a single one. For historical reasons, we will call such a join a meld, and the ADT a "meldable priority queue". As with a problem, we like to have a formal definition of the abstract data type. Definition 1.1. Given a totally
    [Show full text]