Single pp OP for "if(ref($self) eq 'REFTYPE')" ?

[richardleach]

#23391 points out some inefficiencies around
getting the ref value of an SV. This issue is to break out the specific idea
of converting if ( ref($x) eq 'REFTYPE') into a single, efficient pp OP.

The currently generated optree looks like:

4     <;> nextstate(main 9 -e:1) v:%,us,{,fea=15 ->5
-     <1> null vK/1 ->d
9        <|> cond_expr(other->a) vK/1 ->e
8           <2> seq sK/2 ->9
6              <1> ref[t15] sK/1 ->7
5                 <0> padsv[$x:8,15] s ->6
7              <$> const(PV "HASH") s/BARE ->8

It could conceivably be transformed into something like:

4     <;> nextstate(main 9 -e:1) v:%,us,{,fea=15 ->5
-     <1> null vK/1 ->d
7        <|> cond_expr(other->a) vK/1 ->e
6              <2> ref_eq [... ] sK/1 ->7
5                 <0> padsv[$x:8,15] s ->6

[guest20]

Can we have an OP%s_REVERSE version to accommodate those of us who program like a jedi master?

catch {
  warn ... if 'Yoda' eq ref $self
}

[xenu]

Keep in mind that ref() has an unfortunate API that returns the class name for blessed objects. The optimised opcode has to handle that too. I'm talking about specifically this case: bless $foo, "ARRAY"

There's builtin::reftype() that doesn't have this problem. It should be optimised too.

An argument could be made that reftype() should be the only optimised function, as this is what new code should be using. But on the other hand, lots of legacy code is stuck with ref() and making it faster would be nice. I have no opinion on this.

BTW, I remember @leonerd talking about doing exactly this optimisation while he was implementing builtin::reftype(). I don't know if he didn't finish it because he didn't have time, or if there was another reason.

[Grinnz]

ref is sufficient for 99% of cases that either don't need to worry about or don't care that someone has blessed into a really dumb class name, and reftype exposing the underlying ref type of a blessed object doesn't mean it's meant to be used as such a ref, so it has the opposite potential problem. Both are certainly good candidates for optimization as they will almost always be directly compared to a string.

[guest20]

@xenu The API can be both unfortunate and fast.

[bulk88]

Even worse, while single stepping

7 <$> const(PV "HASH") s/BARE ->8 is a SVPV POK COW 255 for some reason and not a HEK*, even tho its a const literal in PP src code, and not temporary end user data (ETL/customers/financial data/etc), and will never go away for the rest of the process lifetime.

How is pp_seq() supposed to do a $lv = $rv; assignment of that SVPV POK COW 255 ptr? The SVPV POK COW 255 ptr can't replicate in this OP tree dump demo code example. I think/guestimate some libperl code somewhere, b/c it sees the COW 255 flag permutation on the SV head, then refuses to HEKify that SV* during BEGIN/CHECK phase.

[bulk88]

Can we have an OP%s_REVERSE version to accommodate those of us who program like a jedi master?

catch {
warn ... if 'Yoda' eq ref $self
}

I think, richard can correct me, but I think his idea has 2 parts, burning in if(ref($self) eq 'HASH') {} into if(SvTYPE(sv) == SVt_PVHV){}, and 2nd part, pp_ref() taking 2 PAD SV*s, 1st is PP level $self, 2nd is a const fold/optimize/collapsed RO SV* POK with 'My::Class::Base', getting rid of the push_pad_const, seq and cond_expr opcodes.

I'm scratching my head on why cond_expr OP is even needed here? can't seq have a 2 OP* tail like

struct binop {
    BASEOP
    OP *	op_first;
    OP *	op_last;
};
struct logop {
    BASEOP
    OP *	op_first;
    OP *	op_other;
};

and skip the craziness of pushing &PL_sv_yes on the PL stack, and then cond_expr having to parse that SV head with SvTRUE_NN() which is not a light weight algorithm at all.

PP(pp_cond_expr)
{
    PERL_ASYNC_CHECK();
    bool ok = SvTRUE_NN(*PL_stack_sp);
    rpp_popfree_1_NN();
    return (ok ? cLOGOP->op_other : cLOGOP->op_next);
}

[bulk88]

Keep in mind that ref() has an unfortunate API that returns the class name for blessed objects. The optimised opcode has to handle that too. I'm talking about specifically this case: bless $foo, "ARRAY"

I think the optimization you describe already exists,

perl5/pp.c

Line 547 in 5551b97

/* op is in boolean context? */

// !!!! whitespace and comments trimmed for WWW display click the link above
    if (   (PL_op->op_private & OPpTRUEBOOL)
        ||   ((PL_op->op_private & OPpMAYBE_TRUEBOOL) && block_gimme() == G_VOID)) {
        SV * const rv = SvRV(sv);
        if (SvOBJECT(rv)) {
            HV *stash = SvSTASH(rv);
            HEK *hek = HvNAME_HEK(stash);
            if (hek) {
                I32 len = HEK_LEN(hek);
                if (UNLIKELY(len == HEf_SVKEY || (len == 1 && HEK_KEY(hek)[0] == '0')))
                    goto do_sv_ref;
            }
        }
        rpp_replace_1_IMM_NN(&PL_sv_yes);
        return NORMAL;
    }

An argument could be made that reftype() should be the only optimised function, as this is what new code should be using. But on the other hand, lots of legacy code is stuck with ref() and making it faster would be nice. I have no opinion on this.

Legacy code is much higher priority IMO. Fixing it (all of CPAN) by hand or with regexps and new tarballs on PAUSE is rare, time burning, lack of volunteers, lack of company $ and company incentive by your manager at work if its a perl shop. Its better to make unmodified old code better with a magic wand from the "VM"/"System Executive"/"Hypervisor"/"Compiler", than to hand fix each code base. Waving a magic wand once to make millions of old unmodified untouched SW binaries faster has worked great for Intel and AMD for the last 45 years. Tell devs and businesses to recompile their C code for PARISC/IA64/ALPHA/MIPS .....

ARM CPUs are different since they are closed ecosystems with walled gardens, combined with a huge customer base of general public non-IT/non-Eng people that can not choose or mix n match the HW/SW stack of their phones/TVs/gaming consoles devices. If Apple picked MIPS or SH4 CPU for the Iphone 1, guess what would be the only real competitor to x86 in 2025.

For Modern Perl, new APIs/.pm'es and grammar sugar sound nice to hobby perl devs, but what incentive do current/legacy biz Perl users have to make worth updating libperl.so for their very stable current deployment env? changelog entries about CVEs at best? There is no incentive.

Perl (VM) needs perf/speed/optimization marketing entries in the Changelog every year or every other year IMO.

[Leont]

Yeah this sounds like a useful optimization.

[richardleach]

I'm scratching my head on why cond_expr OP is even needed here?

Probably simplest to leave it in - plus it will help with deparsing. There'd be no need to actually call it though.

7        <|> cond_expr(other->a) vK/1 ->e
6              <2> ref_eq [... ] sK/1 ->7
5                 <0> padsv[$x:8,15] s ->6

The new OP could either:

• Be an UNOP that returns op_next->op_next or op_next->op_other as required
• Be an UNOP_aux that stores those pointers in it's aux_buf and returns the correct one directly.

The latter option is one pointer fewer to chase, but might not be worth the added complexity.