P.H. Hartel and K.G. Langedoen. Benchmarking implementations of lazy functional languages. In Proceedings FPCA, pages 341--349, 1993.  Home/Search   Document Details and Download   Summary   Related Articles   Check

....(see Wadler [18] applied (also manually) run with input 11. sort Sorts a list of 6000 integers using insertion sort. factor Factorizes a number into primes in a very inefficient way, run with input 1073602561. event A small event driven simulator from Hartel and Langendoens benchmark suite [6], run with input 400000. sched A job scheduler, also from that benchmark suite, run with input 12. tc A simple polymorphic type checker from the same source , run with input 600. There are two sets of measurements, with and without cloning (see Section 3.2) The programs which only occur ....

Pieter Hartel and Koen Langendoen. Benchmarking implementations of lazy functional languages. In Functional Programming & Computer Architecture, pages 341--349, Copenhagen, June 93.

....8000 integers using insertion sort. leroy A program similar to the Church integer benchmark in [12] maps quad quad (x. x 1) where quad = double double and double f x = f (f x) over the list [1,2, 40000] event A small event driven simulator from Hartel and Langendoens benchmark suite [9], run with input 400000. infer A polymorphic type checker from the same source, run with input 1200. sched A job scheduler, also from that benchmark suite, run with input 14. We have measured operation counts using instrumentation code emitted by the compiler, instruction counts using the ....

Pieter Hartel and Koen Langendoen. Benchmarking implementations of lazy functional languages. In Functional Programming & Computer Architecture, pages 341--349, Copenhagen, June 93.

....functions manually removed by specialization, run with input 11. nrev Naive reverse, a very silly program, but it shows a case where dynamic cheap eagerness really pays off, run on a list of length 4141 elements. event A small event driven simulator from Hartel and Langendoen s benchmark suite [HL93], run with input 400000. sched A job scheduler, also from that benchmark suite, run with input 14. infer A simple polymorphic type checker from [HL93] run with input 600. 4.1 Strategies We have measured several strategies which differ in which thunks they are willing to dynamically ....

....really pays off, run on a list of length 4141 elements. event A small event driven simulator from Hartel and Langendoen s benchmark suite [HL93] run with input 400000. sched A job scheduler, also from that benchmark suite, run with input 14. infer A simple polymorphic type checker from [HL93] , run with input 600. 4.1 Strategies We have measured several strategies which differ in which thunks they are willing to dynamically speculate. s: Only static cheap eagerness, corresponding to the most aggressive strategy in [Fax00] e: Thunks with evals of free variables (speculation ....

Pieter Hartel and Koen Langendoen. Benchmarking implementations of lazy functional languages. In Functional Programming & Computer Architecture, pages 341--349, Copenhagen, June 93.

....toy programs (Euler, MatMult, MergeSort, Nfib, NumInt, Queens, QuickSort, Sieve, Strassen, SumFrom, and Tak that have been described before in [Kas93] Several slightly larger programs were also included: FFT, ODProv, PCProv, Pascal, Event, and Ida. The last two are from Hartel s benchmark suite[HL93], while ODProv[O D85] and PCProv are toy theorem provers. Pascal is an interpreter for a subset of Pascal. All of the larger programs except FFT make extensive use of lazy evaluation[Pey87] This reduces the number of calls that procedures make directly to one another; instead, procedures invoke ....

Pieter H. Hartel and Koen G. Langendoen. Benchmarking implementations of lazy functional languages. In ACM Conference on Functional Programming Languages and Computer Architecture (FPCA), pages 341--349, New York, June 1993. ACM.

....and Performance GEL is implemented as a set of Hope modules, amounting to some 2095 lines (71 kbytes) of source code. Parts of GEL and a complete PMC program have also been translated to a range of other functional languages (included Haskell and Lazy ML) as part of a benchmarking exercise (Hartel Langendoen 1992). The GEL modules fall into three categories: ffl Structural modules provide the higher order D C functions on which GEL is based, including all support for the CSG and geometric decomposition types. ffl Geometric libraries provide operations on basic entities such as points and vectors, from ....

Hartel, P. H. & Langendoen, K. G. (1992), Benchmarking implementations of lazy functional languages, Technical Report CS-92-20, Dept. of Comp. Sys., University of Amsterdam.

....to the heap. It is therefore of great importance that the compiler used in our experiments should perform well. We have adopted the compiler developed for the FAST project [13] and although comparing compilers is difficult, we are confident that the system is competitive with the state of the art [24]. It also, conveniently, generates C, making generated code very easy to instrument and modify. Each processor allocates closures from its own independent part of the heap, and therefore communication is never required when closures are created. Note that a number of assumptions and ....

Pieter H. Hartel and Koen G. Langendoen. Benchmarking implementations of lazy functional languages. In Proceedings of the Conference on Functional Programming Langauges and Computer Architecture, Copenhagen, June, 1993.

....heap. It is therefore of great importance that the compiler used in our experiments should perform well. We have adopted the compiler developed for the FAST project [7] and although comparing compilers is difficult, we have some confidence that the system is competitive with the state of the art [9]. It also, conveniently, generates C, making generated code very easy to instrument and modify. 4.2 Garbage Collection When storage allocated from the shared heap becomes free, it should be recycled for reuse. In a parallel system a parallel garbage collector is needed, and the area is the ....

Pieter H. Hartel and Koen G. Langendoen. Benchmarking implementations of lazy functional languages. In Proceedings of the Conference on Functional Programming Langauges and Computer Architecture, Copenhagen, June, 1993.

....8000 integers using insertion sort. leroy A program similar to the Church integer benchmark in [13] maps quad quad (x. x 1) where quad = double double and double f x = f (f x) over the list [1,2, 40000] event A small event driven simulator from Hartel and Langendoens benchmark suite [8], run with input 400000. typecheck A polymorphic type checker from the same source, run with input 1200. sched A job scheduler, also from that benchmark suite, run with input 14. The compiler can be instructed to generate code counting various events, including executions of boxing and unboxing ....

Pieter Hartel and Koen Langendoen. Benchmarking implementations of lazy functional languages. In Functional Programming & Computer Architecture, pages 341--349, Copenhagen, June 93.

.... MacQueen, 1991) Traditionally, strict languages have a reputation of being more efficient than their non strict counterparts. The author has no conclusive explanation for this opposite behaviour. However, it is certainly the case that the Glasgow Haskell Team has done an excellent job Hartel (1994) relates the Glasgow Haskell Compiler to other systems. All in all we may conclude that backtracking based on monads appears to be a serious alternative to logic languages (but see the remark at the end of Section 2.1) 5 Adding control Having succeeded in programming an efficient backtracking ....

Hartel, P. H. 1994 (December). Benchmarking implementations of lazy functional languages II -- two years later. Tech. rept. CS-94-21. Dept. of Comp. Sys, Univ. of Amsterdam.

....with some advantages, which counterbalance the costs Peyton Jones [Pey92, Part I] provides a technical discussion. One should also note that the Glasgow Haskell Compiler, which uses the tagless approach is currently considered to be the fastest implementation of a lazy functional language [Har94] since it generates code which is competitive to imperative languages [H 96] 3.1.2 Method Tables The idea of representing data objects by closures can be improved further. Instead of a pointer to a single piece of code, each representation of a data object stores a pointer to an array of ....

Pieter H. Hartel. Benchmarking implementations of lazy functional languages II---two years later. Technical Report CS-94-21, University of Amsterdam, 1994.

....frequency at which claims and references are made to the heap. It is therefore of great importance that the compiler used in our experiments should perform reasonably well. Although comparing compilers is difficult, we have some confidence that the system is competitive with the state of the art [11]. It also, conveniently, generates C, making generated code very easy to instrument and modify. 4.2 Process Management Parallel computation is coordinated via the heap where graph nodes are allocated. Work is allocated to processors via a work pool, which in the current system is a simple queue. ....

Pieter H. Hartel and Koen G. Langendoen. Benchmarking implementations of lazy functional languages. In Proceedings of the Conference on Functional Programming Langauges and Computer Architecture, Copenhagen, June, 1993.

....aim was to provide an implementation of a pure, lazy functional language on a transputer array. The project also involved researchers from the University of Amsterdam with whom the Southampton team developed sequential compiler technology [HGW89, GHW90] and performance analysis techniques [HGW91, HaLa92] Researchers at Imperial college and Amsterdam used the Southampton compiler as a basis for investigating various parallel implementation techniques [CHK 92, CHK 93, VrHa92] An important component of the FAST system is a highly optimising compiler for Haskell 1.0 [HuWa90] on a single ....

PH Hartel and KG Langendoen, Benchmarking Implementations of Lazy Functional Languages. Technical Report CS-92-20, Department of Computer Systems, Faculty of Mathematics and Computer Science, University of Amsterdam.

....Pereira and A. Porto to solve the four colors map problem ( 6, pp. 200 201] and Engineering is a planning problem for civil engineering after [6, pp. 189 190] All the tests were executed using a Sparc Classic running SunOS 4.1.3C with 48Mbytes of RAM and a cache memory of 128Kbytes. Like in [13], timings are calculated taking the best value obtained out of ten runs. Also, the Sicstus Prolog compiler was not used with its default byte code, but with the fastcode option specific for Sun architectures (roughly three times faster than the default) and on the other hand no heap tuning ....

....timings are calculated taking the best value obtained out of ten runs. Also, the Sicstus Prolog compiler was not used with its default byte code, but with the fastcode option specific for Sun architectures (roughly three times faster than the default) and on the other hand no heap tuning (cf. [13]) was made to improve Clean execution. The results are presented in Table 3 (run times are expressed in seconds) Although, of course, the transformation should be tested with heavier applications, we think the results give the flavor that employing transformational techniques like that used here ....

P.H. Hartel and K.G. Langedoen. Benchmarking implementations of lazy functional languages. In Proceedings FPCA, pages 341--349, 1993.

....but two aspects of the problem have received little attention until recently: 1. The integration of the results of the analysis into a real compiler. 2. The efficiency of the algorithm implementing the analysis. The first issue has been tackled recently both from an experimental point of view [11, 16] and from a theoretical point of view [5, 8] We are concerned with the second issue in this paper. The abstract interpretation and the projections approaches have led to the construction of analyses based on rich domains which make them intractable even for some simple examples. Techniques ....

P. H. Hartel and K. G. Langendoen, Benchmarking implementations of lazy functional languages, in Proceedings of the 6th ACM Conference on Functional Programming Languages and Computer Architecture, ACM Press, 1993, pp. 341-350.

....because the least significant bit of a descriptor is always zero. We copy nodes that do not have pointer arguments, such as integers and reals, to the end of the new semispace, so that they are not examined again. To compare both collectors, we run the benchmarks described by Hartel and Langendoen [HL93] using our compiler for the lazy functional language Clean, with both collectors, on a SPARCstation 10 30 with 32 megabytes of memory, running SunOS 4.1.3 (a 36 Mhz SuperSPARC processor, with no secondary cache) The results of our comparisons are displayed in Table 1 and 2, including the name of ....

P. H. Hartel and K. G. Langendoen. Benchmarking implementations of lazy functional languages. In Proceedings of the Sixth International Conference on Functional Programming Languages and Computer Architecture (FPCA '93), pages 341--349. ACM Press, June 1993.

No context found.

P. H. Hartel and K. G. Langendoen, `Benchmarking implementations of lazy functional languages', 6th Functional Programming Languages and Computer Architcture, Copenhagen, Denmark, June 1993. ACM, pp. 341--349.

No context found.

P. H. Hartel and K. G. Langendoen. Benchmarking implementations of lazy functional languages. In 6th Functional programming languages and computer architecture, pages 341--349, Copenhagen, Denmark, Jun

....developing functional programs. The Haskell route and the Miranda route should be more integrated than they are at present. It is possible to generate Haskell, Concurrent Clean [13, 19] and LML from advanced Intermediate, so that implementations can be compared using the same benchmark programs [8]. The recommended way to use advanced Intermediate is as follows: 1. Develop the program using the Miranda system, freely using the primitives provided by Intermediate (e.g. array support) and at the same time taking into account the limitations imposed by Intermediate (e.g. the lack of support ....

P. H. Hartel and K. G. Langendoen. Benchmarking implementations of lazy functional languages. Technical report CS-92-XX, Dept. of Comp. Sys, Univ. of Amsterdam, Dec 1992.

....on such an exercise one should consider first the scope of the effects that pure space oriented thunk lifting has on some real programs. Should the effects be large, then further investigations are justified. 3 Experiments To test the effect of the thunk lifting, a number of benchmark programs [6] have been transformed, compiled and executed. The benchmark programs are applications from different areas. The benchmark set contains small and medium size programs, each of which runs on a realistic input data set. The largest program comprises 653 lines. There are a few numerical programs ....

P. H. Hartel and K. G. Langendoen. Benchmarking implementations of lazy functional languages. In 6th Functional programming languages and computer architecture, pages 341-- 349, Copenhagen, Denmark, Jun 1993. ACM.

....different architectures so as to look at architectural influences on the benchmarking procedure. A high end architecture should be avoided for benchmarking activities, as its behaviour is uneven. It is better to use a midrange machine if possible. 1 Introduction In the previous benchmark paper [10], which will be referred to as the benchmark I paper, five compilers for lazy functional languages were benchmarked. It is interesting to see what progress has been made in the development of these compilers during the past two years. The benchmark procedure has been extended to take into account ....

P. H. Hartel and K. G. Langendoen. Benchmarking implementations of lazy functional languages. In 6th Functional programming languages and computer architecture, pages 341--349, Copenhagen, Denmark, Jun 1993. ACM, New York.

No context found.

P.H. Hartel and K.G. Langedoen. Benchmarking implementations of lazy functional languages. In Proceedings FPCA, pages 341--349, 1993.

No context found.

P. Hartel, K. Langendoen. Benchmarking Implementations of Lazy Functional Languages, In Proc. of Functional Programming Languages and Computer Architecture, 1993, pp341--349.

No context found.

P. H. Hartel. Benchmarking implementations of lazy functional languages II { two years later. Technical Report CS-94-21, Dept. of Comp. Sys, Univ. of Amsterdam, December 1994.

No context found.

P. H. Hartel and K. G. Langendoen, Benchmarking implementations of lazy functional languages, in Proceedings of the 6th ACM Conference on Functional Programming Languages and Computer Architecture, ACM Press, 1993, pp. 341-350. 24

No context found.

P. H. Hartel. Benchmarking implementations of lazy functional languages II -- two years later. Technical Report CS-94-21, Dept. of Comp. Sys, Univ. of Amsterdam, December 1994.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC