"M.-A. Lemburg" <mal@lemburg.com> wrote
> Damien Morton wrote:
> > Conclusions:
> >
> > While reducing the size of compiled bytecodes by about 1%, the proposed
> > modifications at best increase performance by 2%, and at worst reduce
> > performance by 3%.
> >
> > Enabling all of the proposed opcodes results in a 1% performance loss.
> >
> > In general, it would seem that adding opcodes in bulk, even if many
opcodes
> > switch to the same labels, results in a minor performance loss.
>
> The general problem with the ceval switch statement is that it
> is too big. Adding new opcodes will only make it bigger, so I doubt
> that much can be gained in general by trying to come up with new
> do-everything-in-one-opcode cases.
Each of the LOAD_FAST_N, LOAD_CONST_N, etc opcodes I added contributed only
1 line of code to the inner loop.
LOAD_FAST_0:
...
LOAD_FAST_15:
oparg = opcode - LOAD_FAST_0
LOAD_FAST:
<body of load_fast>
break
It is the growth of the switch jumptable that I suspect caused the slowdown.
Im told that, under MSVC, the switch is implemented as two tables - the
first a table of bytes, and the second a table of addresses.
If thats the case, adding non-code-bearing opcodes that direct to the same
label should only increase the switch jumptables by 1 byte for each opcode
added. If not, then the switch jumptables would increase in size by 4 bytes
or each opcode added.
Either way, there doesnt seem to be any advantage in this approach.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4