[issue28782] SEGFAULT when running a given coroutine
Demur Rumed added the comment: I had considered this, for some reason I didn't realize code[1] could be equal to YIELD_FROM, felt it'd always be false f_lasti being -2 has always been my preference, lasti.patch lgtm -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27078] Make f'' strings faster than .format: BUILD_STRING opcode?
Demur Rumed added the comment: I don't think lack of precedence is a reason to say new opcodes are new features. More that generally new opcodes are created for new features -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue27078> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27213] Rework CALL_FUNCTION* opcodes
Demur Rumed added the comment: Since the most common use of CALL_FUNCTION_EX is.. def f(*x,*kw): other_func(*x, **kw) I've added some code to BUILD_MAP_UNPACK_WITH_CALL & BUILD_TUPLE_UNPACK to not allocate a new object if called with oparg of 1 & TOP() is correct type -- Added file: http://bugs.python.org/file43741/callfunc5.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27213> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27078] Make f'' strings faster than .format: BUILD_STRING opcode?
Changes by Demur Rumed <gunkm...@gmail.com>: -- nosy: +rhettinger ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27078> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27078] Make f'' strings faster than .format: BUILD_STRING opcode?
Changes by Demur Rumed <gunkm...@gmail.com>: -- type: enhancement -> performance ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27078> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27078] Make f'' strings faster than .format: BUILD_STRING opcode?
Demur Rumed added the comment:
I'm not understanding your message. We don't call FORMAT_VALUE on constant
strings in f"x is {x}" & FORMAT_VALUE doesn't take an argument. Are you saying
in a hypothetical FORMAT_VALUE where BUILD_STRING takes a set of objects &
applies formatting to them, thus allowing us to remove FORMAT_VALUE as an
opcode? That seems like I'm imposing my own internal thoughts on what you're
saying, but when I don't understand what someone's saying I'm prone to raise my
own imaginations. Also note that f'{x}' compiles to 'LOAD X, FORMAT_VALUE' so
there is no join lookup in the last benchmarks I posted
Nitpick about fstrtup2: it assumes compiler_joined_str's len is at least 2.
Either an assert should be added or the last if-else should be `else if (len ==
1)` instead of a plain `else`
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27078>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27078] Make f'' strings faster than .format: BUILD_STRING opcode?
Demur Rumed added the comment:
fstrtup2.patch is a bit more of an involved optimization for when we are
joining 2 strings. Instead it emits BINARY_ADD. This may be considered too
'niche' since it only triggers when the substitution occurs at the start or end
of a string & there is only one substitution
However, it reduces the "X is {x}" testcase on my machine to 4.9 usec
Interesting thing, to consider ceiling of what we can do,
Prefixing ./python -m timeit -s "x=1"
'%s'%x 1.08 usec
'%s'%(x,) 2.04 usec
str(x) 2.9 usec
f'{x}' 3.65 usec
So we should not be aiming to compete with %. It may be worthy to convert the
code to generate "x is {}".format calls tho
--
Added file: http://bugs.python.org/file43704/fstrtup2.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27078>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27078] Make f'' strings faster than .format: BUILD_STRING opcode?
Demur Rumed added the comment:
Benchmarked f'X is {x}' with BUILD_TUPLE change:
Before: 6.62 usec per loop
After: 6.33 usec per loop
f'X is {x} {x+2} {x+3}'
Before: 15.1 usec per loop
After: 14.7 usec per loop
Attached patch
--
keywords: +patch
Added file: http://bugs.python.org/file43701/fstrtup.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27078>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27078] Make f'' strings faster than .format: BUILD_STRING opcode?
Demur Rumed added the comment: The simplest perf fix is to first use BUILD_TUPLE instead of BUILD_LIST timeit 'x=1;(x,x,x)' 0.36 usec per loop timeit 'x=1;[x,x,x]' 0.425 usec per loop Introducing a new opcode BUILD_STRING to inline PyTuple_New + PyUnicode_Join to replace BUILD_TUPLE + CALL_FUNCTION should benchmark against BUILD_TUPLE version, not BUILD_LIST + CALL_FUNCTION -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27078> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27436] Strange code in selectors.KqueueSelector
Demur Rumed added the comment: Xiang: pause a moment to read the code being discussed. event before the |= is 0. You're saying flag must READ xor WRITE xor neither. Then only one if can be taken. Therefore events |= EVENT_* will always happen with events == 0, therefore it can be events = EVENT_* Further inspection of the code could move the flag/events calc into the 'if key' block -- nosy: +Demur Rumed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27436> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27213] Rework CALL_FUNCTION* opcodes
Demur Rumed added the comment: callfunc3 addresses most feedback. Doesn't address _PyEval_EvalCodeWithName2 code bloat, & I disagree with mentioning BUILD_MAP_UNPACK_WITH_CALL change in magic number update as the ABI of BUILD_MAP_UNPACK_WITH_CALL is unchanged. ie if we were to implement #27358 after this there would be no need to bump the magic number One thing which looks odd to me is the INCREF/DECREF calls on function objects surrounding calls. Especially odd is CALL_FUNCTION_EX where we finish with two calls to Py_DECREF(func). It shows up in IMPORT_NAME too -- Added file: http://bugs.python.org/file43602/callfunc3.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27213> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow
Demur Rumed added the comment: (returning None wouldn't work because that may be the key, but something like returning the dict itself (ie an unhashable) or keeping this as a C API & returning NULL would work) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27358> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow
Demur Rumed added the comment: mapaca2 heavy handily deals with the must-work-with-all-mappings by converting any non dict mappings on the stack with dicts when with_call is true I'm not sure if it'd be better to seek a less opcode centric fix-- ie introduce a method to dictobject which returns None if no collision occurs otherwise it returns the first key which collides and stops updating at that point. PyDict_DistinctUpdate -- Added file: http://bugs.python.org/file43498/mapaca2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27358> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow
Changes by Demur Rumed <gunkm...@gmail.com>: -- nosy: +serhiy.storchaka ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27358> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow
Changes by Demur Rumed <gunkm...@gmail.com>: -- components: +Interpreter Core type: -> performance versions: +Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27358> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27358] BUILD_MAP_UNPACK_WITH_CALL is slow
New submission from Demur Rumed:
BUILD_MAP_UNPACK_WITH_CALL is _really_ slow, wasting much of its time asserting
that keys are non overlapping. This patch optimizes a fast path for distinct
dicts, especially useful for #27213 where BUILD_MAP_UNPACK_WITH_CALL is
generated for a single **kw rather than needing **kw1,**kw2 to hit this slow
opcode
This patch tracks size of dictionary, if size doesn't increase by same size as
the dict we updated sum with, then we scan to find where collision is. Further
optimization can be done by scanning size of dicts to preallocate dictionary
Microbenchmark:
from timeit import timeit
def f(**x):return x
timeit(lambda:f(**{'a':2},**{'b':2}))
Unpatched takes ~15s
Patched takes ~5s
--
files: mapaca.patch
keywords: patch
messages: 268951
nosy: Demur Rumed
priority: normal
severity: normal
status: open
title: BUILD_MAP_UNPACK_WITH_CALL is slow
Added file: http://bugs.python.org/file43494/mapaca.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27358>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27213] Rework CALL_FUNCTION* opcodes
Demur Rumed added the comment: callfunc2 fixes test_dis, addresses code review, currently implements a copy of _PyEval_EvalCodeWithName as _PyEval_EvalCodeWithName2 which changes a few lines to work with new keyword stack layout so that we can use fast_function with kwargs CALL_FUNCTION_EX is benchmarking much slower (4x slower when using **kw), but unpatched hits similar perf when using multiple **kw. So most slowdown is due to BUILD_MAP_UNPACK_WITH_CALL being slow. So some patch which speeds up intersection check (eg optimize to not allocate intersection when disjoint) should greatly diminish the perf loss on this simpler implementation. I'll open a separate issue for this -- Added file: http://bugs.python.org/file43493/callfunc2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27213> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27213] Rework CALL_FUNCTION* opcodes
Demur Rumed added the comment: Attaching first iteration. Very drafty. Still need to fix test_dis; will run test suite this evening. Perf on pybench went from 16.5s to 17.5s. It was 18.3s prior to reintroducing use of fast_function. Code still needs clean up besides investigation into how to optimize Changes not described in the original patch concept: I made CALL_FUNCTION_EX oparg carry 2 flag bits on whether there's a kwdict or a vararg tuple. Code may be simpler to only have kwdict be optional. BUILD_MAP_UNPACK_WITH_CALL was modified to only use the highest bit of the 2nd byte to track where function_pos is. Most uses of BUILD_MAP_UNPACK_WITH_CALL is f(*va,**kw) so I chose to only set the highest bit when there isn't a positional unpacking. If we pushed an empty tuple then that flag bit could be removed -- keywords: +patch Added file: http://bugs.python.org/file43474/callfunc.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27213> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27213] Rework CALL_FUNCTION* opcodes
Demur Rumed added the comment: I've been working on this, may have the ceval portion mostly worked out but can't test until I finish the compile portion. Haven't had time this week, will have time to focus this weekend -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27213> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27095] Simplify MAKE_FUNCTION
Demur Rumed added the comment: Kind of amusing how visit_argannoation logic went full circle. Makes sense considering pre-mkfu patch the ABI was quite similar on that front -- Added file: http://bugs.python.org/file43362/mkfu5.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27095] Simplify MAKE_FUNCTION
Demur Rumed added the comment: mkfu4 implements #27140. It doesn't special case 1-tuples into `BUILD_MAP 1` It may be easier to have `BUILD_CONST_KEY_MAP 1` peepholed if it's really preferable to strength reduce I'm also noticing that it could've been suggested to go to the extreme with BUILD_CONST_KEY_MAP where instead of relying on peepholer to constant fold tuple, we implement constant folding const keys entirely there. Just a random thought, not a suggestion or anything else -- Added file: http://bugs.python.org/file43353/mkfu4.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27129] Wordcode, part 2
Demur Rumed added the comment: The patches LGTM & seem to be implementation of follow up ideas outlined in the first portion. It'd be good to verify that benchmarks are relatively unaffected -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27127] Never have GET_ITER not followed by FOR_ITER
Changes by Demur Rumed <gunkm...@gmail.com>: -- resolution: -> rejected status: open -> closed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27127> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27127] Never have GET_ITER not followed by FOR_ITER
Demur Rumed added the comment: I should've kept gitfit & forbegin more separated as issues. Attached is gitfit2, which only folds the GET_ITER into the comprehension if it isn't a generator so to pass test_genexps -- Added file: http://bugs.python.org/file43300/gitfit2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27127> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27127] Never have GET_ITER not followed by FOR_ITER
Demur Rumed added the comment: Didn't see Raymond's response before posting, forbegin3 at least exists as a completion of the experiment to a passes-tests state. The tracing hacks to support an instruction corresponding to two separate lines support rejecting this idea -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27127> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27127] Never have GET_ITER not followed by FOR_ITER
Demur Rumed added the comment: Attaching forbegin3.patch. It reintroduces GET_ITER for the sole purpose of eagerly throwing. I decided to reuse GET_ITER over something like TEST_ITER as this way we can have GET_ITER flow into FOR_BEGIN & rely on the fast path of iter(iter(x)) GET_ITER/JUMP_FORWARD idea doesn't work because FOR_ITER is carefully setup currently to trace as existing on 2 separate lines. If we JUMP_FORWARD into FOR_ITER then that tracing triggers & our trace will say we executed the last line of the loop immediately before executing the iteration logic -- Added file: http://bugs.python.org/file43295/forbegin3.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27127> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27127] Never have GET_ITER not followed by FOR_ITER
Changes by Demur Rumed <gunkm...@gmail.com>: Added file: http://bugs.python.org/file43271/forbegin2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27127> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27127] Never have GET_ITER not followed by FOR_ITER
Changes by Demur Rumed <gunkm...@gmail.com>: Removed file: http://bugs.python.org/file43270/forbegin2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27127> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27127] Never have GET_ITER not followed by FOR_ITER
Demur Rumed added the comment: Attached is a patch which fixes test_sys_settrace & test_pdb & test_trace. Still failing is test_genexps. I'm unsure the best way to fix this one: 1. Allow generator expressions to defer type errors about non iterables until the initial call to next 2. Create a TEST_ITER opcode entirely for generator expressions to eagerly throw 3. Generate instructions like FOR_BEGIN, if empty, jump over generator & put an empty generator on the stack -> CALL_FUNCTION 2, have generator produce code as LOAD_FAST 0, LOAD_FAST 1, , FOR_ITER repeat (ie translate stack of FOR_BEGIN from before call as header of generator) Empty generator can be created with 'LOAD_CONST (None,), FOR_BEGIN, POP' but it seems rather bad to have generators require 3 more opcodes around their creation than currently -- Added file: http://bugs.python.org/file43270/forbegin2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27127> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27236] Add CHAINED_COMPARE_OP opcode
Demur Rumed added the comment: @rhettinger can you clarify your opinion in relation to #27140 with #27095 & #27213 in mind? I agree that CHAINED_COMPARE_OP is unnecessary -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27236> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27127] Never have GET_ITER not followed by FOR_ITER
Demur Rumed added the comment: I've gotten most tests to past by having FOR_ITER be traced as if the instruction index is that of the corresponding FOR_BEGIN. test_sys_settrace still fails on test_15_loops because an empty loop body doesn't have the 'pass' line traced (ie when FOR_ITER starts the line) which I'm currently pondering ways around The first patch, which only moved GET_ITER into the closure, would still be good for list/set/dict comprehensions (to help PREDICT & JITs) If there's essentially a decision that all loops should have JUMP_ABSOLUTE to their beginning for the sake of tracing simplicity, then FOR_BEGIN/FOR_ITER are dead -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27127> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27213] Rework CALL_FUNCTION* opcodes
Demur Rumed added the comment: I'd like to take on creating a patch for this proposal once #27140 lands -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27213> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17611] Move unwinding of stack for "pseudo exceptions" from interpreter to compiler.
Demur Rumed added the comment: Java duplicates finally bytecode too: http://cliffhacks.blogspot.ca/2008/02/java-6-tryfinally-compilation-without.html Tho they avoid jsr instruction because it causes non trivial bytecode validation. Still, they would've had to concluded that finally blocks are often small enough to be alright to inline -- nosy: +Demur Rumed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue17611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27140] Opcode for creating dict with constant keys
Demur Rumed added the comment: When is this intended to be merged? I've been waiting on this before updating the patch @ #27095 with fixes to other code review comments -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27140> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27140] Opcode for creating dict with constant keys
Demur Rumed added the comment: Perhaps BUILD_CONST_KEY_MAP? Ideally the opcode could ellide the LOAD_CONST for the tuple. ie have LOAD_CONST 2 (1, 2, 3), BUILD_CONST_KEY_MAP 3 be BUILD_CONST_KEY_MAP 2 (1, 2, 3). However that'd require stack_effect to somehow lookup the const tuple Thinking to in the context of MAKE_FUNCTION, I'd like to create a function for ceval which takes stack_pointer & returns stack_pointer at new offset with dict at top of stack. Then use this both for this opcode & have MAKE_FUNCTION call it directly (ie, don't have to emit BUILD_MAP_EX). This too makes for a need to do some backtracking to figure out stack effect Relying on the peepholer seems unideal; it does more work than generating the tuple the first time & doing it eagerly will produce a more compact stack depth & co_consts -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27140> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27127] Never have GET_ITER not followed by FOR_ITER
Demur Rumed added the comment: Two issues: One: `a = (i for i in 6)` does not throw until calling next(a). This applies to the first patch. If it's unacceptable to defer the throw then this whole issue should be closed unless there's interest in having a GET_ITER, FOR_ITER, FOR_BEGIN, FOR_NEXT set of opcodes between comprehensions & for loops. That seems excessive Two: tracing is getting a bit confused by FOR_ITER being at the end of the loop body. The clearest example is that in test_pdb's test_pdb_until_command_generator it needs 3 steps instead of 2 to trace `print(i)` after the 'until 4' because whereas currently it traces the `for i in test_gen()` before calling into the iterator, it now calls into the iterator first & traces `for i in test_gen()` only after returning. Additionally it doesn't trace `for i in test_gen()` at the end of iteration, instead tracing the last line It seems fragile to try fix this up by having the FOR_ITER tail receive a negative lnotab line offset to place it on the same line as the loop heading. My own research of the code base has been trying to determine if I can manually emit a trace in the FOR_ITER opcode, but I'd rather not muck with the frame to carry out this façade -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27127> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27127] Never have GET_ITER not followed by FOR_ITER
Demur Rumed added the comment: Summer heat is getting to me. Please ignore this issue until I've uploaded a fixed patch -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27127> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27127] Never have GET_ITER not followed by FOR_ITER
Demur Rumed added the comment:
Microbenchmark of continue regression: timeit("for a in range(256):\n\tif
a:continue",number=10)
Without patch: ~3.57
With patch: ~3.64
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27127>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27127] Never have GET_ITER not followed by FOR_ITER
Demur Rumed added the comment:
Pretty small perf increase:
timeit("for a in range(256):pass", number=10)
Without patch: ~2.1
With patch: ~1.84
pybench is 1-2% faster. Would prefer others' results. Especially a benchmark
where it doesn't wrap payloads in for loops
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27127>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27127] Never have GET_ITER not followed by FOR_ITER
Demur Rumed added the comment: Currently it'll work since in an except it'll generate a CONTINUE_LOOP that'll jump to the end of the loop & either jump back to the start or to the end Your example is incorrect. If the continue's JUMP_ABS were a FOR_ITER then if we were on the last iteration of the loop we would end up executing the loop body with an invalid stack. So you'd have to follow the FOR_ITER with a JUMP_ABS past the loop. Not sure if there's a speed advantage worth complexity/larger wordcode -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27127> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27129] Wordcode, part 2
Changes by Demur Rumed <gunkm...@gmail.com>: Removed file: http://bugs.python.org/file43048/forbegin.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27127] Never have GET_ITER not followed by FOR_ITER
Demur Rumed added the comment: Attached is the larger potential change of replacing GET_ITER/FOR_ITER with FOR_BEGIN/FOR_ITER. I took awhile to getting this put together due to missing that CONTINUE_LOOP was jumping to the top of the loop, skipping past FOR_ITER -- Added file: http://bugs.python.org/file43049/forbegin.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27127> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27129] Wordcode, part 2
Demur Rumed added the comment: Oops wrong issue, sorry. Please delete? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27129] Wordcode, part 2
Demur Rumed added the comment: Attached is the larger potential change of replacing GET_ITER/FOR_ITER with FOR_BEGIN/FOR_ITER. I took awhile to getting this put together due to missing that CONTINUE_LOOP was jumping to the top of the loop, skipping past FOR_ITER -- Added file: http://bugs.python.org/file43048/forbegin.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27129] Wordcode, part 2
Demur Rumed added the comment: https://github.com/search?q=f_lasti=Code Popular use of f_lasti is checking it for -1, checking the instruction at the byte offset of f_lasti, checking the argument with code[f_lasti+1] (Some bad code checking f_lasti+3 which'll break with 3.6) abarnert discussed how bytecode should be typed to Python code. Ideally it'd be typed as a "(instruction, arg)" tuple. He considered creating a "words" type similar to "bytes" but with 16 bit values. It's a bit niche to introduce a builtin for. So if the co_code object is remaining a bytes object then it seems intuitive to keep f_lasti as a bytes offset. Clashes with jump offsets no longer being a bytes offset even in Python code tho In reality most of the results on github all seem to be copying a few distinct uses. So maybe backwards compatibiltiy isn't so important Other search https://searchcode.com/?q=f_lasti=0=1=3=7=1=19 doesn't produce many results either -- nosy: +Demur Rumed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27129> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27097] ceval: Wordcode follow up, explicit unsigned short read
Demur Rumed added the comment: PREDICT could be optimized by having a HAS_ARG check on the constant op to decide whether we assign oparg = OPARG(word) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27097> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27127] Never have GET_ITER not followed by FOR_ITER
New submission from Demur Rumed: This is a small change to comprehensions pass in their iterable rather than calling GET_ITER before CALL_FUNCTION. This makes it so that the compiler never generates GET_ITER without following it with FOR_ITER, nor does it generate FOR_ITER without preceding it by GET_ITER This is the standalone portion of a more constructive patch I'm wanting to submit: Replace GET_ITER with a FOR_BEGIN which effectively acts as GET_ITER/FOR_ITER. Then modify FOR_ITER to replace the JUMP_ABSOLUTE by changing it to a JABS instruction which jumps if the iterator does not return null. This reduces the bytecode of by 2 bytes for every for loop & reduces the dispatch count per loop by 1 (As we merge GET_ITER/FOR_ITER & JUMP_ABSOLUTE/FOR_ITER) -- components: Interpreter Core files: gitfit.patch keywords: patch messages: 266400 nosy: Demur Rumed priority: normal severity: normal status: open title: Never have GET_ITER not followed by FOR_ITER type: performance versions: Python 3.6 Added file: http://bugs.python.org/file43006/gitfit.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27127> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] ceval: use Wordcode, 16-bit bytecode
Demur Rumed added the comment: A documentation touch up for EXTENDED_ARG is included in #27095 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27097] ceval: Wordcode follow up, explicit unsigned short read
Demur Rumed added the comment: There's some difficulty in changing next_instr to an unsigned short* unless pointer arithmetic converts it back to unsigned char*. Code relies on f_lasti to be a byte index more than it relies on f_lasti to be -1 at first. Should this change include converting jump offsets to word increments? This patch seeks to be a minimal change to achieve the desired aligned/batched memory read behavior of NEXTOP/NEXTARG. Perhaps a clear description of how deep the changes should be is in order It's also a bit hard to assert pointer alignment without failling back to stdint's uintptr_t. It may be sufficient to assert f_lasti is an even number -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27097> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27097] ceval: Wordcode follow up, explicit unsigned short read
Demur Rumed added the comment: There is no strict aliasing issues because aliasing is explicitly allowed for char buffers. The only issue is unaligned memory reads, but allocations are well aligned, so there'd have to be explicit work to allocate & then put code at an uneven offset. CPython never does this. This leaves the only issue being if a jump has an uneven jump offset. But jumping into the middle of an instruction is already undefined behavior because if I jump into a byte that happens to be BINARY_ADD on an empty stack it's undefined behavior. Jumping into the middle of an instruction thus falls under "Undefined behavior due to invalid bytecode" tl;dr There is no undefined behavior given correct bytecode layout, & we already have undefined behavior given incorrect bytecode layout. PREDICT concerns may be valid; the solution there may be to have a PEEKOPARG which we can then check the short value before splitting it if the opcode portion matches -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27097> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27095] Simplify MAKE_FUNCTION
Demur Rumed added the comment: May've been best to wait on posting a patch, but long weekend yesterday made time available mkfu3 updates mkfu2 with wordcode. Includes fix to EXTENDED_ARG documentation -- Added file: http://bugs.python.org/file42965/mkfu3.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27093] Silence warning in cjkcodecs.h
Changes by Demur Rumed <gunkm...@gmail.com>: -- components: +Extension Modules ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27093> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27097] ceval: Wordcode follow up, explicit unsigned short read
New submission from Demur Rumed: Attached is a patch based off #26647 which converts ceval to read opcode/oparg by casting next_instr to an unsigned short. I don't believe we need to complicate the code with checking the pointer alignment of the instruction stream; some effort must be gone through to generate bytecode off alignment, & if the issue comes up it's because someone's using the C API on a CPU that doesn't support unaligned reads to generate their own custom bytecode. Anyways pybench went from 16.5 on wordcode to 16.0 for me The change works through replacing NEXTOP/NEXTARG with a NEXTOPARG macro -- components: Interpreter Core files: ushort.patch keywords: patch messages: 266209 nosy: Demur Rumed priority: normal severity: normal status: open title: ceval: Wordcode follow up, explicit unsigned short read type: performance versions: Python 3.6 Added file: http://bugs.python.org/file42961/ushort.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27097> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27095] Simplify MAKE_FUNCTION
Demur Rumed added the comment: Attached are modifications to the patch based on feedback from Nikita. It produces a larger patch tho. The changes are to combine return branches in compiler_make_closure & to combine code between compiler_function & compiler_lambda into compiler_default_arguments -- Added file: http://bugs.python.org/file42960/mkfu2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27095] Simplify MAKE_FUNCTION
Changes by Demur Rumed <gunkm...@gmail.com>: -- versions: +Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27095] Simplify MAKE_FUNCTION
New submission from Demur Rumed: Implemented as per https://mail.python.org/pipermail/python-dev/2016-April/144135.html -- files: mkfu.patch keywords: patch messages: 266187 nosy: Demur Rumed priority: normal severity: normal status: open title: Simplify MAKE_FUNCTION type: performance Added file: http://bugs.python.org/file42959/mkfu.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27095> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27093] Silence warning in cjkcodecs.h
New submission from Demur Rumed: gcc6 now warns about indentation of code. find_paireencmap raised such warnings. This patch silences that warning while updating the code to be more PEP7 friendly wrt curlies -- files: cjkcodecs.patch keywords: patch messages: 266148 nosy: Demur Rumed priority: normal severity: normal status: open title: Silence warning in cjkcodecs.h type: compile error versions: Python 3.6 Added file: http://bugs.python.org/file42955/cjkcodecs.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27093> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] ceval: use Wordcode, 16-bit bytecode
Demur Rumed added the comment: Removes 0 <= unsigned assertion & fixes j < 0 check to avoid overflow bug -- Added file: http://bugs.python.org/file42950/wpyD.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] ceval: use Wordcode, 16-bit bytecode
Demur Rumed added the comment: I have verified that wpyC does not produce signed/unsigned warnings with make DEBUG=1 -- Added file: http://bugs.python.org/file42949/wpyC.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] ceval: use Wordcode, 16-bit bytecode
Demur Rumed added the comment: Sorry for the nuisance of uploading another patch so soon. wpyB modifies test_ctypes now that __phello__ is smaller, & fixes a typo in a comment I made & removes a blank line I had added in when adding in if(0) logic -- Added file: http://bugs.python.org/file42948/wpyB.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] ceval: use Wordcode, 16-bit bytecode
Demur Rumed added the comment: I've tracked down the lnotab issue after modifying master/wpy to not vacuum NOPs. Old code puts LOAD_CONST at after NOPs, on the same line as return op, whereas new code is putting LOAD_CONST before NOPs, on it's own line I've attached a fix along with addressing compiler warnings & __phello__ & adding some asserts that make sure we aren't passing indices that point inside instructions to peephole's helper functions -- Added file: http://bugs.python.org/file42946/wpyA.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] ceval: use Wordcode, 16-bit bytecode
Demur Rumed added the comment: Compiler warnings can be fixed by using h instead of j in case RETURN_VALUE & casting CONST_LEN() to unsigned is safe As for the failing tests: I've finally figured out how to use Tools/freeze to fix __phello__ et al. I've brought up the trace test failure a few times, essentially return (1, 2, 3) compiles to LOAD_CONST (1,2,3) being on separate line than the RETURN_VALUE whereas previously it did not. This issue does not occur for return """1, 2, 3""" Leading me to believe peephole has missed some detail in ltotab handling -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] ceval: use Wordcode, 16-bit bytecode
Demur Rumed added the comment: Based on serhiy's LGTM I'm uploading hopefully final touches based on his feedback New in this are changes to Makefile.pre & PCbuild files. I can't really test PCbuild but I did test that make followed by modifying wordcode_helpers.h followed by make rebuilds peephole & compile. There's now also modification of PC/launcher.c to include 3370 as 3.6 Doc/library/dis.rst: I've reverted changes to HAVE_ARGUMENT description since most of my 'pedantic' changes to differentiate between using arguments & ignoring arguments have been reverted -- Added file: http://bugs.python.org/file42935/wpy9.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] ceval: use Wordcode, 16-bit bytecode
Demur Rumed added the comment: I've replaced wpy8 which I uploaded a few days ago as the previous version had a blank line removed from dis.rst by accident -- Added file: http://bugs.python.org/file42886/wpy8.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] ceval: use Wordcode, 16-bit bytecode
Changes by Demur Rumed <gunkm...@gmail.com>: Removed file: http://bugs.python.org/file42835/wpy8.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] ceval: use Wordcode, 16-bit bytecode
Changes by Demur Rumed <gunkm...@gmail.com>: Added file: http://bugs.python.org/file42835/wpy8.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] ceval: use Wordcode, 16-bit bytecode
Demur Rumed added the comment: I've been waiting on storchaka to finish code reviewing peephole based on his statement of 'Reviewing peephole.c still is not completed.' before uploading a patch which addresses the issues raised since -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] ceval: use Wordcode, 16-bit bytecode
Demur Rumed added the comment: I should mention a change in dis which hasn't come up for the sake of explicit discussion: I modified dis to not print EXTENDED_ARG. Instead one can tell by the byte indices having a hole (since they uniformly count up by 2 otherwise) & the argument value being greater than 255 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] ceval: use Wordcode, 16-bit bytecode
Demur Rumed added the comment: Plain git diff formatted patch. I installed mercurial but then `hg clone https://hg.python.org/cpython` failed twice over weird protocol errors (2nd one had to do with negative length) so I gave up -- Added file: http://bugs.python.org/file42659/wpy7.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] ceval: use Wordcode, 16-bit bytecode
Demur Rumed added the comment: I should be able to submit a wpy7.patch this evening, though I was never able to generate a patch in the format you prefer. Should I fall back to piping git diff? At this point it may be better if you take in the last suggestions as I'd probably end up removing TARGET_WITH_IMPL & then there'd be debate about that being unnecessary To be clear: I'll upload a wpy7.patch this evening, & you can decide whether to create your own patch from wpy6 or wpy7 or accept wpy7. In the meantime if you just update wpy6 then all well. Sorry for not being very straight forward -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23507] Tuple creation is too slow
Demur Rumed added the comment: This code could be made to look a lot less hackish if the potential tuple reuse was abstracted by a PyTuple_UniqueOrNew(PyTuple) which returns its argument if REFCNT==1 otherwise allocates a tuple of the same size & returns that. It decrefs PyTuple if REFCNT != 1 -- nosy: +Demur Rumed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23507> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] ceval: use Wordcode, 16-bit bytecode
Demur Rumed added the comment: Made changes from code review, did a little extra on fixing up type consistency, not sure if this is exactly the patch format you wanted; I tried `git difftool --extcmd='diff -u' python/master` but it's listing the original files as being from /tmp I've updated modulefinder with haypo's index patch except in the context of wordcode -- Added file: http://bugs.python.org/file42453/wpy5.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26722] Fold compare operators on constants (peephole)
Demur Rumed added the comment: I submitted a patch years ago that addressses the ''x,y = 1, 2' case: http://bugs.python.org/issue10648 & it was not met with enthusiasm 2016-04-10 5:08 GMT+00:00 Alexander Marshalov <rep...@bugs.python.org>: > > Alexander Marshalov added the comment: > > Hi all, this is my first patch to Python. > I'm interested in the performance of python code, I even worked on the > development of the static optimizer based on modifications of the AST. > I had a few ideas for improving peepholer (for example, the expression "x, > y = 1, 2" according to my benchmarks is about 7-11% slower than the > expression "x = 1; y = 2", this can be fixed by using a peepholer), but I > already understood that it is not necessary to do it. > Thanks for the clarification, I will continue to work towards > AST-optimizations. > > -- > > ___ > Python tracker <rep...@bugs.python.org> > <http://bugs.python.org/issue26722> > ___ > -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26722> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] ceval: use Wordcode, 16-bit bytecode
Demur Rumed added the comment: [12:36] Could I get a code review for wordcode's 4th patchset? http://bugs.python.org/review/26647/#ps16875 ... [13:13] serprex: you'd be better off bumping the issue -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26722] Fold compare operators on constants (peephole)
Demur Rumed added the comment: Do you have any numbers on how common constant comparisons are in real code? -- nosy: +Demur Rumed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26722> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] ceval: use Wordcode, 16-bit bytecode
Demur Rumed added the comment: Got f_lasti working as -1. Applied PEP7. Unrelated: fixed a misnamed variable in test_grammar because it ran into a peephole bug (const -> jump_if_false erase didn't work when EXTENDED_ARGs were involved). dis has argval/arg set to None instead of the unused argument value Things are seeming more brittle with f_lasti as -1. But maybe it's all in my head -- Added file: http://bugs.python.org/file42353/wpy4.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] ceval: use Wordcode, 16-bit bytecode
Changes by Demur Rumed <gunkm...@gmail.com>: Added file: http://bugs.python.org/file42339/wpy3.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] ceval: use Wordcode, 16-bit bytecode
Changes by Demur Rumed <gunkm...@gmail.com>: Removed file: http://bugs.python.org/file42338/wpy3.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] ceval: use Wordcode, 16-bit bytecode
Demur Rumed added the comment: Addressed feedback from josh.rosenberg besides reintroducing FOURTH/SET_FOURTH -- Added file: http://bugs.python.org/file42338/wpy3.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] ceval: use Wordcode, 16-bit bytecode
Demur Rumed added the comment: Added back HAVE_ARGUMENT & HAS_ARG. As a result printing has removed arguments Removed some code which was labelled unrelated This does _not_ include having f_lasti be -1 instead of -2 -- Added file: http://bugs.python.org/file42331/wpy2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] ceval: use Wordcode, 16-bit bytecode
Demur Rumed added the comment: While it's good to know benchmarking in core Python goes beyond the microbenchmarks included in the distribution, I'm having some trouble with hg.python.org/benchmarks due to my system only having 256MB of ram I've attached results for 2 benchmarks: 2to3 & regex -- Added file: http://bugs.python.org/file42328/2to3re.txt ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] ceval: use Wordcode, 16-bit bytecode
Demur Rumed added the comment: To clarify format of extended arg listings: 1st column is the number of instances of EXTENDED_ARG being emitted, 2nd column is length of bytecode, followed by filename The previous numbers were of modules, which generally are run-once and listing many constants. I've attached a modification where instead I iterated over the code objects inside co_consts from compiling the *.py file. Trunk currently only emits EXTENDED_ARGs for classes (Pdb, & then the rest in Lib/typing.py) so I've omitted it -- Added file: http://bugs.python.org/file42325/exarg_in_funcs.txt ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] ceval: use Wordcode, 16-bit bytecode
Demur Rumed added the comment: I've attached some benchmarking results as requested There is 1 failing test which doesn't fail in master for test_trace; the unit test for #9936 -- Added file: http://bugs.python.org/file42324/wcpybm.txt ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] Wordcode
Changes by Demur Rumed <gunkm...@gmail.com>: -- nosy: +abarnert ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] Wordcode
Demur Rumed added the comment: I'll dig up benchmark results when I get home, but I'd be interested to get results on a less wannabe RISC CPU The change is to have all instructions take an argument. This removes the branch on each instruction on whether to load oparg. It then also aligns instructions to always be 2 bytes rather than 1 or 3 by having arguments only take up 1 byte. In the case that an argument to an instruction is greater than 255, it can chain EXTENDED_ARG up to 3 times. In practice this rarely occurs, mostly only for jumps, & abarnert measured stdlib to be ~5% smaller The rationale is that this offers 3 benefits: Smaller code size, simpler instruction iteration/indexing (One may now scan backwards, as peephole.c does in this patch), which between the two results in a small perf gain (the only way for perf to be negatively impacted is by an increase in EXTENDED_ARGs, when I post benchmarking I'll also post a count of how many more EXTENDED_ARGs are emitted) This also means that if I want to create something like a tracer that tracks some information for each instruction, I can allocate an array of codesize/2 bytes, then index off of half the instruction index. This isn't currently done in peephole.c, nor does this include halving jump opargs I've looked up the 'recent work to cache attribute/global lookup' issue I mentioned: http://bugs.python.org/issue26219 I believe that patch would benefit from this one, but it'd be better to get Yury's opinion that belief -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26659] slice() leaks memory when part of a cycle
Demur Rumed added the comment: Implementing tp_traverse & tp_clear seems to runs into complications due to slice_cache -- nosy: +Demur Rumed ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26659> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26543] imaplib noop Debug
Demur Rumed added the comment: Fixes syntax & line length issues in previous patch -- Added file: http://bugs.python.org/file42312/imaplib2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26543> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] Wordcode
Demur Rumed added the comment: Also missing from this patch is modification of the bytecode magic number -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26543] imaplib noop Debug
Demur Rumed added the comment: I've attached a patch file of the proposed change which seems correct -- keywords: +patch nosy: +Demur Rumed Added file: http://bugs.python.org/file42310/imaplib.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26543> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26647] Wordcode
New submission from Demur Rumed: Originally started @ https://github.com/abarnert/cpython/tree/wpy This patch is based off of https://github.com/serprex/cpython/tree/wpy It omits importlib.h & importlib_external.h as those are generated It omits https://github.com/serprex/cpython/blob/wpy/Python/wordcode.md I got around to benchmarking against building on master rather than using my repo's packaged version, it's currently a 1% speed improvement (every bit counts). I'm testing on an Intel Atom 330 with Linux. Besides the minor perf increase, it generates smaller bytecode & is simpler (peephole now handles EXTENDED_ARG since it isn't too hard to track & while loops become for loops in dis) Previous discussion: https://mail.python.org/pipermail/python-dev/2016-February/143357.html pdb works without changes. coverage.py doesn't seem to rely on anything this changes I modified byteplay to target this change mostly over the course of half an hour before work: https://github.com/serprex/byteplay/blob/master/wbyteplay.py I'd be interested to hear if this encoding simplifies things for FAT python & the recent work to cache attribute/global lookup Remaining code issues: peepholer could allocate half the space as it does now for basic block tracking, compile.c & peephole.c repeat themselves on computing instruction size given an argument & how to spit out an instruction given an argument Breaking change in dis: I've removed HAVE_ARGUMENT. This is to help code fail fast. It could be replaced with IGNORES_ARGUMENT or, as abarnert suggested, a range(90,256) named after the other hasXXXs 'hasarg' -- components: Interpreter Core files: wpy.patch keywords: patch messages: 262501 nosy: Demur Rumed priority: normal severity: normal status: open title: Wordcode type: performance versions: Python 3.6 Added file: http://bugs.python.org/file42300/wpy.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10648] Extend peepholer to reverse loads or stores instead of build/unpack
New submission from Demur Rumed junkm...@hotmail.com: This modifies the peepholer's BUILD/UNPACK_SEQUENCE for the case when all stores are simple, or all loads are simple It first scans to see if the pushing is done with simple LOADs. If so, it reverses the loads and removes the build unpack. If not, it scans ahead to see if it is followed by simple STOREs. If so, it reverses the stores and removes the build unpack -- components: Interpreter Core files: peep.diff keywords: patch messages: 123588 nosy: serprex priority: normal severity: normal status: open title: Extend peepholer to reverse loads or stores instead of build/unpack type: performance versions: Python 3.2 Added file: http://bugs.python.org/file19974/peep.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10648 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9843] imp documentation redundancy with acquire_lock and release_lock
New submission from Demur Rumed junkm...@hotmail.com: http://docs.python.org/dev/library/imp.html acquire_lock and release_lock are listed twice. The first iteration of acquire_lock repeats On platforms without threads, this function does nothing. twice and advises release, while the latter does not -- assignee: d...@python components: Documentation messages: 116267 nosy: d...@python, serprex priority: normal severity: normal status: open title: imp documentation redundancy with acquire_lock and release_lock ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9843 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9843] imp documentation redundancy with acquire_lock and release_lock
Demur Rumed junkm...@hotmail.com added the comment: That doesn't appear to remove the repetition of their listing. Something I failed to mention: The duplication occurs after imp.reload -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9843 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9225] Replace DUP_TOPX with DUP_TOP_TWO
New submission from Demur Rumed junkm...@hotmail.com: DUP_TOPX(3) is never used, nor is ROT_FOUR. This patch removes the opcodes, replacing DUP_TOPX with DUP_TOP_TWO Oddly, at least with pybench, use of PREDICT(BINARY_SUBSCR) in DUP_TOP_TWO seems to show an always right PREDICT as slower than FAST_DISPATCH -- components: Interpreter Core files: duptoptwo.patch keywords: patch messages: 110035 nosy: serprex priority: normal severity: normal status: open title: Replace DUP_TOPX with DUP_TOP_TWO type: performance Added file: http://bugs.python.org/file17949/duptoptwo.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9225 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9225] Replace DUP_TOPX with DUP_TOP_TWO
Changes by Demur Rumed junkm...@hotmail.com: -- versions: +Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9225 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9155] Reserve COMPARE_OP for rich comparisons
Demur Rumed junkm...@hotmail.com added the comment: The seperation of COMPARE_OP into multiple opcodes shouldn't affect cache size since the opcodes are aliased. Spreading out the switch statement shouldn't cause issue from flattening, since GCC would inline the single use of cmp_outcome. Thus the only bloat is the wrapper overhead, which I believe the C code is relatively large with respect to the macros. As for DUP_TOP_TWO, that's smaller than DUP_TOPX It may be suitable to benchmark on other systems besides my own due to the subversive nature of caches; I've seen improvement in any code that uses comparisons. To consider, however, is that ceval.o dropped from 268592B to 267448B. This is reflected in that the interpreter's executable dropped from 6721842B to 6719866B Raymond, what do you mean with respect to the peepholer? I believe my changes there have shown it to be a simplification of the code -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9155] Reserve COMPARE_OP for rich comparisons
Demur Rumed junkm...@hotmail.com added the comment: Replaced TARGET_DUP_TOPX with _unknown_opcode I recompiled with --with-computed-gotos, and the results remain promising, though the interpreter instead grows from 6756023B to 6765167B -- Added file: http://bugs.python.org/file17903/cmpoprotdupalluny3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9155] Reserve COMPARE_OP for rich comparisons
Demur Rumed junkm...@hotmail.com added the comment: I've fixed the segfaulting in IN and NOT_IN, though the code requires cleaning due to the obtusely cargo culted nature of those opcodes I'm also including an incrementation which completely removes COMPARE_OP, using the opcode to determine the comparison type. As a result, I found it safe to remove the PyCmp_ enum, though cpickle seems to disagree. It's also lacking performance wise -- Added file: http://bugs.python.org/file17866/cmpoprotdupalluny.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9155] Reserve COMPARE_OP for rich comparisons
Demur Rumed junkm...@hotmail.com added the comment: It seems the lack of benefits from replacing COMPARE_OP with a set of aliased bytecodes was repairable through TARGET_WITH_IMPL. Also fixed was the lack of amendments to dis -- versions: -Python 3.3 Added file: http://bugs.python.org/file17876/cmpoprotdupalluny2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9155] Reserve COMPARE_OP for RichComparisons
New submission from Demur Rumed junkm...@hotmail.com: Currently, COMPARE_OP is burdened by a needless, and unorthogonal, extra layer of indirection. I've modified it to only handle the rich comparison case, moving the other five cases to BINARY_IN, BINARY_NOT_IN, BINARY_IS, BINARY_IS_NOT, and BINARY_EXC_MATCH To consider is inlining the POP_JUMP_IF_FALSE POP_TOP which always follow BINARY_EXC_MATCH -- components: Interpreter Core files: cmpoppatch.diff keywords: patch messages: 109259 nosy: serprex priority: normal severity: normal status: open title: Reserve COMPARE_OP for RichComparisons type: performance versions: Python 3.2, Python 3.3 Added file: http://bugs.python.org/file17855/cmpoppatch.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
