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

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

Thread Previous | Thread Next
Nicholas Clark
August 3, 2011 05:45
Re: [perl #95986] [PATCH] Superficial separation of INSTRUCTION fromOP.
Message ID:
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:
> The report:
> The lastest version can be found at 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.


    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.

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

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About