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 w
2016-04-13 18:24 GMT+02:00 Victor Stinner :
> Demur Rumed proposes a different change to use a regular bytecode
> using 16-bit units: an instruction has always one 8-bit argument, it's
> zero if the instruction doesn't have an argument:
>
>http://bugs.python.org/issue26647
>
> According to ben
Oh nice. Did you see my recent "bytecode" project?
http://bytecode.readthedocs.io/
Victor
Le 5 mai 2016 8:30 PM, a écrit :
> Here is something I wrote because I was also unsatisfied with byteplay's
> API: https://github.com/zachariahreed/byteasm. Maybe it's useful in a
> discussion of "minimum v
Here is something I wrote because I was also unsatisfied with byteplay's
API: https://github.com/zachariahreed/byteasm. Maybe it's useful in a
discussion of "minimum viable" api for bytecode manipulation.
___
Python-Dev mailing list
Python-Dev@python.o
> 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 implem
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
> 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
Hi Raymond,
2016-04-24 21:45 GMT+02:00 Raymond Hettinger :
> 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
> 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.pyt
On 13.04.16 19:33, Guido van Rossum wrote:
Nice work. I think that for CPython, speed is much more important than
memory use for the code. Disk space is practically free for anything
smaller than a video. :-)
I collected statistics for use opcodes with different arguments during
running CPytho
...@gmail.com]
Sent: Saturday, April 16, 2016 17:05
To: python-dev@python.org
Subject: Re: [Python-Dev] Wordcode: new regular bytecode using 16-bit units
The outstanding bug with this patch right now is a regression in line numbers
causing the test for http://bugs.python.org/issue9936 to fail. I&#x
The outstanding bug with this patch right now is a regression in line
numbers causing the test for http://bugs.python.org/issue9936 to fail. I've
tried to debug it without success
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/
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
On 14 April 2016 at 08:26, Victor Stinner wrote:
> 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 p
On 2016-04-13 12:24 PM, Victor Stinner wrote:
Can someone please review the change?
+1 for the change. I can take a look at the patch in a few days.
Yury
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/py
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 yo
So code that depends on iterating through bytecode via HAS_ARG is going to
break...
Darn it. :/
--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
On Apr 13, 2016 4:44 PM, "Victor Stinner" wrote:
> Le mercredi 13
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 mig
The EXTENDED_ARG is included in the multibyte ops, I treat it just like any
other operator. Here's a snippet of my hacked-dis.dis output, which made
it clear to me that I could just count them as an "operator with word
operand."
Line 3000: x = x if x or not x and x is None else x
0001dc83 7c 00 0
What is the value of HAS_ARG going to be now?
--
Ryan
[ERROR]: Your autotools build scripts are 200 lines longer than your
program. Something’s wrong.
http://kirbyfan64.github.io/
On Apr 13, 2016 11:26 AM, "Victor Stinner" wrote:
> Hi,
>
> In the middle of recent discussions about Python perform
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
On Wednesday, April 13, 2016 09:25, Victor Stinner wrote:
> The side effect of wordcode is that arguments in 0..255 now uses 2 bytes per
> instruction instead of 3, so it also reduce the size of bytecode for the most
> common case.
>
> Larger argument, 16-bit argument (0..65,535), now uses 4 bytes
Nice work. I think that for CPython, speed is much more important than
memory use for the code. Disk space is practically free for anything
smaller than a video. :-)
On Wed, Apr 13, 2016 at 9:24 AM, Victor Stinner
wrote:
> Hi,
>
> In the middle of recent discussions about Python performance, it w
Hi,
In the middle of recent discussions about Python performance, it was
discussed to change the Python bytecode. Serhiy proposed to reuse
MicroPython short bytecode to reduce the disk space and reduce the
memory footprint.
Demur Rumed proposes a different change to use a regular bytecode
using 1
24 matches
Mail list logo
