Front page | perl.perl5.porters |
Postings from March 2008
Re: TODOs (was Re: summer of code mentor applications starting (and ending) next week)
Thread Previous
|
Thread Next
From:
Rafael Garcia-Suarez
Date:
March 18, 2008 10:22
Subject:
Re: TODOs (was Re: summer of code mentor applications starting (and ending) next week)
Message ID:
b77c1dce0803181022o4d124cfbx59313f790347d43f@mail.gmail.com
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.
> diff -ruNp -X exclude-diffs blead/pod/perltodo.pod ptodo/pod/perltodo.pod
> --- blead/pod/perltodo.pod 2008-03-17 19:29:47.000000000 -0600
> +++ ptodo/pod/perltodo.pod 2008-03-18 10:56:33.000000000 -0600
> @@ -4,10 +4,11 @@ perltodo - Perl TO-DO List
>
> =head1 DESCRIPTION
>
> -This is a list of wishes for Perl. The tasks we think are smaller or easier
> -are listed first. Anyone is welcome to work on any of these, but it's a good
> -idea to first contact I<perl5-porters@perl.org> to avoid duplication of
> -effort. By all means contact a pumpking privately first if you prefer.
> +This is a list of wishes for Perl. The tasks we think are smaller or
> +easier are listed first. Anyone is welcome to work on any of these,
> +but it's a good idea to first contact I<perl5-porters@perl.org> to
> +avoid duplication of effort, and to learn from any previous attempts.
> +By all means contact a pumpking privately first if you prefer.
>
> Whilst patches to make the list shorter are most welcome, ideas to add to
> the list are also encouraged. Check the perl5-porters archives for past
> @@ -886,6 +887,55 @@ The peephole optimier converts constants
> hash key scalars. Under ithreads, something is undoing this work. See
> See http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2007-09/msg00793.html
>
> +=head2 repack the optree
> +
> +Repacking the optree after execution order is determined could allow
> +removal of NULL ops, and optimal ordering of OPs wrt cache-line
> +filling. The slab allocator could be reused for this purpose.
> +
> +http://www.nntp.perl.org/group/perl.perl5.porters/2007/12/msg131975.html
> +
> +=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.
> +
> +=head2 squeeze the optree
> +
> +The optree is 2 intertwined linked lists, where 1st also has branches.
> +With suitable restructuring, the link overheads can be substantially
> +reduced. The 1st leap is to store op_sibling pointers in a global
> +hash, verify that they match the in-OP values, and then remove the
> +in-OP storage, thus shrinking the optree by almost 20%.
> +
> +To do this, you'll have to convert all op_sibling field accesses and
> +updates to function calls. op-sibling pointers are set during
> +bottom-up parsing/yacc-ing, and are read to establish the execution
> +order (the 2nd linked list), thereafter they are mostly unused (except
> +for error reporting) so the function overhead is rarely incurred, and
> +therefore inconsequential. In essence, the separation of hot memory
> +(the optree) from cold (the op_siblings) should improve cache
> +utilization.
> +
> +Naturally, such a fundamental change (and increase in complexity) will
> +require benchmarking to prove its value. The make test.valgrind
> +target supports cachegrinding with the test suite, but other
> +benchmarks should be used also (language shootout, spamassasin
> +regression tests, etc).
> +
> =head1 Big projects
>
> Tasks that will get your name mentioned in the description of the "Highlights
>
>
Thread Previous
|
Thread Next