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 <zr...@fastmail.com>: >> __ >> 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 <zr...@fastmail.com>: >>>> 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
