Re: [Python-Dev] Wordcode: new regular bytecode using 16-bit units
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.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Speeding up CPython 5-10%
In the project https://github.com/zachariahreed/byteasm I mentioned on the list earlier this month, I have a pass that to computes stack usage for a given sequence of bytecodes. It seems to be a fair bit more agressive than cpython. Maybe it's more generally useful. It's pure python rather than C though. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Speeding up CPython 5-10%
Your criticisms may very well be true. IIRC though, I wrote that pass because what was available was not general enough. The stackdepth_walk function made assumptions that, while true of code generated by the current cpython frontend, were not universally true. If a goal is to move this calculation after any bytecode optimization, something along these lines seems like it will eventually be necessary. Anyway, just offering things already written. If you don't feel it's useful, no worries. On Wed, May 18, 2016, at 11:35 AM, Cesare Di Mauro wrote: > 2016-05-17 8:25 GMT+02:00 : >> In the project https://github.com/zachariahreed/byteasm I >> mentioned on >> the list earlier this month, I have a pass that to computes >> stack usage >> for a given sequence of bytecodes. It seems to be a fair bit more >> agressive than cpython. Maybe it's more generally useful. It's pure >> python rather than C though. >> > IMO it's too big, resource hungry, and slower, even if you convert > it in C. > > If you take a look at the current stackdepth_walk function which > CPython uses, it's much smaller (not even 50 lines in simple C code) > and quite efficient. > > Currently the problem is that it doesn't return the maximum depth of > the tree, but it updates the intermediate/current maximum, and *then* > it uses it for the subsequent calculations. So, the depth artificially > grows, like in the reported cases. > > It doesn't require a complete rewrite, but spending some time for fine- > tuning it. > > Regards > Cesare ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Speeding up CPython 5-10%
No problem, I did not think you were attacking me or find your response rude. On Wed, May 18, 2016, at 01:06 PM, Cesare Di Mauro wrote: > If you feel like I've attacked you, I apologize: it wasn't my > intention. Please, don't get it personal: I only reported my honest > opinion, albeit after a re-read it looks too rude, and I'm sorry > for that. > > Regarding the post-bytecode optimization issues, they are mainly > represented by the constant folding code, which is still in the > peephole stage. Once it's moved to the proper place (ASDL/AST), then > such kind of issues with the stack calculations disappear, whereas the > remaining ones can be addressed by a fix of the current > stackdepth_walk function. > > And just to be clear, I've nothing against your code. I simply think > that, due to my experience, it doesn't fit in CPython. > > Regards > Cesare > > 2016-05-18 18:50 GMT+02:00 : >> __ >> Your criticisms may very well be true. IIRC though, I wrote that pass >> because what was available was not general enough. The >> stackdepth_walk function made assumptions that, while true of code >> generated by the current cpython frontend, were not universally true. >> If a goal is to move this calculation after any bytecode >> optimization, something along these lines seems like it will >> eventually be necessary. >> >> Anyway, just offering things already written. If you don't feel it's >> useful, no worries. >> >> >> On Wed, May 18, 2016, at 11:35 AM, Cesare Di Mauro wrote: >>> 2016-05-17 8:25 GMT+02:00 : In the project https://github.com/zachariahreed/byteasm I mentioned on the list earlier this month, I have a pass that to computes stack usage for a given sequence of bytecodes. It seems to be a fair bit more agressive than cpython. Maybe it's more generally useful. It's pure python rather than C though. >>> IMO it's too big, resource hungry, and slower, even if you convert >>> it in C. >>> >>> If you take a look at the current stackdepth_walk function which >>> CPython uses, it's much smaller (not even 50 lines in simple C code) >>> and quite efficient. >>> >>> Currently the problem is that it doesn't return the maximum depth of >>> the tree, but it updates the intermediate/current maximum, and >>> *then* it uses it for the subsequent calculations. So, the depth >>> artificially grows, like in the reported cases. >>> >>> It doesn't require a complete rewrite, but spending some time for >>> fine-tuning it. >>> >>> Regards >>> Cesare >> ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 468
Is there any further thoughts on including this in 3.6? Similar to the recent discussion on OrderedDict namespaces for metaclasses, this would simplify / enable a number of type factory use cases where proper metaclasses are overkill. This feature would also be quite nice in say pandas where the (currently unspecified) field order used in the definition of frames is preserved in user-visible displays. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 468
I would be super excited for this feature, so if there's a reasonable chance of it being picked up I don't mind doing the implementation work. On Fri, Jun 10, 2016, at 11:54 AM, Eric Snow wrote: > On Thu, Jun 9, 2016 at 1:10 PM, Émanuel Barry wrote: > > As stated by Guido (and pointed out in the PEP): > > > > Making **kwds ordered is still open, but requires careful design and > > implementation to avoid slowing down function calls that don't benefit. > > > > The PEP has not been updated in a while, though. Python 3.5 has been > > released, and with it a C implementation of OrderedDict. > > > > Eric, are you still interested in this? > > Yes, but wasn't planning on dusting it off yet (i.e. in time for 3.6). > I'm certainly not opposed to someone picking up the banner. > > > > IIRC that PEP was one of the > > motivating use cases for implementing OrderedDict in C. > > Correct, though I'm not sure OrderedDict needs to be involved any more. > > > Maybe it's time for > > a second round of discussion on Python-ideas? > > Fine with me, though I won't have a lot of time in the 3.6 timeframe > to handle a high-volume discussion or push through an implementation. > > -eric ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
