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

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

Thread Previous
Reini Urban
August 4, 2011 02:59
Re: [perl #95986] [PATCH] Superficial separation of INSTRUCTION from OP.
Message ID:
2011/8/3 Nicholas Clark <>:
> 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.
> 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.
> 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.

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