# Recursion Removal under Environments with Cache .Title Recursion Removal under Environments with

date post

18-Sep-2018Category

## Documents

view

217download

0

Embed Size (px)

### Transcript of Recursion Removal under Environments with Cache .Title Recursion Removal under Environments with

TitleRecursion Removal under Environments with Cache andGarbage Collection (Program Transformation, SymbolicComputation and Algebraic Manipulation)

Author(s) Kakehi, Kazuhiko; Futamura, Yoshihiko

Citation (2000), 1125: 1-11

Issue Date 2000-01

URL http://hdl.handle.net/2433/63587

Right

Type Departmental Bulletin Paper

Textversion publisher

Kyoto University

Recursion Removal under Environments with Cacheand Garbage Collection

Kazuhiko KAKEHI* Yoshihiko FUTAMURA\daggerGraduate School of Science and Engineering, School of Science and Engineering,

Waseda University Waseda University

Abstract

Basis of software development is to guarantee productivity and safety. Programming usingrecursion $\mathrm{a}\mathrm{n}\mathrm{d}/\mathrm{o}\mathrm{r}$ garbage collection $(\mathrm{G}\mathrm{C})$ satisfies these basis, with sacrificing execution time.Recursion removal, which transforms recursive programs into iterative ones, and improvementstoward garbage collection tackle this imbalance of advantages and disadvantages. While garbagecollection has researched intensively with showing their effects, this is not the case for recursionremoval.

This report explains recursion removal $\mathrm{b}\mathrm{r}\mathrm{i}\mathrm{n}\mathrm{g}\mathrm{s}\Leftrightarrow \mathrm{r}\sigma \mathrm{e}\mathrm{a}\mathrm{t}$ refinement toward recursive programsand also ones running with garbage collection under the current computational environmentwith cache. In our experiments, recursion-removed programs run at most 9.1 times faster thanthe original at gcc and 5.7 times faster at Common Lisp.

1 Introduction

Good software development requires productiv-ity and safety, that is, what programmers in-tend should be easily expressed in programminglanguages and programs should run as intendedwithout errors.

Programming with recursion is said to beeasy: easy to write, easy to verify and easy tomaintain; such recursively written programs un-fortunately run slowly compared with iterativeones in current computer environments. Recur-sion removal, which trarisforms recursive pro-grams into iterative ones, has therefore great im-portance, but its implementation in compilers israre except tail recursion removal.

Memory management is necessary for pro-gram execution. In imperative languages mem-ory operations like malloc and free are used.They complicate the large development, becauseprogrammers have to krlow whole lifetime of

memory areas, otherwise needed data is over-written or unnecessary data remains unnoticedforever, which results in quite hard-to-remedybugs. Under environments with garbage collec-tion (GC for abbreviation) operations for acquir-ing memory area like cons are needed for pro-grammers, because garbage collector as a sub-process collects memory areas which are not re-ferred to any more. Thus GC solves problemsof memory management and makes program-ming easy, as recursion removal is; thus newprogramming languages like Java start to adoptthis technique. As is pointed out frequently,however, programs using garbage collection runslowly.

This report, based on [10], explains throughanalysing program behaviors and experimentsthat recursion removal brings great effects on ex-ecution time, and additionally time for garbagecollection. Especially we believe the latterpoint, garbage collection, casts new viewpoint

*JSPS Research Felow, $\mathrm{k}\mathrm{a}\mathrm{z}\otimes \mathrm{f}\mathrm{u}\mathrm{t}\mathrm{a}\mathrm{n}\mathrm{u}\mathrm{r}\mathrm{a}$ . info. waseda. $\mathrm{a}\mathrm{c}$ . jp$\mathrm{t}_{\mathrm{f}\mathrm{u}\mathrm{t}\mathrm{a}\mathrm{m}}\mathrm{u}\mathrm{r}\mathrm{a}\otimes \mathrm{f}\mathrm{u}\mathrm{t}\mathrm{a}\mathrm{m}\mathrm{u}\mathrm{r}\mathrm{a}$.inf $0$ .waseda. $\mathrm{a}\mathrm{c}$ .jp

1125 2000 1-11 1

to compile-time garbage collection.This reports consists of the following sec-

tions. Section 2 shows recursion removal meth-ods and expected refinements, which will be ver-ified by experiments with gcc in the followingSection 3. Here we observe effects of recursionremoval are greatly influenced by cache. Sec-tion 4 explains improvements toward programsunder garbage collection environments and showresults at Common Lisp. Recursion removal ex-hibits good improvement both on execution and$\mathrm{G}\mathrm{C}$ , but in some cases overheads outweigh it.Section 5 summarizes related works, and finallySection 6 concludes.

2 Recursion removal

As [6] explained recursion has an advantage tomake program development easy, but iterativeprograms run faster on von Neumann-style com-puters than recursive ones. This fact drives re-searches of recursion removal from [3], but itsimplementation in compilers are quite rare ex-cept for tail recursion, which can be easily trans-lated into iteration.

2.1 Effects expected from recursionremoval

By recursion removal we can improve these threepoints.

costs of recursive calls Recursive programsneed recursive calls in their execution.This requires calling stacks and con-sumes much time for pushing and poppingthem. Iterative programs eliminate recur-sive calls, and gain faster execution.

