On Apr 23, 2016, at 8:59 AM, Serhiy Storchaka wrote:

I collected statistics for use opcodes with different arguments during running CPython tests. Estimated size with using wordcode is 1.33 times less than with using current bytecode.

[1] http://comments.gmane.org/gmane.comp.python.ideas/38293

I think the word code patch should go in sooner rather than later. Several of us have been through the patch and it is in pretty good shape (some parts still need work though). The earlier this goes in, the more time we'll have to shake out any unexpected secondary effects. perfect-is-the-enemy-of-good-ly yours, Raymond P.S. The patch is smaller, more tractable, and in better shape than the C version of OrderedDict was when it went in.

On Apr 24, 2016, at 1:16 PM, Victor Stinner wrote:

I proposed to not try to optimize ceval.c to fetch (oparg, opval) in a single 16-bit operation. It should be easy to implement it later, but I prefer to focus on changing the format of the bytecode.

Improving instruction decoding was the whole point and it was what kicked-off the work on the patch. It is also where most of the performance improvement comes from and isn't the difficult part of the patch. The persnickety parts of the patch lay elsewhere, so there is really nothing to be gained gutting out our actual objective. The OPs original patch had already gotten this part done and it ran fine for me. Raymond

On Apr 24, 2016, at 2:31 PM, Victor Stinner wrote:

2016-04-24 23:16 GMT+02:00 Raymond Hettinger :

...

...

On Apr 24, 2016, at 1:16 PM, Victor Stinner wrote: I proposed to not try to optimize ceval.c to fetch (oparg, opval) in a single 16-bit operation. It should be easy to implement it later, but I prefer to focus on changing the format of the bytecode.

Improving instruction decoding was the whole point and it was what kicked-off the work on the patch. It is also where most of the performance improvement comes from and isn't the difficult part of the patch. The persnickety parts of the patch lay elsewhere, so there is really nothing to be gained gutting out our actual objective.

The OPs original patch had already gotten this part done and it ran fine for me.

Oh wait, my phrasing is unclear. I do want optimize the (opcode, oparg) fetch, I just suggested to split the patch in two parts, and first review carefully the first part.

Unless it is presenting a tough review challenge, we should do whatever we can to make it easier on the OP who seems to be working with very limited computational resources (I had to run the benchmarks for him because his setup lacked the requisite resources). He's already put a lot of work into the patch which is pretty good shape when it arrived. The opcode/oparg fetch logic is mostly already isolated to the part of the patch that touches ceval.c. I found that part to be relatively clean and clear. The part that took the most time to go through was for peephole.c. How about we let Yury and Serhiy take a pass at it as is. And, if they would benefit from splitting the patch into parts, then perhaps one of us with better tooling can pitch in to the help the OP. Raymond

2016-04-13 23:02 GMT+02:00 Eric Fahlgren :

Percentage of 1-byte args = 96.80%

Yeah, I expected such high ratio. Good news that you confirm it.

Non-argument ops = 53,719 One-byte args = 368,787 Multi-byte args = 12,191

Again, only a very few arguments take multiple bytes. Good, the bytecode will be smaller. IMHO it's more a nice side effect than a real goal. The runtime performance matters more than the size of the bytecode, it's not like a bytecode take 4 MB. It's probably closer to 1 KB and so can probably benefit of the fatest CPU caches.

Just for the record, here's my arithmetic: byteCodeSize = 1*nonArgumentOps + 3*oneByteArgs + 3*multiByteArgs wordCodeSize = 2*nonArgumentOps + 2*oneByteArgs + 4*multiByteArgs

If multiByteArgs means any size > 1 byte, the wordCodeSize formula is wrong: - no parameter: 2 bytes - 8-bit parameter: 2 bytes - 16-bit parameter: 4 bytes - 24-bit parameter: 6 bytes - 32-bit parameter: 8 bytes But you wrote that you didn't see EXTEND_ARG, so I guess that multibyte means 16-bit in your case, and so your formula is correct. Hopefully, I don't expect 32-bit parameters in the wild, only 24-bit parameter for function with annotation.

(It is interesting to note that I have never encountered an EXTENDED_ARG operator in the wild, only in my own synthetic examples.)

As I wrote, EXTENDED_ARG can be seen when MAKE_FUNCTION is used with annotations. Victor

2016-04-13 23:23 GMT+02:00 Victor Stinner :

Hopefully, I don't expect 32-bit parameters in the wild, only 24-bit parameter for function with annotation.

I never found 32-bit parameters, and not even 24-bit ones. I think that their usage is as rare as all planets alignment. ;-) That's why with in WPython I supported only 8, 16, and 32-bit parameters (which are 6 bytes long). Regards, Cesare

Le mercredi 13 avril 2016, Ryan Gonzalez a écrit :

What is the value of HAS_ARG going to be now?

I asked Demur to keep HAS_ARG(). Not really for backward compatibility, but for the dis module: to keep a nice assembler. There are also debug traces in ceval.c which use it. For ceval.c, we might use HAS_ARG() to micro-optimize oparg=0 (hardcode 0 rather than reading the bytecode) for operators with no argument. Or maybe it's completly useless :-) Victor

2016-04-14 0:11 GMT+02:00 Ryan Gonzalez :

So code that depends on iterating through bytecode via HAS_ARG is going to break...

Sure. This change is backward incompatible for applications parsing bytecode in C or Python. That's why the patch also has to update the dis module. I don't see how you plan to keep the backwad compatibility, since the argument size changed from 2 bytes to 1 byte. You must update your code (written in C or Python or whatever). Hopefully, the dis was enhanced in Python 3.4: get_instructions() now gives nice Instructon objects rather than only pure text output. FYI I wrote my own library to decode and decode bytecode. It provides abstract bytecode objects to easily modify bytecode: https://bytecode.readthedocs.org/ I suggest to use such library (or simply the dis module for simple needs) if you have to handle bytecode, rather than writing your own code. I know a few other projects which handle directly bytecode: * https://pypi.python.org/pypi/codetransformer * https://github.com/serprex/byteplay * https://pypi.python.org/pypi/coverage IHMO it's not a big deal to update these projects for the future Python 3.6. I can even help them to support the new bytecode format. Victor

Le jeudi 14 avril 2016, Nick Coghlan a écrit :

...

IHMO it's not a big deal to update these projects for the future Python 3.6. I can even help them to support the new bytecode format.

We've also had previous discussions on adding a "minimum viable bytecode editing" API to the standard library, and updating these third party modules to support wordcode instead of bytecode could provide a good use-case-driven opportunity for defining that (i.e. it wouldn't be about providing an end user facing API directly, but rather about letting CPython take care of the bookkeeping details for things like lnotab and sorting out jump targets).

Yeah, I know well this discussion since it started with my PEP 511. I wrote the bytecode as a tool for the discussion, to try to understand better the use case. The main task was to design the API. I first looked at byteplay and codetranformer projects, but I found some issues in their design. Their API has some design issues. IMHO their API is not the best to modify bytecode. My goal is to support Bytecode.from_code(code).to_code()==code: store enough information to be able to emit again exactly the same bytecode (line numbers, exact argument value, etc.). I started with a long email, but I decided to document differences in bytecode documentation: https://bytecode.readthedocs.org/en/latest/byteplay_codetransformer.html Victor