develooper Front page | perl.perl5.porters | Postings from June 2008

Re: TODOs (was Re: summer of code mentor applications starting (and ending) next week)

Thread Previous | Thread Next
From:
Reini Urban
Date:
June 5, 2008 01:54
Subject:
Re: TODOs (was Re: summer of code mentor applications starting (and ending) next week)
Message ID:
6910a60806050154kdfc638dqe3be9ff398b6cd91@mail.gmail.com
2008/3/18 Jim Cromie:
> +=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

I don't think that this is such a fundamental change.
When exactly are those op_siblings pointers used now?

Not only error reporting, when I grep for op_sibling in *.c without
op.c and toke.c:

dump.c: do_op_dump - ok, no perf problem
pp_ctl.c: S_dofindlabel if a label is in a kid
pp_sort.c: pp_sort (oops!) if OPf_STACKED and OPf_SPECIAL. Very bad.
                The kid is needed there for the sortcop.
sv.c: S_find_uninit_var on OP_OPEN and OP_PUSHMARK, and also in the
general case. bad.
util.c: S_closest_cop - ok, this is for debugging and error reporting.
util.c: Perl_vmess - this is just error reporting.

-- 
Reini Urban
http://phpwiki.org/ http://murbreak.at/

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About