Results 1 - 10
of
24
Data Parallel Haskell: a status report
, 2007
"... We describe the design and current status of our effort to implement the programming model of nested data parallelism into the Glasgow Haskell Compiler. We extended the original programmingmodel and its implementation, both of which were first popularised by the NESL language, in terms of expressiv ..."
Abstract
-
Cited by 56 (14 self)
- Add to MetaCart
We describe the design and current status of our effort to implement the programming model of nested data parallelism into the Glasgow Haskell Compiler. We extended the original programmingmodel and its implementation, both of which were first popularised by the NESL language, in terms of expressiveness as well as efficiency. Our current aim is to provide a convenient programming environment for SMP parallelism, and especially multicore architectures. Preliminary benchmarks show that we are, at least for some programs, able to achieve good absolute performance and excellent speedups.
Playing by the rules: rewriting as a practical optimisation technique in GHC
"... We describe a facility for improving optimization of Haskell programs using rewrite rules. Library authors can use rules to express domain-specific optimizations that the compiler cannot discover for itself. The compiler can also generate rules internally to propagate information obtained from aut ..."
Abstract
-
Cited by 46 (6 self)
- Add to MetaCart
We describe a facility for improving optimization of Haskell programs using rewrite rules. Library authors can use rules to express domain-specific optimizations that the compiler cannot discover for itself. The compiler can also generate rules internally to propagate information obtained from automated analyses. The rewrite mechanism is fully implemented in the released Glasgow Haskell Compiler. Our system is very simple, but can be effective in optimizing real programs. We describe two practical applications involving short-cut deforestation, for lists and for rose trees, and document substantial performance improvements on a range of programs. 1 Introduction Optimising compilers perform program transformations that improve the efficiency of the program. However, a compiler can only use relatively shallow reasoning to guarantee the correctness of its optimisations. In contrast, the programmer has much deeper information about the program and its intended behaviour. For example, a programmer may know that
Practical Implementation of a Dependently Typed Functional Programming Language
, 2005
"... Language ..."
Functional array fusion
- In ICFP ’01: Proceedings of the sixth ACM SIGPLAN international conference on Functional programming
, 2001
"... This paper introduces a new approach to optimising array algorithms in functional languages. We are specifically aiming at an efficient implementation of irregular array algorithms that are hard to implement in conventional array languages such as Fortran. We optimise the storage layout of arrays co ..."
Abstract
-
Cited by 17 (5 self)
- Add to MetaCart
This paper introduces a new approach to optimising array algorithms in functional languages. We are specifically aiming at an efficient implementation of irregular array algorithms that are hard to implement in conventional array languages such as Fortran. We optimise the storage layout of arrays containing complex data structures and reduce the running time of functions operating on these arrays by meansofequationalprogramtransformations. Inparticular, this paper discusses a novel form of combinator loop fusion, whichbyremovingintermediatestructuresoptimisestheuse of the memory hierarchy. We identify a combinator named loopP that provides a general scheme for iterating over an array and that in conjunction with an array constructor replicateP is sufficient to express a wide range of array algorithms. On this basis, we define equational transformation rules that combine traversals of loopP and replicateP as well as sequences of applications of loopP into a single loopP traversal. Our approach naturally generalises to a parallel implementation and includes facilities for optimising load balancing and communication. A prototype implementation based on the rewrite rule pragma of the Glasgow Haskell Compiler is significantly faster than standard Haskell arrays and approaches the speed of hand coded C for simple examples. 1.
Harnessing the Multicores: Nested Data Parallelism in Haskell
, 2008
"... ABSTRACT. If you want to program a parallel computer, a purely functional language like Haskell is a promising starting point. Since the language is pure, it is by-default safe for parallel evaluation, whereas imperative languages are by-default unsafe. But that doesn’t make it easy! Indeed it has p ..."
Abstract
-
Cited by 17 (6 self)
- Add to MetaCart
ABSTRACT. If you want to program a parallel computer, a purely functional language like Haskell is a promising starting point. Since the language is pure, it is by-default safe for parallel evaluation, whereas imperative languages are by-default unsafe. But that doesn’t make it easy! Indeed it has proved quite difficult to get robust, scalable performance increases through parallel functional programming, especially as the number of processors increases. A particularly promising and well-studied approach to employing large numbers of processors is data parallelism. Blelloch’s pioneering work on NESL showed that it was possible to combine a rather flexible programming model (nested data parallelism) with a fast, scalable execution model (flat data parallelism). In this paper we describe Data Parallel Haskell, which embodies nested data parallelism in a modern, general-purpose language, implemented in a state-of-the-art compiler, GHC. We focus particularly on the vectorisation transformation, which transforms nested to flat data parallelism. 1
Scrap your Nameplate - Functional Pearl
"... Recent research has shown how boilerplate code, or repetitive code for traversing datatypes, can be eliminated using generic programming techniques already available within some implementations of Haskell. One particularly intractable kind of boilerplate is nameplate, or code having to do with names ..."
Abstract
-
Cited by 15 (4 self)
- Add to MetaCart
Recent research has shown how boilerplate code, or repetitive code for traversing datatypes, can be eliminated using generic programming techniques already available within some implementations of Haskell. One particularly intractable kind of boilerplate is nameplate, or code having to do with names, name-binding, and fresh name generation. One reason for the difficulty is that operations on data structures involving names, as usually implemented, are not regular instances of standard map, fold , or zip operations. However, in nominal abstract syntax, an alternative treatment of names and binding based on swapping, operations such as #-equivalence, capture-avoiding substitution, and free variable set functions are much better-behaved.
Using Circular Programs to Deforest in Accumulating Parameters
, 2002
"... Functional languages allow a modular programming style by function composition, which however can lead to inefficient runtime behavior due to production and consumption of intermediate results. We present a new mechanizable transformation technique for removing intermediate data structures in the co ..."
Abstract
-
Cited by 13 (4 self)
- Add to MetaCart
Functional languages allow a modular programming style by function composition, which however can lead to inefficient runtime behavior due to production and consumption of intermediate results. We present a new mechanizable transformation technique for removing intermediate data structures in the composition of two functions from a class of recursive functions with accumulating parameters, for which classical deforestation techniques fail. In order to avoid multiple traversals of the input data structure, the composition algorithm produces circular programs that make essential use of lazy evaluation and local recursion. The resulting programs are simplified using a post-processing phase presented in the paper.
Fine Control of Demand in Haskell
- In 6th International Conference on the Mathematics of Program Construction, Dagstuhl
, 2002
"... Functional languages have the A-calculus at their core, but then depart fi'om this fu'm foundation by including features that alter their default evaluation order. The resulting mixed evaluation--partly lazy and partly strict--complicates the formal semantics of these languages. ..."
Abstract
-
Cited by 12 (5 self)
- Add to MetaCart
Functional languages have the A-calculus at their core, but then depart fi'om this fu'm foundation by including features that alter their default evaluation order. The resulting mixed evaluation--partly lazy and partly strict--complicates the formal semantics of these languages.
A call-by-need lambda-calculus with locally bottom-avoiding choice: Context lemma and correctness of transformations
- MATHEMATICAL STRUCTURES IN COMPUTER SCIENCE
, 2008
"... We present a higher-order call-by-need lambda calculus enriched with constructors, case-expressions, recursive letrec-expressions, a seq-operator for sequential evaluation and a non-deterministic operator amb that is locally bottom-avoiding. We use a small-step operational semantics in form of a sin ..."
Abstract
-
Cited by 12 (9 self)
- Add to MetaCart
We present a higher-order call-by-need lambda calculus enriched with constructors, case-expressions, recursive letrec-expressions, a seq-operator for sequential evaluation and a non-deterministic operator amb that is locally bottom-avoiding. We use a small-step operational semantics in form of a single-step rewriting system that defines a (nondeterministic) normal order reduction. This strategy can be made fair by adding resources for bookkeeping. As equational theory we use contextual equivalence, i.e. terms are equal if plugged into any program context their termination behaviour is the same, where we use a combination of may- as well as must-convergence, which is appropriate for non-deterministic computations. We show that we can drop the fairness condition for equational reasoning, since the valid equations w.r.t. normal order reduction are the same as for fair normal order reduction. We evolve different proof tools for proving correctness of program transformations, in particular, a context lemma for may- as well as mustconvergence is proved, which restricts the number of contexts that need to be examined for proving contextual equivalence. In combination with so-called complete sets of commuting and forking diagrams we show that
all the deterministic reduction rules and also some additional transformations preserve contextual equivalence.We also prove a standardisation theorem for fair normal order reduction. The structure of the ordering <= c is also analysed: Ω is not a least element, and <=c already implies contextual equivalence w.r.t. may-convergence.
Understanding Memory Allocation of Scheme Programs
, 2000
"... Memory is the performance bottleneck of modern architectures. Keeping memory consumption as low as possible enables fast and unobtrusive applications. But it is not easy to estimate the memory use of programs implemented in functional languages, due to both the complex translations of some high leve ..."
Abstract
-
Cited by 10 (1 self)
- Add to MetaCart
Memory is the performance bottleneck of modern architectures. Keeping memory consumption as low as possible enables fast and unobtrusive applications. But it is not easy to estimate the memory use of programs implemented in functional languages, due to both the complex translations of some high level constructs, and the use of automatic memory managers. To help understand memory allocation behavior of Scheme programs, we have designed two complementary tools. The first one reports on frequency of allocation, heap configurations and on memory reclamation. The second tracks down memory leaks. We have applied these tools to our Scheme compiler, the largest Scheme program we have been developing. This has allowed us to drastically reduce the amount of memory consumed during its bootstrap process, without requiring much development time. Development tools will be neglected unless they are both conveniently accessible and easy to use. In order to avoid this pitfall, we have carefully de...

