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
23 matches
Mail list logo