locality of space Elimination of recursivecalls has much larger meaning for exe-cution time in current computer environ-ments. Todays processors take advantageof cache memory. Cache is a quite fast butsmall memory area closely located at theprocessor. Due to its size, programs haveto be configured to utilize it efficiently. Re-cursive programs and iterative ones have

great difference here, as the contrast isexemplified in Figure 1. Recursion failsto meet this, because recursion requiresstacks and this worsens locality. Itera-tive programs, in the contrary, only needsome fixed size of memory and refer to thearea continually, and locality of referenceis much higher than recursion.

possibility of inlining One more advantageof iterative programs are possibility to beinlined. Un-inlined subroutines are calledseparately and take time. Recursive rou-tines are not possible to be inlined, whilecompilers can inline iterative ones. Recur-sion removal eliminate this calling penal-ties.

We have also to be aware of overheads intro-duced by recursion removal. In some transla-tions, recursion removal newly introduces extracalculation or data structure, and they some-times spoil or worsen execution time.

2.2 Methods

We need to fix the aim of our recursion removal.The definition of recursion removal we give hereis: to translate recursive programs into itera-tive ones without increasing computational com-plexity and using stacks. This definition givestwo restrictions. Considering this transforma-tion aims at speed up of original programs, theformer, complexity, is quite reasonable. Thelatter, stack, is also acceptable, considering theessence of executing recursion is stacks and thatis what we want to eliminate.

Here we give an overview of recursion re-moval presented in [7]. This method, with basison accumulating parameters, aims at linear re-cursion, in which at most one recursive call ap-pears in its definition. The top left program ofFigure 2 is the general form of right linear re-cursive programs, which has a recursive call onits right side. Transformation of this target pro-gram differs from its auxiliary function $a$ . Theyutilized the following two properties of auxiliaryfunctions.

2

Figure 1: Recursive and iterative calls and their cache behavior

$f(x)=\mathrm{i}\mathrm{f}p(x)$

then $b(x)$else $a(c(X), f(d(X)))$

$floop(x)=\mathrm{i}\mathrm{f}p(x)$

floop$(X)=\mathrm{i}\mathrm{f}p(x)$ then $b(x)$then $b(x)$ else doelse do $v$ $:=c(x);w:=v;u:=x$

$v:=c(x);u:=x$ while $\neg p(d(u))$ dowhile $\neg p(d(u))$ do $u:=d(u)$

$u:=d(u)$ $w:=a(w, C(u))$$v:=h(v, u)$ odod $a(w, b(d(u)))$

return $a(v, b(d(u)))$ return $v$od od

Figure 2: Right linear recursive program $f$ (left top) and its iterative form floop using a cumulativefunction (left bottom); another iterative form floop using left-pseudo-associativity (right)

3

(1) cumulative functions We can recursionremove by finding a cumulative function $h(v, u)$of the auxiliary function $a$ . $h$ has to $\mathrm{S}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{s}\mathfrak{g}r$ un-der the condition $\neg p(u)$

$a(v, f(u))=a(h(v,u),$ $f(d(u)))$

for any expression $v$ . Note that $h$ cannot haverecursive calls to $f$ or any hee variables.

$h$ can be easily found when $a$ is associative.

$a(v, f(u))$ $=$ $a(v, a(c(u), f(d(u))))$

$=$ $a(a(v, c(u)),$ $f(d(u)))$

implies $h(v, u)=a(v, C(u))$ . Consider $g(x)$ :

$g(x)=\mathrm{i}\mathrm{f}p(_{X)}$

then $b(x)$else $c_{1}(x)+c_{2}(x)\cross g(d(x))$

The auxiliary function of $g(x)$ doesnt have asso-ciativity, but its program is recursion-removableusing two cumulative functions $h_{1}$ and $h_{2}$ intothe following form:

gloop$(_{X})=$if $p(x)$ then $b(x)$

else do$v_{1}:=c_{1}(x);v_{2}:=c_{2}(x);u:=x$

while $\neg p(d(u))$do $u:=d(u)$

$v_{1}:=h_{1}(v_{1}, v_{2}, u)$

$v_{2}:=h_{2}(v_{1}, v_{2}, u)$ odreturn $v_{1}+v_{2}\cross b(d(u))$od

with

$h_{1}(v_{1}, v_{2}, u)$ $=$ $v_{1}+v_{2}\cross c_{1}(u)$ ,$h_{2}(v_{1}, v_{2}, u)$ $=$ $v_{2^{\mathrm{X}C}2(u)}$ .

(2) $1\mathrm{e}\mathrm{f}\mathrm{t}-\mathrm{P}\mathrm{s}\mathrm{e}\mathrm{u}\mathrm{d}\mathrm{o}-\mathrm{a}\mathrm{S}\mathrm{S}\mathrm{o}\mathrm{C}\mathrm{i}\mathrm{a}\mathrm{t}\mathrm{i}_{\mathrm{V}}\mathrm{i}\mathrm{t}\mathrm{y}$ While appendis associative, the core operation cons does nothave associativity. This hinders recursion re-moval by cumulative functions. Here we focuson rplacd or rplaca, which replace cdr and carpart of the cons cell pointed by the first argu-ment with the second, an