more performance wibbles
authorNorman Ramsey <nr@cs.tufts.edu>
Sat, 12 Jun 2010 00:50:33 +0000 (20:50 -0400)
committerNorman Ramsey <nr@cs.tufts.edu>
Sat, 12 Jun 2010 00:50:33 +0000 (20:50 -0400)
1  2 
paper/dfopt.tex

diff --cc paper/dfopt.tex
@@@ -2886,16 -2885,15 +2886,16 @@@ We~don't know what difference this choi
  In \secref{engine}, the @body@ function analyzes and (speculatively)
  rewrites the body of a control-flow graph, and @fixpoint@ iterates
  this analysis until it reaches a fixed point.
 -The decorated graphs computed on earlier iterations are thrown away.
 -But for each decorated graph of $N$~nodes, it is necessary to allocate
 -at least $2N-1$~thunks.
 -We~have written a version of \hoopl\ in which this overhead is
 -eliminated by defining two separate functions: one to compute the
 +Decorated graphs computed on earlier iterations are thrown away.
 +But~for each decorated graph of $N$~nodes, it is necessary to allocate
 +at least $2N-1$~thunks, which correspond to applications of
 +@singledtonDG@ in~@node@ and of @dgSplice@ in~@cat@.
 +In~an earlier version of \hoopl, this overhead was
- eliminated by splitting @arfGraph@ into two functions: one to compute the
++eliminated by splitting @arfGraph@ into two very similar functions: one to compute the
  fixed point, and the other to produce the rewritten graph.
- Having a single version of @arfGraph@ is much simpler and easier
 -The version we present in \secref{engine} is much simpler and easier
 -to maintain, but we don't know the cost of the additional
 -allocations.
++Having a single version of @arfGraph@ is simpler and easier
 +to maintain, but we don't know the cost of allocating the
 +additional thunks.
  \item
  The representation of a forward-transfer function is private to
  \hoopl.