develooper Front page | perl.perl5.porters | Postings from March 2015

Re: OP_SIGNATURE

Thread Previous | Thread Next
From:
Dave Mitchell
Date:
March 5, 2015 12:59
Subject:
Re: OP_SIGNATURE
Message ID:
20150305125941.GD28599@iabyn.com
On Wed, Mar 04, 2015 at 02:34:52PM +0000, Dave Mitchell wrote:
> No, I have shown with exact figures that OP_SIGNATURE is blisteringly
> fast, and am awaiting someone to come up with a practical example of some
> generic ops that *might* approach similar performance. Until someone comes
> up with at least one proposal, every one *apart* from me is hand-waving.

Which still no-one has done. I'm actually pretty pissed off by this.
I happen to understand in *great detail* exactly why OP_SIGNATURE is so fast,
and why a collection of discrete semi-generic ops is extremely unlikely
to be able to compete. You may not want to take this on face value, but
I think my track record of making things go faster in perl speaks for
my credibility on this specific matter. 

I am not claiming that's its impossible; I'm just claiming that I
personally can't think of anything that can. Since other people are making
assertions that it should be possible to get nearly as good performance as
OP_SIGNATURE with a combination of more generic ops, the onus is *you* to
come up with a specific proposal, which I can then either accept, tweak, or
demonstrate to be slower. And by proposal, I don't mean a vague suggestion
of a new op type, I mean a complete description of what sequence of ops a
signature should be compiled to. For example with my patch, this:

    sub f ($a, $b = 1, $c = $a++) {}

is compiled as:

    1  <;> nextstate(main 77 p:5) v:%,469762048
    2  <+> signature($a, $b=1, $c=<expr>) v
    3  <;> nextstate(main 79 p:5) v:%,469762048
    4  <0> padsv[$a:77,80] sRM
    5  <1> postinc[t4] sK/1
    6  <0> padsv[$c:79,80] sRM*
    7  <2> sassign vKS/2
    8  <;> nextstate(main 80 p:5) :%,469762048
    9  <1> leavesub[1 ref] K/REFC,1

(Note that ops 4-7 are skipped if 3 args are supplied by the caller.)

Describe the complete sequence of ops that you would compile f() to,
and for each newly-invented op, describe what it does.

If you are unwilling to do this, you should publicly concede that
OP_SIGNATURE is likely to be the fastest implementation.

P.S. for comparison, here's what f() is compiled to in vanilla 5.21.x perl:

1  <;> nextstate(main 80 p:5) v:%,469762048
2  <#> gv[*_] s
3  <1> rv2av[t24] sK/1
4  <$> const[IV 3] s
5  <2> le sK/2
6  <|> or(other->7) vK/1
7      <0> pushmark s
8      <0> pushmark sM
9      <$> const[PV "Too many arguments for subroutine at %s line %d.\n"] sM
a      <0> pushmark s
b      <$> const[IV 1] s
c      <$> const[IV 2] s
d      <0> pushmark s
e      <0> caller[t20] l
f      <2> lslice lKM/2
g      <@> sprintf[t21] sK/2
h      <@> die[t22] vK/1
i  <;> nextstate(main 80 p:5) v:%,469762048
j  <#> gv[*_] s
k  <1> rv2av[t19] sK/1
l  <$> const[IV 1] s
m  <2> ge sK/2
n  <|> or(other->o) vK/1
o      <0> pushmark s
p      <0> pushmark sM
q      <$> const[PV "Too few arguments for subroutine at %s line %d.\n"] sM
r      <0> pushmark s
s      <$> const[IV 1] s
t      <$> const[IV 2] s
u      <0> pushmark s
v      <0> caller[t15] l
w      <2> lslice lKM/2
x      <@> sprintf[t16] sK/2
y      <@> die[t17] vK/1
z  <;> nextstate(main 77 p:5) v:%,469762048
10 <#> aelemfast[*_] s
11 <0> padsv[$a:77,80] sRM*/LVINTRO
12 <2> sassign vKS/2
13 <;> nextstate(main 78 p:5) v:%,469762048
14 <#> gv[*_] s
15 <1> rv2av[t8] sK/1
16 <$> const[IV 2] s
17 <2> ge sK/2
18 <|> cond_expr(other->19) sK/1
19     <#> aelemfast[*_] s/1
           goto 1a
1q <$> const[IV 1] s
1a <0> padsv[$b:78,80] sRM*/LVINTRO
1b <2> sassign vKS/2
1c <;> nextstate(main 79 p:5) v:%,469762048
1d <#> gv[*_] s
1e <1> rv2av[t14] sK/1
1f <$> const[IV 3] s
1g <2> ge sK/2
1h <|> cond_expr(other->1i) sK/1
1i     <#> aelemfast[*_] s/2
           goto 1j
1o <0> padsv[$a:77,80] sRM
1p <1> postinc[t12] sK/1
1j <0> padsv[$c:79,80] sRM*/LVINTRO
1k <2> sassign vKS/2
1l <;> nextstate(main 80 p:5) v:%,469762048
1m <0> stub P
1n <1> leavesub[1 ref] K/REFC,1



-- 
Diplomacy is telling someone to go to hell in such a way that they'll
look forward to the trip

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