DOCSLIB.ORG

Graph Reduction Without Pointers

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Graph Reduction Without Pointers Graph Reduction Without Pointers TR89-045 December, 1989 William Daniel Partain The University of North Carolina at Chapel Hill Department of Computer Science ! I CB#3175, Sitterson Hall Chapel Hill, NC 27599-3175 UNC is an Equal Opportunity/Aflirmative Action Institution. Graph Reduction Without Pointers by William Daniel Partain A dissertation submitted to the faculty of the University of North Carolina at Chapel Hill in partial fulfillment of the requirements for the degree of Doctor of Philosophy in the Department of Computer Science. Chapel Hill, 1989 Approved by: Jfn F. Prins, reader ~ ~<---(­ CJ)~ ~ ;=tfJ\ Donald F. Stanat, reader @1989 William D. Partain ALL RIGHTS RESERVED II WILLIAM DANIEL PARTAIN. Graph Reduction Without Pointers (Under the direction of Gyula A. Mag6.) Abstract Graph reduction is one way to overcome the exponential space blow-ups that simple normal-order evaluation of the lambda-calculus is likely to suf­ fer. The lambda-calculus underlies lazy functional programming languages, which offer hope for improved programmer productivity based on stronger mathematical underpinnings. Because functional languages seem well-suited to highly-parallel machine implementations, graph reduction is often chosen as the basis for these machines' designs. Inherent to graph reduction is a commonly-accessible store holding nodes referenced through "pointers," unique global identifiers; graph operations cannot guarantee that nodes directly connected in the graph will be in nearby store locations. This absence of locality is inimical to parallel computers, which prefer isolated pieces of hardware working on self-contained parts of a program. In this dissertation, I develop an alternate reduction system using "sus­ pensions" (delayed substitutions), with terms represented as trees and vari­ ables by their binding indices (de Bruijn numbers). Global pointers do not exist and all operations, except searching for redexes, are entirely local. The system is provably equivalent to graph reduction, step for step. I show that . if this kind of interpreter is implemented on a highly-parallel machine with a locality-preserving, linear program representation and fast scan primitives (an FFP Machine is an appropriate architecture) then the interpreter's worst­ case space complexity is the same as that of a graph reducer (that is, equiv­ alent sharing), and its time complexity falls short on only one unimportant case. On the other side of the ledger, graph operations that involve chaining through many pointers are often replaced with a single associative-matching operation. What is more, this system has no difficulty with free variables in redexes and is good for reduction to full beta-normal form. These results suggest that non-naive tree reduction is an approach to supporting functional programming that a parallel-computer architect should not overlook. 111 Preliminaries Programming language. I support some of my descriptions by show­ ing an implementation encoded in Standard ML, set in a sans serif font. Appendix A is a reader's introduction to ML and defines the supporting routines for the programs in the dissertation proper. I chose ML because the compiler from Bell Laboratories [8] was the best-implemented functional language available to me. The code shown is directly extracted from working programs. A stylistic matter. I veer from the usual habit of calling myself "we," siding with E. B. White: It is almost impossible to write anything decent using the editorial "we," unless you are the Dionne family. Anonymity, plus the "we," gives a writer a cloak of dishonesty, and he finds himself going around, like a masked reveler at a ball, kissing all the pretty girls [84, page 121]. Acknowledgments. I am not sure how I got into the Ph.D. business, but I know how I got through it. The Team Mag6 members have been the best of colleagues, notably David Middleton, initiator into the Mysteries, Edoardo Biagioni, with his startling imagination, and Bruce Smith, with his breadth of understanding and good sense. Charles Molnar and his group added more than a little spice through their collaboration with us. Vern Chi and the Microelectronics Systems Lab have provided superb computing facilities, even if I was mainly an intruder. "Net people" provided many small helps and assurances; Paul Watson went beyond the call duty by sending a copy of his hard-to-get thesis. Bharat J ayaraman and Rick Snodgrass, former committee members, read drafts even after they had decided to leave; that is conscientiousness! Gyiirgy Revesz provided a needed boost during his visit from the T. J. Watson Research Center. As for sanity, my family and friends have served admirably as bouncers for Dorothea Dix hospital, including my IV father who has hounded me mercilessly about finishing and my mother who made a point not to. Ed McKenzie was as good a lunch crony as one could hope to find, but I will never forgive him for completing his degree in only four years. Phil and Paige LeMasters failed to disguise their deliberate effort to keep me in contact with the world outside Sitterson Hall. My noble and ennobling committee-Gyula Mag6, David Plaisted, Jan Prins, Don Stanat and Jennifer Welch-have bravely weathered the drafts from room 327 and have vastly improved my material. Prof. Stanat lured me into the Department and has stood behind his mistakes, even as I flamed the faculty and wrote purple prose into proposals. Prof. Mag6 has enhanced his reputation as the best thesis advisor in the Department, unbuffeted by the fashions of graduate-student whims, tolerant of not-always-serious meet­ ings, readily available for consultation, and incisive (but not opaque) in his critique. I offer my heartfelt thanks to each one. I am grateful to the U. S. Army Research Office which provided financial support for this work through an Army Science and Technology Fellowship (grant number DAAL03-86-G-0050). Comments. I welcome your comments and corrections. My e-mail address is partain©cs. unc. edu, and paper mail will reach me via the Computer Sci­ ence Department, UNC, Sitterson Hall, Chapel Hill, NC 27599-3175. Elec­ tronic comments sent to Prof. Mag6 (mago©cs. unc. edu) will be forwarded to me even after I leave UNC. v Contents 1 The problem 1 1.1 Motivation ....... 1 1. 2 Thesis statement . 9 1.3 Dissertation organization 10 2 The A-calculus 12 2.1 Syntax .............. 13 2.2 Computing with the A-calculus 15 2.3 Other A-calculus reduction rules 16 2.4 !'~-normal form and normal-order reduction 17 2.5 Other normal forms and evaluation orders 18 2.6 The name-free A-calculus ..... 20 2. 7 Combinators . 22 2.8 The practical use of the A-calculus 26 2.9 The necessity of sharing for normal-order evaluation 27 30 3 Graph reduction: the A9 -interpreter 3.1 Graph structure and terminology .. 32 3.2 Finding a redex and j39 -reduction .. 35 3.3 Sharing free expressions and lazy copying 38 3.4 More on variable bindings . 40 3.4.1 Graph reduction with binding indices 40 3.4.2 Wadsworth's use of backpointers .. 42 3.5 Graph-reduction architectures and sharing . 45 3.6 Graph rewriting ............... 51 4 Reduction with suspensions: the As-interpreter 53 4.1 As-term structure and terminology 58 4.2 !'is-reduction: the !'is rule ............. 63 VI 4.3 Searching for the next redex . 66 4.4 Lazy copying of shared rators 75 4.5 Tidying .\,-terms . 76 4.5.1 Removing useless suspensions 79 4.5.2 Removing trivial suspensions 80 4.5.3 Moving .\,-abstractions above suspensions 81 4.5.4 Rotating suspensions . 84 4.5.5 Upward and downward s-connections . 85 4.5.6 Constraints on moving suspensions . 86 4.5. 7 Tidying: definition and important properties 86 4.5.8 The recurring example on the .\,-interpreter . 90 4.6 a-equivalence of .\,-terms . 90 4.7 Equivalence to graph reduction: correctness 92 4.8 Related approaches to A-calculus evaluation . 94 4.8.1 Efforts to find simpler reduction rules 94 4.8.2 Comparison with environment-based evaluation . 97 4.8.3 Environment/reduction hybrids . 100 4.8.4 Pointers versus .\,-pointers . 100 5 The .\,-interpreter on an FFP Machine 102 5.1 Introduction to the FFP Machine . 103 5.1.1 Project history and design goals 103 5.1.2 Basic structure of an FFP Machine . 104 5.1.3 Communication and partitioning . 106 5.1.4 Broadcasting and sorting operations 108 5.1.5 Single-result operations . 109 5.1.6 Scan, or parallel prefix, operations 109 5.1. 7 Computing level numbers . 110 5.1.8 Calculating exotic level numbers 112 5.1.9 Calculating selectors and first/last bits . 113 5.1.10 Low-level programming style in an FFP Machine 114 5.1.11 Copying and sharing in an FFP Machine 115 5.1.12 Related non-graph-reduction architectures . 116 5.2 An implementation of a .\,-interpreter 119 5.2.1 Basic algorithms . 120 5.2.2 Controlling the interpreter . 125 5.2.3 Reducing to $-normal or root-lambda form 126 5.2.4 $,-reduction and local tidying . 130 5.2.5 Nonlocal tidying . 132 Vll 5.2.6 Global checking . 133 5.2. 7 Summary of the FFP Machine implementation 138 5.3 Equivalence to graph reduction: efficiency 140 5.3.1 Space complexity . 141 5.3.2 Time complexity . 142 5.4 Previous FFP Machine implementations of the .\-calculus 151 6 Embellishments 153 6.1 Suspension lists 153 6.2 Dealing with recursion 156 6.3 Exotic suspensions . 157 6.4 More parallelism . 158 6.5 Ordering in As-terms and supercombinators 158 6.6 Speculative copying . 160 6. 7 Going further with binding indices 161 7 Conclusions 163 A Programming with ML 166 A.1 The one-minute ML programmer 166 A.2 Utility functions .
Load more

