develooper Front page | perl.perl5.porters | Postings from August 2011

Re: [perl #95986] [PATCH] Superficial separation of INSTRUCTION from OP.

Thread Previous
From:
Reini Urban
Date:
August 4, 2011 02:59
Subject:
Re: [perl #95986] [PATCH] Superficial separation of INSTRUCTION from OP.
Message ID:
CAHiT=DHGW0CtnBtj_PJwD_UhU+HCRN_gn8m+FvO0Soui-6ZhWA@mail.gmail.com
2011/8/3 Nicholas Clark <nick@ccl4.org>:
> On Wed, Aug 03, 2011 at 02:11:38PM +0200, Gerard Goossen wrote:
>> On Mon, Aug 01, 2011 at 08:32:30AM -0700, Dave Mitchell via RT wrote:
>> > On Sun, Jul 31, 2011 at 03:58:17AM -0700, Gerard Goossen wrote:
>> > > Preparation for having INSTRUCTION which is different from OP.
>> > > This patch only introduces the INSTRUCTION type which is a synonym for
>> > > OP, changes function and variable definitions to use the type and
>> > > renames variables from *op to *instr.
>> >
>> > This patch changes function signatures which are part of the public API,
>> > so needs to be treated with caution.
>> >
>> > To put it in it's wider context, can you provide a link to a thread or
>> > website which describes your overall plan in more detail?
>>
>> The original proposal:
>> http://news.perlfoundation.org/2009/08/2009q3-grant-proposal-changing.html
>> The report:
>> http://news.perlfoundation.org/2010/04/grant-report-changing-the-perl.html
>>
>> The lastest version can be found at git://github.com/ggoossen/perl.git
>> in the codegen-instruction branch (it has some minor problems from
>> rebasing on the latest blead).
>
> It's still very hard from that to get any breakdown of where things
> are headed, given that the most recent change on the `codegen` branch
> is still a massive:
>
>  98 files changed, 8347 insertions(+), 6604 deletions(-)
>
> Have a missed a branch with a proposed sequence of patches for blead?
>
>> In short:
>>
>>   at compile time:
>>     The building of the op_next chain is gone.
>>     A final walk is done through the optree in finalize_optree doing
>>         required checking now done by the peephole optimizer. This
>>         step has already been added to blead.
>>
>>   before the first run time:
>>     The code generation does a walk through the optree generating a
>>         list of instruction, these instruction correspond more or less
>>         with the current op_next chain
>
> How does that fit with ithreads, where the optree is shared between threads,
> and hence can't be modified at runtime?
>
>>   at run time:
>>     Starting with the first instruction from the CV the function from
>>         the instr_ppaddr field is called. The function is responsible
>>         for returning the next instruction, until a NULL instruction is
>>         returned.
>
> I'm still extremely uncomfortable that a change this radical to the
> entire *runtime* side of the OP system is sane to make. It breaks a
> chunk of CPAN, for no proven runtime efficiency gain. The timing
> results you posted previously were not conclusive of any real speedup.
> Partly, I think, because you inverted the calling convention from
> OPs wrap new-style multi-arg functions to new-style multi-arg functions
> wrap OPs way too early, before sufficient OPs had been converted to
> avoid the thunking layer.
>
> Moreover, I don't see good prospects for it enabling future speedups.
> Unladen Swallow has failed to demonstrate that LLVM is the way to go.
> In anything, possibly the opposite. One of those working on it wrote
>
>    Unfortunately, LLVM in its current state is really designed as a
>    static compiler optimizer and back end. LLVM code generation and
>    optimization is good but expensive. The optimizations are all
>    designed to work on IR generated by static C-like languages. Most
>    of the important optimizations for optimizing Python require
>    high-level knowledge of how the program executed on previous
>    iterations, and LLVM didn't help us do that.
>
> and
>
>    LLVM also comes with other constraints. For example, LLVM doesn't
>    really support back-patching, which PyPy uses for fixing up their
>    guard side exits. It's a fairly large dependency with high memory
>    usage, but I would argue that based on the work Steven Noonan did
>    for his GSOC that it could be reduced, especially considering that
>    PyPy's memory usage had been higher.
>
> http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html
>
>
> I'm not even convinced that I'd say that the thing is production ready,
> given that (as best I can tell) you remove 2 pointers from BASEOP
> (op_next and op_ppaddr), but in turn add a structure for an instruction:
>
> struct instruction {
>    Perl_ppaddr_t       instr_ppaddr;
>    OP*                 instr_op;
>    INSTR_FLAGS         instr_flags;
>    void*               instr_arg;
> };
>
> meaning that (as best I can tell), the memory cost *for every
> instruction* is now 2 pointers more (given alignment constraints).
>
>
>
> I'd love to see a proper AST being used internally to generate (something
> close to) the existing OP structure. But I'm not confident that we've yet
> proven the case that moving from the existing OP structure is worth the
> pain.

I'm also with Nick here.

Most of B:: packages will have to be rewritten, and will be disfunctional again.

Not that I dislike the idea to rewrite it again after having it done
for the 5.10 changes,
but I'd need 1-2 years I guess, and I'm still not ready with fixing
all the 5.10 changes.

5.18 sounds like a good goal to me if we can improve it until then.
Wait. 5.6 - 5.10 -> 5.14 if we go by numbers. Skip 14, so the next
will be 18. Fine.
If we go by years, well, this will be another 10 years.
-- 
Reini

Thread Previous


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