Front page | perl.perl5.porters |
Postings from March 2008
On Tue, Mar 18, 2008 at 06:22:17PM +0100, Rafael Garcia-Suarez wrote:
> On 18/03/2008, Jim Cromie <jim.cromie@gmail.com> wrote:
> > Ok, Ill bite.
> >
> > these are ordered relative to each other only, Ive made no attempt to
> > grade them vs the other entries.
> >
> > feel free to discuss/dispute ..
>
> All those todoes are nice, although the "squeeze the optree" sounds a
> bit like science fiction to me.
I continue to be extremely doubtful that squeezing the optree by the method
Jim suggests will work successfully. It's adding a lot of complexity for
negative total memory saving (one has to store the map from ops to sibling
pointers somewhere), with only local positive memory saving. The necessary
extra complexity strikes me as something that bugs will love to breed in.
> > +=head2 optimize tail-calls
> > +
> > +Tail-calls present an opportunity for broadly applicable optimization;
> > +anywhere that C<< return foo(...) >> is called, the outer return can
> > +be replaced by a goto, and foo will return directly to the outer
> > +caller, saving (conservatively) 25% of perl's call&return cost, which
> > +is relatively higher than in C. The scheme language is known to do
> > +this heavily. B::Concise provides good insight into where this
> > +optimization is possible, ie anywhere entersub,leavesub op-sequence
> > +occurs.
> > +
> > + perl -MO=Concise,-exec,a,b,-main -e 'sub a{ 1 }; sub b {a()}; b(2)'
> > +
> > +Bottom line on this is probably a new pp_tailcall function which
> > +combines the code in pp_entersub, pp_leavesub. This should probably
> > +be done 1st in XS, and using B::Generate to patch the new OP into the
> > +optrees.
Will modules using caller for introspection choke on this?
What would Devel::Cover think? (being a useful piece of code that it would be
bad to break)
Nicholas Clark
Thread Previous
|
Thread Next