Recommended publications
  • Benchmarking Implementations of Functional Languages with ‘Pseudoknot’, a Float-Intensive Benchmark
    Zurich Open Repository and Archive University of Zurich Main Library Strickhofstrasse 39 CH-8057 Zurich www.zora.uzh.ch Year: 1996 Benchmarking implementations of functional languages with ‘Pseudoknot’, a float-intensive benchmark Hartel, Pieter H ; Feeley, Marc ; et al Abstract: Over 25 implementations of different functional languages are benchmarked using the same program, a floating-point intensive application taken from molecular biology. The principal aspects studied are compile time and execution time for the various implementations that were benchmarked. An important consideration is how the program can be modified and tuned to obtain maximal performance on each language implementation. With few exceptions, the compilers take a significant amount of time to compile this program, though most compilers were faster than the then current GNU C compiler (GCC version 2.5.8). Compilers that generate C or Lisp are often slower than those that generate native code directly: the cost of compiling the intermediate form is normally a large fraction of the total compilation time. There is no clear distinction between the runtime performance of eager and lazy implementations when appropriate annotations are used: lazy implementations have clearly come of age when it comes to implementing largely strict applications, such as the Pseudoknot program. The speed of C can be approached by some implementations, but to achieve this performance, special measures such as strictness annotations are required by non-strict implementations. The benchmark results have to be interpreted with care. Firstly, a benchmark based on a single program cannot cover a wide spectrum of ‘typical’ applications. Secondly, the compilers vary in the kind and level of optimisations offered, so the effort required to obtain an optimal version of the program is similarly varied.
    [Show full text]
  • A Scheme Foreign Function Interface to Javascript Based on an Infix
    A Scheme Foreign Function Interface to JavaScript Based on an Infix Extension Marc-André Bélanger Marc Feeley Université de Montréal Université de Montréal Montréal, Québec, Canada Montréal, Québec, Canada [email protected] [email protected] ABSTRACT FFIs are notoriously implementation-dependent and code This paper presents a JavaScript Foreign Function Inter- using a given FFI is usually not portable. Consequently, face for a Scheme implementation hosted on JavaScript and the nature of FFI’s reflects a particular set of choices made supporting threads. In order to be as convenient as possible by the language’s implementers. This makes FFIs usually the foreign code is expressed using infix syntax, the type more difficult to learn than the base language, imposing conversions between Scheme and JavaScript are mostly im- implementation constraints to the programmer. In effect, plicit, and calls can both be done from Scheme to JavaScript proficiency in a particular FFI is often not a transferable and the other way around. Our approach takes advantage of skill. JavaScript’s dynamic nature and its support for asynchronous In general FFIs tightly couple the underlying low level functions. This allows concurrent activities to be expressed data representation to the higher level interface provided to in a direct style in Scheme using threads. The paper goes the programmer. This is especially true of FFIs for statically over the design and implementation of our approach in the typed languages such as C, where to construct the proper Gambit Scheme system. Examples are given to illustrate its interface code the FFI must know the type of all data passed use.
    [Show full text]
  • Top-K Entity Resolution with Adaptive Locality-Sensitive Hashing
    Top-K Entity Resolution with Adaptive Locality-Sensitive Hashing Vasilis Verroios Hector Garcia-Molina Stanford University Stanford University [email protected] [email protected] ABSTRACT Given a set of records, entity resolution algorithms find all the records referring to each entity. In this paper, we study Entity 1 the problem of top-k entity resolution: finding all the records Entity 2 referring to the k largest (in terms of records) entities. Top-k Top-k Entity entity resolution is driven by many modern applications that Dataset Filtering Entities’ Records Resolution operate over just the few most popular entities in a dataset. We propose a novel approach, based on locality-sensitive hashing, that can very rapidly and accurately process mas- Entity k sive datasets. Our key insight is to adaptively decide how much processing each record requires to ascertain if it refers to a top-k entity or not: the less likely a record is to refer to Figure 1: Filtering stage in the overall workflow. a top-k entity, the less it is processed. The heavily reduced rest. As we will see, this fact makes it easier to find the top- amount of processing for the vast majority of records that k entities without computing all entities. We next illustrate do not refer to top-k entities, leads to significant speedups. two additional applications where one typically only needs Our experiments with images, web articles, and scientific top-k entities. Incidentally, two of the datasets we use for publications show a 2x to 25x speedup compared to the tra- our experiments are from these applications.
    [Show full text]
  • Solving the Funarg Problem with Static Types IFL ’21, September 01–03, 2021, Online
    Solving the Funarg Problem with Static Types Caleb Helbling Fırat Aksoy [email protected] fi[email protected] Purdue University Istanbul University West Lafayette, Indiana, USA Istanbul, Turkey ABSTRACT downwards. The upwards funarg problem refers to the manage- The difficulty associated with storing closures in a stack-based en- ment of the stack when a function returns another function (that vironment is known as the funarg problem. The funarg problem may potentially have a non-empty closure), whereas the down- was first identified with the development of Lisp in the 1970s and wards funarg problem refers to the management of the stack when hasn’t received much attention since then. The modern solution a function is passed to another function (that may also have a non- taken by most languages is to allocate closures on the heap, or to empty closure). apply static analysis to determine when closures can be stack allo- Solving the upwards funarg problem is considered to be much cated. This is not a problem for most computing systems as there is more difficult than the downwards funarg problem. The downwards an abundance of memory. However, embedded systems often have funarg problem is easily solved by copying the closure’s lexical limited memory resources where heap allocation may cause mem- scope (captured variables) to the top of the program’s stack. For ory fragmentation. We present a simple extension to the prenex the upwards funarg problem, an issue arises with deallocation. A fragment of System F that allows closures to be stack-allocated. returning function may capture local variables, making the size of We demonstrate a concrete implementation of this system in the the closure dynamic.
    [Show full text]
  • The Evolution of Lisp
    1 The Evolution of Lisp Guy L. Steele Jr. Richard P. Gabriel Thinking Machines Corporation Lucid, Inc. 245 First Street 707 Laurel Street Cambridge, Massachusetts 02142 Menlo Park, California 94025 Phone: (617) 234-2860 Phone: (415) 329-8400 FAX: (617) 243-4444 FAX: (415) 329-8480 E-mail: [email protected] E-mail: [email protected] Abstract Lisp is the world’s greatest programming language—or so its proponents think. The structure of Lisp makes it easy to extend the language or even to implement entirely new dialects without starting from scratch. Overall, the evolution of Lisp has been guided more by institutional rivalry, one-upsmanship, and the glee born of technical cleverness that is characteristic of the “hacker culture” than by sober assessments of technical requirements. Nevertheless this process has eventually produced both an industrial- strength programming language, messy but powerful, and a technically pure dialect, small but powerful, that is suitable for use by programming-language theoreticians. We pick up where McCarthy’s paper in the first HOPL conference left off. We trace the development chronologically from the era of the PDP-6, through the heyday of Interlisp and MacLisp, past the ascension and decline of special purpose Lisp machines, to the present era of standardization activities. We then examine the technical evolution of a few representative language features, including both some notable successes and some notable failures, that illuminate design issues that distinguish Lisp from other programming languages. We also discuss the use of Lisp as a laboratory for designing other programming languages. We conclude with some reflections on the forces that have driven the evolution of Lisp.
    [Show full text]
  • Tousimojarad, Ashkan (2016) GPRM: a High Performance Programming Framework for Manycore Processors. Phd Thesis
    Tousimojarad, Ashkan (2016) GPRM: a high performance programming framework for manycore processors. PhD thesis. http://theses.gla.ac.uk/7312/ Copyright and moral rights for this thesis are retained by the author A copy can be downloaded for personal non-commercial research or study This thesis cannot be reproduced or quoted extensively from without first obtaining permission in writing from the Author The content must not be changed in any way or sold commercially in any format or medium without the formal permission of the Author When referring to this work, full bibliographic details including the author, title, awarding institution and date of the thesis must be given Glasgow Theses Service http://theses.gla.ac.uk/ [email protected] GPRM: A HIGH PERFORMANCE PROGRAMMING FRAMEWORK FOR MANYCORE PROCESSORS ASHKAN TOUSIMOJARAD SUBMITTED IN FULFILMENT OF THE REQUIREMENTS FOR THE DEGREE OF Doctor of Philosophy SCHOOL OF COMPUTING SCIENCE COLLEGE OF SCIENCE AND ENGINEERING UNIVERSITY OF GLASGOW NOVEMBER 2015 c ASHKAN TOUSIMOJARAD Abstract Processors with large numbers of cores are becoming commonplace. In order to utilise the available resources in such systems, the programming paradigm has to move towards in- creased parallelism. However, increased parallelism does not necessarily lead to better per- formance. Parallel programming models have to provide not only flexible ways of defining parallel tasks, but also efficient methods to manage the created tasks. Moreover, in a general- purpose system, applications residing in the system compete for the shared resources. Thread and task scheduling in such a multiprogrammed multithreaded environment is a significant challenge. In this thesis, we introduce a new task-based parallel reduction model, called the Glasgow Parallel Reduction Machine (GPRM).
    [Show full text]
  • Chapter 2 Background
    Chapter 2 Background This chapter discusses background information pertinent to the re- search discussed in the remainder of the book. Section 2.1 defines the problem area addressed by the research: combinator graph reduction of lazy functional programs. Section 2.2 discusses previous research on combinator reduction methods of program execution. Section 2.3 out- lines the approach used for research presented in later chapters, focus- ing on the TIGRE abstract machine for combinator graph reduction. 2.1. PROBLEM DEFINITION The problem area of interest is the efficient execution of lazy functional programs using combinator graph reduction. Since this method of program execution is not well known, Appendix A has been provided as a brief tutorial on the main concepts. 2.1.1. Lazy Functional Programming Functional programs are built by pairing expressions into applications. Each expression may be a function or value, and the result of each pairing may also be a function or a value. Functional programming languages may be contrasted with more conventional, imperative, programming languages by the fact that functional programs preserve referential transparency (i.e., expressions have no side effects and depend only on values returned from subexpressions), and hence lack an assignable program state. Lazy functional programming languages are further distinguished from imperative languages by the fact that they employ lazy (or, more precisely, nonstrict) evaluation of parameters by default. Lazy evalua- tion (sometimes called normal order evaluation, although this term does not precisely characterize the notion of lazy evaluation) is a call-by-need para- 5 6 Chapter 2. Background meter passing mechanism in which only a thunk* for an argument is passed to a function when that function is called (Henderson & Morris 1976, Friedman & Wise 1976, Vuilleman 1973).
    [Show full text]
  • Java: Exercises in Style
    Java: Exercises in Style Marco Faella June 1, 2018 i ii This work is licensed under the Creative Commons Attribution- NonCommercial 4.0 International License. To view a copy of this li- cense, visit http://creativecommons.org/licenses/by-nc/4.0/ or send a letter to Creative Commons, PO Box 1866, Mountain View, CA 94042, USA. Author: Marco Faella, [email protected] Preface to the Online Draft This draft is a partial preview of what may eventually become a book. The idea is to share it with the public and obtain feedback to improve its quality. So, if you read the whole draft, or maybe just a chapter, or you just glance over it long enough to spot a typo, let me know! I’m interested in all comments and suggestions for improvement, including (natural) language issues, programming, book structure, etc. I would like to thank all the students who have attended my Programming Languages class, during the past 11 years. They taught me that there is no limit to the number of ways you may think to have solved a Java assignment. Naples, Italy Marco Faella January 2018 iii Contents Contents iv I Preliminaries 1 1 Introduction 3 1.1 Software Qualities . 5 2 Problem Statement 9 2.1 Data Model and Representations . 10 3 Hello World! 13 4 Reference Implementation 17 4.1 Space Complexity . 21 4.2 Time Complexity . 23 II Software Qualities 29 5 Need for Speed 31 5.1 Optimizing “getAmount” and “addWater” . 32 5.2 Optimizing “connectTo” and “addWater” . 34 5.3 The Best Balance: Union-Find Algorithms .
    [Show full text]
  • Part: an Asynchronous Parallel Abstraction for Speculative Pipeline Computations Kiko Fernandez-Reyes, Dave Clarke, Daniel Mccain
    ParT: An Asynchronous Parallel Abstraction for Speculative Pipeline Computations Kiko Fernandez-Reyes, Dave Clarke, Daniel Mccain To cite this version: Kiko Fernandez-Reyes, Dave Clarke, Daniel Mccain. ParT: An Asynchronous Parallel Abstraction for Speculative Pipeline Computations. 18th International Conference on Coordination Languages and Models (COORDINATION), Jun 2016, Heraklion, Greece. pp.101-120, 10.1007/978-3-319-39519- 7_7. hal-01631723 HAL Id: hal-01631723 https://hal.inria.fr/hal-01631723 Submitted on 9 Nov 2017 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Distributed under a Creative Commons Attribution| 4.0 International License ParT: An Asynchronous Parallel Abstraction for Speculative Pipeline Computations? Kiko Fernandez-Reyes, Dave Clarke, and Daniel S. McCain Department of Information Technology Uppsala University, Uppsala, Sweden Abstract. The ubiquity of multicore computers has forced program- ming language designers to rethink how languages express parallelism and concurrency. This has resulted in new language constructs and new com- binations or revisions of existing constructs. In this line, we extended the programming languages Encore (actor-based), and Clojure (functional) with an asynchronous parallel abstraction called ParT, a data structure that can dually be seen as a collection of asynchronous values (integrat- ing with futures) or a handle to a parallel computation, plus a collection of combinators for manipulating the data structure.
    [Show full text]
  • The Butterfly(TM) Lisp System
    From: AAAI-86 Proceedings. Copyright ©1986, AAAI (www.aaai.org). All rights reserved. The Butterfly TMLisp System Seth A. Steinberg Don Allen Laura B agnall Curtis Scott Bolt, Beranek and Newman, Inc. 10 Moulton Street Cambridge, MA 02238 ABSTRACT Under DARPA sponsorship, BBN is developing a parallel symbolic programming environment for the Butterfly, based This paper describes the Common Lisp system that BBN is on an extended version of the Common Lisp language. The developing for its ButterflyTM multiprocessor. The BBN implementation of Butterfly Lisp is derived from C Scheme, ButterflyTM is a shared memory multiprocessor which may written at MIT by members of the Scheme Team.4 The contain up to 256 processor nodes. The system provides a simplicity and power of Scheme make it particularly suitable shared heap, parallel garbage collector, and window based as a testbed for exploring the issues of parallel execution, as I/Osystem. The future constructis used to specify well as a good implementation language for Common Lisp. parallelism. The MIT Multilisp work of Professor Robert Halstead and THE BUTTERFLYTM LISP SYSTEM students has had a significant influence on our approach. For example, the future construct, Butterfly Lisp’s primary For several decades, driven by industrial, military and mechanism for obtaining concurrency, was devised and first experimental demands, numeric algorithms have required implemented by the Multilisp group. Our experience porting increasing quantities of computational power. Symbolic MultiLisp to the Butterfly illuminated many of the problems algorithms were laboratory curiosities; widespread demand of developing a Lisp system that runs efficiently on both for symbolic computing power lagged until recently.
    [Show full text]
  • Parallelism in Lisp
    Parallelism in Lisp Michael van Biema Columbia University Dept. of Computer Science New York, N.Y. 10027 Tel: (212)280-2736 [email protected] three attempts are very interesting, in that two arc very similar Abstract in their approach but very different in the level of their constructs, and the third takes a very different approach. We This paper examines Lisp from the point of view of parallel do not study the so called "pure Lisp" approaches to computation. It attempts to identify exactly where the potential parallelizing Lisp since these are applicative approaches and for parallel execution really exists in LISP and what constructs do not present many of the more complex problems presented are useful in realizing that potential. Case studies of three by a Lisp with side-effects [4, 3]. attempts at augmenting Lisp with parallel constructs are examined and critiqued. The first two attempts concentrate on what we call control parallelism. Control parallelism is viewed here as a medium- or course-grained parallelism on the order of a function call in 1. Parallelism in Lisp Lisp or a procedure call in a traditional, procedure-oriented There are two main approaches to executing Lisp in parallel. language. A good example of this type of parallelism is the One is to use existing code and clever compiling methods to parallel evaluation of all the arguments to a function in Lisp, parallelize the execution of the code [9, 14, 11]. This or the remote procedure call or fork of a process in some approach is very attractive because it allows the use of already procedural language.
    [Show full text]
  • Tamperproofing a Software Watermark by Encoding Constants
    Tamperproofing a Software Watermark by Encoding Constants by Yong He A Thesis Submitted in Partial Fulfilment of the Requirement for the Degree of MASTER OF SCIENCE in Computer Science University of Auckland Copyright © 2002 by Yong He i Abstract Software Watermarking is widely used for software ownership authentication, but it is susceptible to various de-watermarking attacks such as obfuscation. Dynamic Graph Watermarking is a relatively new technology for software watermarking, and is believed the most likely to withstand attacks, which are trying to distort watermark structure. In this thesis, we present a new technology for protecting Dynamic Graph Watermarks. This technology encodes some of the constants, which are found in a software program, into a tree structure that is similar to the watermark, and generates decoding functions to retrieve the value of the constants at program execution time. If the constant tree is modified, the value of some constants will be affected, destroying program correctness. An attacker cannot reliably distinguish the watermark tree from the constant tree, so they must preserve the watermark tree or risk introducing bugs into the program. Constant Encoding technology can be included in Dynamic Graph Watermarking systems as a plug-in module to improve the Dynamic Graph Watermark protection. In this thesis, we present a prototyping program for Constant Encoding technology, which we call the JSafeMark encoder. Besides addressing the issues about Constant Encoding technology, we also discuss the design and implementation of our JSafeMark encoder, and give a practical example to show how this technology can protect Dynamic Graph Watermarking. iii Acknowledgement I would like to thank Professor Clark Thomborson, my supervisor, for his guidance and enthusiasm.
    [Show full text]