We consider the impact of introducing the future construct to the multiple value facility in Lisp (Common Lisp and Scheme). A natural way to accommodate this problem is by modifying the implementation of futures so that one future object returns (or resolves to) multiple values instead of one. We first show how a such straightforward modification fails to maintain the crucial characteristic of futures, namely that inserting futures in a functional program does not alter the the result of the computation. A straightforward modification may result in wrong number of values. We then present two methods which we call the mv-context method and the mv-p flag method to overcome this problem. Both of these methods have been tested in TOP-1 Common Lisp, an implementation of a parallel Common Lisp on the TOP-1 multiprocessor workstation. To our knowledge, this problem has never been analyzed nor solved in an implementation of parallel Lisp. We also present the technique of future chain elimination which avoids creation of unnecessary futures and processes at run-time, which was inspired by this solution.
In theory, abstraction is important, but in practice, so is performance. Thus, there is a struggle between an abstract description of an algorithm and its efficient implementation. This struggle can be mediated by using an interpreter or a compiler. An interpreter takes a program that is a high level abstract description of an algorithm and applies it to some data. Don't think of an interpreter as slow. An interpreter is important enough to software that it is often implemented in hardware. A compiler takes the program and produces another program, perhaps in another language. The resulting program is applied to some data by another interpreter.
Much has been written about Lazy Evaluation in Lisp---less about the other end of the spectrum---Ambitious Evaluation. Ambition is a very subjective concept, though, and if you have some preconceived idea of what you think an Ambitious Evaluator might be about, you might want to set it aside for a few minutes because this probably isn't going to be what you expect.
article Free Access Share on The embeddable Common Lisp Author: Guiseppe Attardi Univ. di Pisa, Pisa, Italy Univ. di Pisa, Pisa, ItalyView Profile Authors Info & Claims ACM SIGPLAN Lisp PointersVolume VIIIIssue 1Jan.-April 1995 pp 30–41https://doi.org/10.1145/224138.1379849Published:01 August 1994Publication History 0citation341DownloadsMetricsTotal Citations0Total Downloads341Last 12 Months70Last 6 weeks12 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteeReaderPDF
Maybe not as hot a topic in computer architecture as it used to be, but still of considerable interest, is parallelism. How do you make a faster computer? Just strap 20 or 200 or 2000 processors together? As we have learned, the architectural and hardware difficulties are immense (How do you connect them? A shared bus? A network? Is there a single system clock or many clocks?), and after these have been solved there remains the matter of programming.
Scheme has served the community for twenty years. It has demonstrated that a useful language can be constructed which has a very small number of rules for forming expressions. Scheme's set of rules were carefully chosen so as to produce a language flexible enough to support most major programming paradigms in use today, yet allow efficient implementations.
Garbage collectors perform two functions: live-object detection and dead-object reclamation . In this paper, we present a new technique for live-object detection based on run-time type reconstruction for a strongly typed, polymorphic language. This scheme uses compile-time type information together with the run-time tree of activation frames to determine the exact type of every object participating in the computation. These reconstructed types are then used to identify and traverse the live heap objects during garbage collection. We describe an implementation of our scheme for the Id parallel programming language compiled for the *T multiprocessor architecture. We present simulation studies that compare the performance of type-reconstructing garbage collection with conservative garbage collection and compiler-directed storage reclamation.
Scheme has served the community for twenty years. It has demonstrated that a useful language can be constructed which has a very small number of rules for forming expressions. Scheme's set of rules were carefully chosen so as to produce a language flexible enough to support most major programming paradigms in use today, yet allow efficient implementations.
This paper analyzes the FANNKUCH benchmark, that was discussed on the comp.lang.lisp internet newsgroup during September 1994, and reviews the performance issues underlying it. This benchmark involves operations on integers and vectors of integers so one might expect that Lisp and C versions could have comparable performance. However, the original benchmark suggested that the Lisp version was at least 10 times slower than the C version. While this version appeared to be optimized, several important improvements are possible.The improved version is between 24 and 116 percent slower than C when run on several Lisp implementations. This can be accounted for by differences in the quality of the compiled code of the inner loops of the benchmark, not by an essential difference between the two languages. The GNU C compiler, gcc, produces a loop with a larger overall size (footprint) but with a smaller loop body than the current Lisp compilers. In principle, a Lisp compiler can produce these loops with the same or fewer number of instructions.It is easy to write benchmarks that make Lisp appear slower than C. However, as with any highly tuned benchmark, a small change can have a profound effect on performance. even in C. For example, replacing / 2 by ≫1 makes a 40% improvement. Also changing the representation of integers and arrays of integers among C's built in types varies the performance by 80%.
The array update problem in the implementation of a purely functional language is the following: once an array is updated, both the original array and the newly updated one must be preserved to maintain referential transparency. Previous approaches have mainly based on the detection or enforcement of single-threaded accesses to an aggregate, by means of compiler-time analyses or language restrictions. These approaches cannot deal with aggregates which are updated in a multi-threaded manner.Baker's shallow binding scheme can be used to implement multi-threaded functional arrays. His scheme, however, can be very expensive if there are repeated alternations between long binding paths. We design a scheme that fragments binding paths randomly. The randomization scheme is on-line, simple to implement, and its expected performance comparable to that of the optimal off-line solutions. All this is achieved without using compiler-time analyses, and without restricting the languages.The expected performance of the randomization scheme is analyzed in details, and some preliminary results are shown. Applications of the randomization technique to other functional aggregates, as well as its implications, are briefly outlined.
Soft typing is a generalization of static type checking that accommodates both dynamic typing and static typing in one framework. A soft type checker infers types for identifiers and inserts explicit run-time checks to transform untypable programs into typable form. Soft Scheme is a practical soft type system for R4RS Scheme. The type checker uses a representation for types that is expressive, easy to interpret, and supports efficient type inference. Soft Scheme supports all of R4RS Scheme, including uncurried procedures of fixed and variable arity, assignment, and continuations.
This paper challenges the myth that Lisp programs are slow, and C programs are fast, by comparing two 2,000 line programs. The two programs are popular machine learning programs, Fahlman's Cascade Correlation program, CASCOR.1, and John Koza's Genetic Programming program, referred to here as GP. CASCOR1 is floating point intensive, while GP is floating point and structure manipulation intensive. These programs not only provide medium sized interlanguage benchmarks, but also provide an opportunity to study performance tuning. One man-day of tuning was done on each of the Lisp versions of the programs, using commonly available tools such as compiler advice and profilers. Much less than 10% of the code was changed. The performance of CASCOP~I (already highly optimized) was improved by almost 40%, comparable to or slightly faster than the C version. The main difference between Lisp and C is the quality of compiling a dot product loop. GP (not optimized, but well written pedagogical software) was improved by a factor of 30, and is over twice as fast as the C version which was advertised as "highly optimized". Lisp's advantages are due, at least in part, to automatic garbage collection and dynamic typing. In real programs, performance has more to do with choice of algorithm, and quality of compiler than on choice of language.
This paper presents a denotational semantics for the combinations of the Scheme language. Scheme leaves unspecified the order of evaluation of the terms of a combination. Our purpose is to formally and denotationally characterize such indeterminacy. We achieve this by extending the denotation as well as the domain of final answers to take into account the various possible orders of evaluation.
Reasoning about program variables as sets of “values” leads to a simple, accurate and intuitively appealing notion of program approximation. This paper presents approach for the compile-time analysis of ML programs. To develop the core ideas of the analysis, we consider a simple untyped call-by-value functional language. Starting with an operational semantics for the language, we develop an approximate “set-based” operational semantics, which formalizes the intuition of treating program variables as sets. The key result of the paper is an O ( n 3 ) algorithm for computing the set based approximation of a program. We then extend this analysis in a natural way to deal with arrays, arithmetic, exceptions and continuations. We briefly describe our experience with an implementation of this analysis for ML programs.
Lists are a pervasive data structure in functional programs. The generality and simplicity of their structure makes them expensive. Hindley-Milner type inference and partial evaluation are all that is needed to optimise this structure, yielding considerable improvements in space and time consumption for some interesting programs. This framework is applicable to many data types and their optimised representations, such as lists and parallel implementations of bags, or arrays and quadtrees.
Adding a module system to LISP enhances program security and efficiency, and help the programmer master the complexity of large systems, thus facilitating application and delivery. TALK's module system is based on a simple compilation model which takes macros into account and provides a solid basis for automatic module management tools. Higher-level structuring entities—libraries and executables—group modules into deliverable goods. The module system is secure because it validates interfaces, efficient because it separates compilation dependencies from execution dependencies, and useful because it offers a simple processing model, automatic tools, and a graceful transition from development to delivery.
ANSI Technical Committee X3J13 met on March 31 and April 1, 1992, to resolve outstanding issues in the draft proposal for Common Lisp. A few members had brought up some inconsistencies found at the last minute, and these were fairly easily resolved.
Inlining trials are a general mechanism for making better automatic decisions about whether a routine is profitable to inline. Unlike standard source-level inlining heuristics, an inlining trial captures the effects of optimizations applied to the body of the inlined routine when calculating the costs and benefits of inlining. The results of inlining trials are stored in a persistent database to be reused when making future inlining decisions at similar call sites. Type group analysis can determine the amount of available static information exploited during compilation, and the results of analyzing the compilation of an inlined routine help decide when a future call site would lead to substantially the same generated code as a given inlining trial. We have implemented inlining trials and type group analysis in an optimizing compiler for SELF, and by making wiser inlining decisions we were able to cut compilation time and compiled code space with virtually no loss of execution speed. We believe that inlining trials and type group analysis could be applied effectively to many high-level languages where procedural or functional abstraction is used heavily.
We show that reasoning by case analysis (on whether subprograms diverge or converge) is complete for proving PCF observational congruences of algebraic terms. The latter are applicative combinations of first-order variables and a constant Ω denoting a diverging program of base type. A restricted version of the logic is complete for proving equality of algebraic terms in the full continuous type hierarchy (equivalently, observational congruence in PCF with parallel conditional). We show that the provability in the latter logic is in co-NP. We also give complete equational proof systems for a subclass of algebraic terms; provability in these systems is in linear time.
