Results 1 -
3 of
3
The nofib Benchmark Suite of Haskell Programs
, 1993
"... This position paper describes the need for, make-up of, and "rules of the game" for a benchmark suite of Haskell programs. (It does not include results from running the suite.) Those of us working on the Glasgow Haskell compiler hope this suite will encourage sound, quantitative assessment of lazy f ..."
Abstract
-
Cited by 68 (0 self)
- Add to MetaCart
This position paper describes the need for, make-up of, and "rules of the game" for a benchmark suite of Haskell programs. (It does not include results from running the suite.) Those of us working on the Glasgow Haskell compiler hope this suite will encourage sound, quantitative assessment of lazy functional programming systems. This version of this paper reflects the state of play at the initial pre-release of the suite. 1 Towards lazy functional benchmarking 1.1 History of benchmarking---functional The quantitative measurement of systems for lazy functional programming is a near-scandalous subject. Dancing behind a thin veil of disclaimers, researchers in the field can still be found quoting "nfibs/sec" (or something equally egregious) , as if this refers to anything remotely interesting. The April, 1989, Computer Journal special issue on lazy functional programming is a not-too-dated self-portrait of the community that promotes computing in this way. It is one that non-specialists...
Compilation of Functional Languages Using Flow Graph Analysis
, 1994
"... syntax, and syntactic and semantic domains of a flow graph Figure 9. Semantic equations Def and Exp of a flow graph The first argument to the functions Def and Exp specifies a set of nodes that represent a flow graph, from which the element(s) of current interest are selected by pattern matching. ..."
Abstract
-
Cited by 16 (12 self)
- Add to MetaCart
syntax, and syntactic and semantic domains of a flow graph Figure 9. Semantic equations Def and Exp of a flow graph The first argument to the functions Def and Exp specifies a set of nodes that represent a flow graph, from which the element(s) of current interest are selected by pattern matching.
Arrays in a lazy functional language -- a case study: the fast Fourier transform
- 2nd Arrays, functional languages, and parallel systems (ATABLE
, 1992
"... The array plays a prominent role in imperative programming languages because the data structure bears a close resemblance to the mathematical notion of a vector and because array operations can be implemented efficiently. Not all lazy functional languages offer arrays as a primitive data structure b ..."
Abstract
-
Cited by 8 (5 self)
- Add to MetaCart
The array plays a prominent role in imperative programming languages because the data structure bears a close resemblance to the mathematical notion of a vector and because array operations can be implemented efficiently. Not all lazy functional languages offer arrays as a primitive data structure because laziness makes it difficult to implement arrays efficiently. We study 8 different versions of the Fast Fourier Transform, with and without arrays, to assess the importance of arrays in a lazy functional language. An efficient implementation of arrays contributes significantly to the performance of functional languages in certain areas. However, a clear distinction should be made between array construction and array subscription. In the FFT example we could not gain efficiency by using array construction, other than for storing precomputed data like the input. Using array subscription improves performance. 1

