Results 1 - 10
of
14
Separation Constraint Partitioning - A New Algorithm for Partitioning Non-strict Programs into Sequential Threads
- In Conference Record of the 22nd ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages
, 1995
"... In this paper we present substantially improved thread partitioning algorithms for modern implicitly parallel languages. We present a new block partitioning algorithm, separation constraint partitioning, which is both more powerful and more flexible than previous algorithms. Our algorithm is guarant ..."
Abstract
-
Cited by 19 (1 self)
- Add to MetaCart
In this paper we present substantially improved thread partitioning algorithms for modern implicitly parallel languages. We present a new block partitioning algorithm, separation constraint partitioning, which is both more powerful and more flexible than previous algorithms. Our algorithm is guaranteed to derive maximal threads. We present a theoretical framework for proving the correctness of our partitioning approach, and we show how separation constraint partitioning makes interprocedural partitioning viable. We have implemented the partitioning algorithms in an Id90 compiler for workstations and parallel machines. Using this experimental platform, we quantify the effectiveness of different partitioning schemes on whole applications. 1 Introduction Modern implicitly parallel languages, such as the functional language Id90, allow the elegant formulation of a broad class of problems while exposing substantial parallelism. However, their non-strict semantics require fine-grain dynami...
Order-of-evaluation Analysis for Destructive Updates in Strict Functional Languages with Flat Aggregates
- In Conference on Functional Programming Languages and Computer Architecture
, 1993
"... The aggregate update problem in functional languages is concerned with detecting cases where a functional array update operation can be implemented destructively in constant time. Previous work on this problem has assumed a fixed order of evaluation of expressions. In this paper, we devise a simple ..."
Abstract
-
Cited by 19 (1 self)
- Add to MetaCart
The aggregate update problem in functional languages is concerned with detecting cases where a functional array update operation can be implemented destructively in constant time. Previous work on this problem has assumed a fixed order of evaluation of expressions. In this paper, we devise a simple analysis, for strict functional languages with flat aggregates, that derives a good order of evaluation for making the updates destructive. Our work improves Hudak's work [14] on abstract reference counting, which assumes fixed order of evaluation and uses the domain of sticky reference counts. Our abstract reference counting uses a 2-point domain. We show that for programs with no aliasing, our analysis is provably more precise than Hudak's approach (even if the fixed order of evaluation chosen by Hudak happens to be the right order). We also show that our analysis algorithm runs in polynomial time. To the best of our knowledge, no previous work shows polynomial time complexity. We suggest ...
Code optimizations for lazy evaluation
- LISP and Symbolic Computation
, 1988
"... Implementations of lazy evaluation for non-strict functional languages usually involve the notion of a delayed representation of the value of an expression, which we call a thunk. We present several techniques for implementing thunks and formalize a class of optimizations that reduce both the space ..."
Abstract
-
Cited by 15 (0 self)
- Add to MetaCart
Implementations of lazy evaluation for non-strict functional languages usually involve the notion of a delayed representation of the value of an expression, which we call a thunk. We present several techniques for implementing thunks and formalize a class of optimizations that reduce both the space and time overhead of these techniques. The optimizations depend on a compile-time inferencing strategy called path analysis, a generalization of strictness analysis that uncovers order-of-evaluation information. Although the techniques in this paper are focused on the compilation of a non-strict functional language for a conventional architecture, they are directly applicable to most of the virtual machines commonly used for implementing such languages. The same techniques also apply to other forms of delayed evaluation such as futures and promises. 1
Copy elimination in functional languages
- in: POPL ’89: Proceedings of the 16th ACM SIGPLAN-SIGACT symposium on Principles of programming languages
, 1989
"... Copy elimination is an important optimization for compiling functional languages. Copies arise because these languages lack the concepts of state and variable; hence updating an object involves a copy in a naive implementation. Copies are also possible if proper targeting has not been carried out in ..."
Abstract
-
Cited by 15 (0 self)
- Add to MetaCart
Copy elimination is an important optimization for compiling functional languages. Copies arise because these languages lack the concepts of state and variable; hence updating an object involves a copy in a naive implementation. Copies are also possible if proper targeting has not been carried out inside functions and across function calls. Targeting is the proper selection of a storage area for evaluating an expression. By abstracting a collection of functions by a target operator, we compute targets of function bodies that can then be used to define an optimized interpreter to eliminate copies due to updates and copies across function calls. The language we consider is typed lambda calculus with higherorder functions and special constructs for array operations. Our approach can eliminate copies in divide and conquer problems like quicksort and bitonic sort that previous approaches could not handle. We also present some results of implementing a compiler for a single assignment language called SAL on some small but tough programs. Our results indicate that it is possible to approach a performance comparable to imperative languages like Pascal. 1
Efficiently Executing PVS
- Project report, ComputerScience Laboratory, SRI International, Menlo Park
, 1999
"... Specification languages like PVS are designed to be expressive rather than executable. However, execution is useful for animating and validating specifications, and for automating certain kinds of proofs. A surprisingly large fragment of PVS turns out to be executable as a functional language with q ..."
Abstract
-
Cited by 10 (1 self)
- Add to MetaCart
Specification languages like PVS are designed to be expressive rather than executable. However, execution is useful for animating and validating specifications, and for automating certain kinds of proofs. A surprisingly large fragment of PVS turns out to be executable as a functional language with quite reasonable efficiency. Execution is achieved by generating Common Lisp code from PVS. The key step in generating efficient code is the use of static analysis to determine safe destructive array updates. Contents 1 Introduction 5 2 A Brief Summary of the PVS Specification Language 7 3 Executing PVS 13 3.1 Translating Primitive Operations . . . . . . . . . . . . . . . . 15 3.2 Translating Expressions . . . . . . . . . . . . . . . . . . . . . 16 3.3 Optimizing Unary to Multiary Function Application . . . . . . 19 3.3.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.4 Translating Recursive Datatypes . . . . . . . . . . . . . . . . . 25 4 Optimizing Nondestructive to Destr...
Static Analysis for Safe Destructive Updates (Extended Abstract)
- Logic Based Program Synthesis and Transformation (LOPSTR 2001), volume 2372 of LNCS
, 2001
"... this paper is for a generic functional language and requires no prior knowledge of PVS. ..."
Abstract
-
Cited by 6 (1 self)
- Add to MetaCart
this paper is for a generic functional language and requires no prior knowledge of PVS.
What About the Natural Numbers
- Computer Languages
, 1989
"... A prime concern in the design of any general purpose programming language should be the ease and safety of working with natural numbers, particularly in conjunction with discrete data structures. This theme of commitment to the naturals as the basic numeric data type is explored in the context of a ..."
Abstract
-
Cited by 3 (2 self)
- Add to MetaCart
A prime concern in the design of any general purpose programming language should be the ease and safety of working with natural numbers, particularly in conjunction with discrete data structures. This theme of commitment to the naturals as the basic numeric data type is explored in the context of a lazy functional language. Non-Title Keywords: structural correspondence, numeric types, total functions, closed systems, functional programming, lazy evaluation.
Partitioning Non-strict Functional Languages for Multi-threaded Code Generation
- In Proceedings of Static Analysis Symposium '95
, 1995
"... In this paper, we present a new approach to partitioning, the problem of generating sequential threads for programs written in a non-strict functional language. The goal of partitioning is to generate threads as large as possible, while retaining the non-strict semantics of the program. We define p ..."
Abstract
-
Cited by 3 (0 self)
- Add to MetaCart
In this paper, we present a new approach to partitioning, the problem of generating sequential threads for programs written in a non-strict functional language. The goal of partitioning is to generate threads as large as possible, while retaining the non-strict semantics of the program. We define partitioning as a program transformation and design algorithms for basic block partitioning and inter-procedural partitioning. The inter-procedural algorithm presented here is more powerful than the ones previously known and is based on abstract interpretation, enabling the algorithm to handle recursion in a straightforward manner. We prove the correctness of these algorithms in a denotational semantic framework. Keywords: Partitioning, abstract interpretation, demand and tolerance sets, inter-procedural analysis, non-strict functional languages. 1 Introduction Functional programming languages can be divided into two classes: strict and non-strict. In a non-strict language, functions may r...
How Much Non-strictness do Lenient Programs Require?
- In Conf. on Func. Prog. Languages and Computer Architecture
, 1995
"... Lenient languages, such as Id90, have been touted as among the best functional languages for massively parallel machines [AHN88]. Lenient evaluation combines non-strict semantics with eager evaluation [Tra91]. Non-strictness gives these languages more expressive power than strict semantics, while ea ..."
Abstract
-
Cited by 2 (0 self)
- Add to MetaCart
Lenient languages, such as Id90, have been touted as among the best functional languages for massively parallel machines [AHN88]. Lenient evaluation combines non-strict semantics with eager evaluation [Tra91]. Non-strictness gives these languages more expressive power than strict semantics, while eager evaluation ensures the highest degree of parallelism. Unfortunately, non-strictness incurs a large overhead, as it requires dynamic scheduling and synchronization. As a result, many powerful program analysis techniques have been developed to statically determine when non-strictness is not required [CPJ85, Tra91, Sch94]. This paper studies a large set of lenient programs and quantifies the degree of non-strictness they require. We identify several forms of non-strictness, including functional, conditional, and data structure non-strictness. Surprisingly, most Id90 programs require neither functional nor conditional non-strictness. Many benchmark programs, however, make use of a limited fo...

