Results 11 -
18 of
18
Efficient Graph Algorithms Using Lazy Monolithic Arrays
- Journal of Functional Programming
, 1998
"... this paper is to show how this problem, and some related ones, can be solved using a novel array creation primitive, lazier than previous ones. Thus, in section 2 we specify the array creation primitive lazyArray. In section 3 we give the solution to the graph marking and depth-first numbering probl ..."
Abstract
-
Cited by 2 (0 self)
- Add to MetaCart
this paper is to show how this problem, and some related ones, can be solved using a novel array creation primitive, lazier than previous ones. Thus, in section 2 we specify the array creation primitive lazyArray. In section 3 we give the solution to the graph marking and depth-first numbering problems using our lazy arrays. In section 4 we show how a related and more general problem, that of computing the transitive closure of a binary relation, can be solved in a similar manner. Graph based unification is an essential ingredient in a time and space efficient type inferencer: in section 5 we give such an algorithm in the same style. In section 6 we show how lazy arrays can be implemented efficiently with low-level graph reduction code. In section 7 we discuss space efficiency. Programs in this paper will be given in the nonstrict purely functional language Haskell. 2 Lazy Arrays
Formal Description for Collecting Reachable Garbage via Dynamic Type Inference
- In: Proceedings of the Second International Workshop on Types in Compilation (TIC98
, 1998
"... A garbage collection (GC) scheme --- what we call type inference GC --- that dynamically performs type inference is studied. In contrast to conventional garbage collection that can collect only unreachable objects, this scheme can collect objects that are reachable yet semantically garbage. The idea ..."
Abstract
-
Cited by 2 (0 self)
- Add to MetaCart
A garbage collection (GC) scheme --- what we call type inference GC --- that dynamically performs type inference is studied. In contrast to conventional garbage collection that can collect only unreachable objects, this scheme can collect objects that are reachable yet semantically garbage. The idea is to utilize ML-like type information that can tell whether or not each object may be used in the rest of computation. There has been some work studying algorithms of the GC scheme. However, their descriptions are either too informal or too abstract, and as a result, either correctness of their algorithms is not so clear, or there remains a gap between models and implementation. Moreover, no formal framework has dealt with polymorphism. This paper presents a formal framework that can directly serve both as specifications for implementing the GC scheme and as a foundation for discussing it. Specifically, on top of a language that reflects a usual execution scheme for functional languages, w...
Optimising Recursive Functions Yielding Multiple Results in Tuples in a Lazy Functional Language
- In: Implementation of Functional Languages, Lochem, The Netherlands, Proceedings
, 2000
"... . We discuss a new optimisation for recursive functions yielding multiple results in tuples for lazy functional languages, like Clean and Haskell. This optimisation improves the execution time of such functions and also reduces the amount of memory allocated in the heap by these functions, which ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
. We discuss a new optimisation for recursive functions yielding multiple results in tuples for lazy functional languages, like Clean and Haskell. This optimisation improves the execution time of such functions and also reduces the amount of memory allocated in the heap by these functions, which reduces garbage collection costs. In some cases execution time is improved by more than a factor of two and allocation costs by a factor of four. Furthermore, the space leak that is caused by selector nodes is removed. This is achieved by reusing nodes allocated in the previous iteration of the recursion to create the nodes for the next iteration, by updating these nodes. Only the parts of the nodes that have changed are updated. Because of these updates, the code that is used to select an element of a tuple is not executed anymore for many selections, because the selector node was overwritten with a new selector node or the result before it is evaluated. 1 Introduction In lazy ...
nhc: a space-efficient Haskell compiler
, 1995
"... Self-compiling implementations of Haskell, i.e., those written in Haskell, have been and, except one, are still space consuming monsters. Object code size for the compilers themselves are 3-8 Mbyte, and they need 12-20 Mbyte to recompile themselves. One reason for the huge demands for memory is that ..."
Abstract
- Add to MetaCart
Self-compiling implementations of Haskell, i.e., those written in Haskell, have been and, except one, are still space consuming monsters. Object code size for the compilers themselves are 3-8 Mbyte, and they need 12-20 Mbyte to recompile themselves. One reason for the huge demands for memory is that the main goal for these compilers is to produce fast code. However, the compiler described in this paper, called nhc for Nearly a Haskell Compiler, is the above mentioned exception. This compiler concentrates on keeping memory usage down, even at a cost in time. The code produced is not fast but nhc is usable, and the resulting programs can be run, on computers with small memory.
The low demand for memory in nhc has two causes: carefully chosen algorithms in the compiler, and a memory efficient abstract machine. The former only affects memory demands in nhc, but the latter is a win for all programs compiled by nhc. The memory efficient algorithms used in nhc can be used in other Haskell compilers with no, or very small, changes to their run-time systems. They have only a marginal effect on compile time. The reason for the slow speed is mostly due to the implementation of the abstract machine, a byte coded G-machine.
Programs compiled by nhc can produce many different heap profiles to facilitate development of more space efficient programs. One example is nhc itself, where these profiles were used to choose between different algorithms.
The current version of nhc includes heap profiling of live objects. These profiles can show the producers, constructors, retainers or lifetimes of the live objects in the heap. A simple time profile is also available.
Time is however neither the main focus of nhc nor of this paper, but there is nevertheless a small section about the speed of nhc. The most notable observation concerning speed is that nhc spends approximately half the time processing interface files, which is much more than is needed in, e.g., the type checker. Processing interface files is also the most space consuming part of nhc in most cases. It is only when compiling source files with large sets of mutually recursive functions that more memory is
needed to type check than to process interface files.
Bounded Frame, Cycle and Large Object Handling in Generational Older-First Garbage Collection
, 2007
"... Over the years, research has been done on several techniques related to garbage collection. Many key insights for copying-based generational garbage collection tech-niques have been revealed. Yet, there is still room for improvement. In this thesis, we introduce various new techniques and algorithms ..."
Abstract
- Add to MetaCart
Over the years, research has been done on several techniques related to garbage collection. Many key insights for copying-based generational garbage collection tech-niques have been revealed. Yet, there is still room for improvement. In this thesis, we introduce various new techniques and algorithms to improve garbage collection. In particular, we introduce the bounded frame marking technique for tracking pointers. This technique allows for efficient computation of the root set. It reuses concepts from two existing techniques, card marking and remembered sets, and uses a bidirectional object layout to improve them by regulating space overhead and reducing the pointer scanning workload. We also present an algorithm to recursively mark reachable objects without using a stack (eliminating the usual space overhead). We adapt this algorithm to implement a depth-first copying collector and increase heap locality. We improve the older-first garbage collection algorithm and its generational variant by adding a mark phase that guarantees the collection of all garbage, including cyclic structures spanning many windows. Finally, we introduce a technique to deal with large objects. In order to test our ideas, we have designed and implemented a portable and extensible garbage collection framework within the SableVM open source Java virtual machine. In it, we have implemented semi-space, older-first, and generational copying garbage collection algorithms. Our experiments show that the bounded frame technique yields competitive performances on many benchmarks. They also show that, for most benchmarks, our depth-first traversal algorithm improves locality and thus increases performance. Our overall performance measurements show that, using our techniques, a garbage collector can deliver competitive performance and surpass existing collectors on various benchmarks.
Precise Garbage Collection in Prolog
"... Abstract. In this paper we present a series of tiny programs that verify that a Prolog heap garbage collector can find specific forms of garbage. Only 2 out of our tested 7 Prolog systems pass all tests. Comparing memory usage on realistic programs dealing with finite datastructures using both poor ..."
Abstract
- Add to MetaCart
Abstract. In this paper we present a series of tiny programs that verify that a Prolog heap garbage collector can find specific forms of garbage. Only 2 out of our tested 7 Prolog systems pass all tests. Comparing memory usage on realistic programs dealing with finite datastructures using both poor and precise garbage collection shows only a small difference, providing a plausible explanation why many Prolog implementors did not pay much attention to this issue. Attributed variables allow for creating infinite lazy datastructures. We prove that such datastructures have great practical value and their introduction requires ‘precise’ garbage collection. The Prolog community knows about three techniques to reach at precise garbage collection. We summarise these techniques and provide more details on scanning virtual machine instructions to infer reachability in a case study. 1
Purity, Impurity and Efficiency in Graph Algorithms
"... Introduction This chapter initially considers pure lazy functional languages: their philosophy, advantages and disadvantages. We then examine how to develop efficient lazy functional programs. One way to achieve efficiency is to introduce impurities. In the final section the two schools of lazy fun ..."
Abstract
- Add to MetaCart
Introduction This chapter initially considers pure lazy functional languages: their philosophy, advantages and disadvantages. We then examine how to develop efficient lazy functional programs. One way to achieve efficiency is to introduce impurities. In the final section the two schools of lazy functional programming, pure and impure, are assessed. The assessment centres around two partial implementations of the Hopcroft Tarjan graph planarity algorithm. Profiling tools are used to make an experimental comparison and optimisation of each program. 4.1 Lazy Functional Programming In his book [42] Reade suggests that the user of a traditional imperative language is required to do the following: 1. describe the result to be computed; 2. impose an order on the steps required in the computation; 3. create and destroy, as required, any data structures used by the computation. 74 The first item is concerned with the extensional prope
Execution Profiling for . . .
, 1994
"... Profiling tools, which measure and display the dynamic space and time behaviour of programs, are essential for identifying execution bottlenecks. A variety of such tools exist for conventional languages, but almost none for non-strict functional languages. There is a good reason for this: lazy evalu ..."
Abstract
- Add to MetaCart
Profiling tools, which measure and display the dynamic space and time behaviour of programs, are essential for identifying execution bottlenecks. A variety of such tools exist for conventional languages, but almost none for non-strict functional languages. There is a good reason for this: lazy evaluation means that the program is executed in an order which is not immediately apparent from the source code, so it is difficult to relate dynamically-gathered statistics back to the original source. This thesis examines the difficulties of profiling lazy higher-order functional languages and develops a profiling tool which overcomes them. It relates information about both the time and space requirements of the program back to the original source expressions identified by the programmer. Considerable attention is paid to the cost semantics with two abstract cost semantics, lexical scoping and evaluation scoping, being investigated. Experience gained from the two profiling schemes led to the d...

