Andrew Appel. Empirical and analytic study of stack versus heap cost for languages with closures. Journal of Functional Programming, 6(1):47--74, 1996.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....We assume that each closure is given a unique activation record when it is invoked. This requires heap allocation of activation records [71] In practice this requires only a straightforward change to the code generator, and produces code that is competitive with stack allocated activation records [9]. In this section we describe how to localize scalars to a particular activation record. More specifically, we show that through this localization process we can eliminate register storage dependences between invocations of closures, enabling concurrent execution of the closures produced by scalar ....

....using the same stack pointer, then register spills by the two threads will target the same memory locations. Most contemporary computer systems allocate activation frames on a stack, rather than the heap, because stacks provide slightly lower cost deallocation than does a garbage collected heap [9]. The SUDS compiler allocates activation frames on the heap, rather than a stack, simply because it was the most natural thing to do in a compiler that was already closure converting. Thus, in the SUDS system every thread in the speculative strip gets its own, distinct, activation frame, and ....

Andrew W. Appel and Zhong Shao. Empirical and analytic study of stack versus heap cost for languages with closures. Journal of Functional Programming, 6(1), 1996.

....full detail a concrete example of how the technique works. Incidentally, this is not a toy example but rather an actual piece of the larger picture. In ML, size is a runtime concept which is not apparent in an array s type. In contrast, a C compiler will statically distinguish between types (int[3]) and (int[4] But the same e#ect can be achieved in ML. Instead of using a unary type constructor of the form # array that only talks about the array s element type # , we could try and define an new type constructor (#, #) darray that also includes a dimension component #. Arrays of di#erent ....

....has no e#ect and can safely be dropped by the optimizer. As a result, the third argument typing trick achieves its goal (communicating the C prototype to the backend) without causing any runtime overhead. 5.5. 2 Frame pointer SML NJ allocates all its stack frames (continuations) on the heap [1, 3]. As a result, it normally does not use the usual system stack for function calls. C functions, on the other hand, do use the system stack. In principle this would cause no major problems because the system stack exists even while pure ML code is running. If for nothing else, a properly set up ....

Andrew W. Appel and Zhong Shao. Empirical and analytic study of stack versus heap cost for languages with closures. J. Functional Programming, 6(1):47--74, January 1996.

....the invocation of a procedure. The semantics of a spawn differs from a C function call only in that the parent can continue to execute in parallel with the child, instead of waiting for the child to complete as is done in C. Cilk s We could have avoid this mistake had we read Appel and Shao [13]. This program uses an inefficient algorithm which runs in exponential time. Although logarithmic time methods are known [42, p. 850] this program nevertheless provides a good didactic example. #include stdlib.h #include stdio.h #include cilk.h cilk int fib (int n) if (n 2) ....

....substantially on the critical path term. On the downside, heap allocation can potentially waste more memory than stack allocation due to fragmentation. For a careful analysis of the relative merits of stack and heap based allocation that supports heap allocation, see the paper by Appel and Shao [13]. For an equally careful analysis that supports stack allocation, see [110] Thus, although the work first principle gives a general understanding of where overheads should be borne, our experience with Cilk 4 showed that large enough critical path overheads can tip the scales to the point where ....

A. W. APPEL AND Z. SHAO, Empirical and analytic study of stack versus heap cost for languages with closures, Journal of Functional Programming, 6 (1996), pp. 47--74.

....on the primary costs, namely copying and pointer maintenance. However, we cannot measure certain other costs, without integrating our implementation with a live object system. The chief of these costs is the effect on locality [Zorn, 1991; Reinhold, 1993; Goncalves, 1995; Diwan et al. 1995; Appel and Shao, 1996] The schemes that we found to perform well with respect to copying cost also share the property that they do not change the relative order of objects; think of them as compacting. Therefore, they do not adversely affect the locality of access within the mutator. Unlike traditional generational ....

Andrew W. Appel and Zhong Shao. Empirical and analytic study of stack versus heap cost for languages with closures. Journal of Functional Programming, 6(1):47--74, January 1996.

....the invocation of a procedure. The semantics of a spawn differs from a C function call only in that the parent can continue to execute in parallel with the child, instead of waiting for the child to complete as is done in C. Cilk s 2 We could have avoid this mistake had we read Appel and Shao [13]. 3 This program uses an inefficient algorithm which runs in exponential time. Although logarithmic time methods are known [42, p. 850] this program nevertheless provides a good didactic example. #include stdlib.h #include stdio.h #include cilk.h cilk int fib (int n) if (n 2) return ....

....substantially on the critical path term. On the downside, heap allocation can potentially waste more memory than stack allocation due to fragmentation. For a careful analysis of the relative merits of stack and heap based allocation that supports heap allocation, see the paper by Appel and Shao [13]. For an equally careful analysis that supports stack allocation, see [110] Thus, although the work first principle gives a general understanding of where overheads should be borne, our experience with Cilk 4 showed that large enough critical path overheads can tip the scales to the point where ....

A. W. APPEL AND Z. SHAO, Empirical and analytic study of stack versus heap cost for languages with closures, Journal of Functional Programming, 6 (1996), pp. 47--74.

....substantially on the critical path term. On the downside, heap allocation can potentially waste more memory than stack allocation due to fragmentation. For a careful analysis of the relative merits of stack and heap based allocation that supports heap allocation, see the paper by Appel and Shao [3]. For an equally careful analysis that supports stack allocation, see [73] Thus, although the work first principle gives a general understanding of where overheads should be borne, our experience with Cilk 4 showed that large enough critical path overheads can tip the scales to the point where ....

Andrew W. Appel and Zhong Shao. Empirical and analytic study of stack versus heap cost for languages with closures. Journal of Functional Programming, 6(1):47--74, 1996.

....of nondeterminism, using inlet and abort. #include stdlib.h #include stdio.h #include cilk.h cilk int fib (int n) if (n 2) return n; else int x, y; x = spawn fib (n 1) y = spawn fib (n 2) sync; return (x y) cilk int main (int argc, char argv[ int n, result; n = atoi(argv[1]) result = spawn fib(n) sync; printf ( Result: d n , result) return 0; Figure 1: A simple Cilk program to compute the nth Fibonacci number in parallel (using a very bad algorithm) The basic Cilk language can be understood from an example. Figure 1 shows a Cilk program that computes the nth ....

....substantially on the critical path term. On the downside, heap allocation can potentially waste more memory than stack allocation due to fragmentation. For a careful analysis of the relative merits of stack and heap based allocation that supports heap allocation, see the paper by Appel and Shao [1]. For an equally careful analysis that supports stack allocation, see [22] Thus, although the work first principle gives a general understanding of where overheads should be borne, our experience with Cilk 4 showed that large enough critical path overheads can tip the scales to the point where ....

Andrew W. Appel and Zhong Shao. Empirical and analytic study of stack versus heap cost for languages with closures. Journal of Functional Programming, 6(1):47--74, 1996.

....on the primary costs, namely copying and pointer maintenance. However, we cannot measure certain other costs, without integrating our implementation with a live object system. The chief of these costs is the effect on locality [Zorn, 1991; Reinhold, 1993; Goncalves, 1995; Diwan et al. 1995; Appel and Shao, 1996] The schemes that we found to perform well with respect to copying cost also share the property that they do not change the relative order of objects; think of them as compacting. Therefore, they do not adversely affect the locality of access within the mutator. Unlike traditional generational ....

Andrew W. Appel and Zhong Shao. Empirical and analytic study of stack versus heap cost for languages with closures. Journal of Functional Programming, 6(1):47--74, January 1996.

....can cause more than a factor of two performance degradation when compared to the original program, which is stack allocating activation records. We are using a simple at closure representation; more advanced closure representation techniques can signi cantly reduce the amount of allocation. [2, 3] Figure 14 shows that our CPS converted programs are allocating signi cantly more heap data 5 , which accounts for the performance di erence. Also note that programs using a safe collector with a hash table are allocating less data than programs using a safe collector with forwarding pointers. ....

Andrew W. Appel and Zhong Shao. Empirical and analytic study of stack versus heap cost for languages with closures. Journal of Functional Programming, 6(1):47{ 74, January 1996.

....can cause more than a factor of two performance degradation when compared to the original program, which is stack allocating activation records. We are using a simple flat closure representation; more advanced closure representation techniques can significantly reduce the amount of allocation. [2, 3] Figure 14 shows that our CPS converted programs are allocating significantly more heap data 5 , which accounts for the performance di#erence. Also note that programs using a safe collector with a hash table are allocating less data than programs using a safe collector with forwarding pointers. ....

Andrew W. Appel and Zhong Shao. Empirical and analytic study of stack versus heap cost for languages with closures. Journal of Functional Programming, 6(1):47-- 74, January 1996.

No context found.

Andrew Appel. Empirical and analytic study of stack versus heap cost for languages with closures. Journal of Functional Programming, 6(1):47--74, 1996.

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