New submission from Demur Rumed :
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 latte
Demur Rumed 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
<http://bugs.python.org/i
New submission from Demur Rumed :
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
Changes by Demur Rumed :
--
title: LOAD_CONST followed by LOAD_ATTR can be optimized to justbe a
LOAD_COST -> LOAD_CONST followed by LOAD_ATTR can be optimized to just be a
LOAD_CONST
___
Python tracker
<http://bugs.pyth
Changes by Demur Rumed :
--
title: Marshal's documentation incomplete -> Marshal's documentation incomplete
(Bools)
___
Python tracker
<http://bugs.pyth
New submission from Demur Rumed :
"The following types are supported: None, integers, floating point
numbers, strings, bytes, bytearrays, tuples, lists, sets, dictionaries,
and code objects"
It fails to list bools: True and False
While it states "Not all Python object types ar
Demur Rumed added the comment:
I've included a patched version. I went with using a function signature
of def pprint(*object, stream=None, indent=1, width=80, depth=None)
--
nosy: +serprex
Added file: http://bugs.python.org/file14765/ppri
Demur Rumed added the comment:
A type safe compose could be useful. One which instead of returning a function
that takes (*args,**kwargs), takes the same as the first function which the
arguments would be passed to. Copying a functions argument semantics would be
useful in general, such as
New submission from Demur Rumed :
A=[1,2,3]
def f(x):
A+=x,
This throws an error. The solution: state "global a". I find it odd that
augmented assignment should be viewed the same as assignment in descerning
local variables. This patch repairs such to maintain a as a varia
Demur Rumed added the comment:
A note on the patch, ste->ste_tmpname... lines, along with changes to
Lambda_kind, were not added by me. The additional newlines prior to
symtable_visit_stmt's declaration are accidental, apologies. I'll avoid
patching a snapshot and then pull th
Changes by Demur Rumed :
--
type: feature request -> behavior
___
Python tracker
<http://bugs.python.org/issue8977>
___
___
Python-bugs-list mailing list
Un
Demur Rumed added the comment:
I've modified the patch to be less aggressive, as suggested by Nick at
http://mail.python.org/pipermail/python-ideas/2010-June/007428.html
As an aside, runtests.sh should have executable permissions
--
Added file: http://bugs.python.org/file17644/d
New submission from Demur Rumed :
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_
Changes by Demur Rumed :
--
title: Reserve COMPARE_OP for RichComparisons -> Reserve COMPARE_OP for rich
comparisons
___
Python tracker
<http://bugs.python.org/iss
Changes by Demur Rumed :
Added file: http://bugs.python.org/file17856/cmpoppatch2.diff
___
Python tracker
<http://bugs.python.org/issue9155>
___
___
Python-bugs-list m
Demur Rumed added the comment:
I've attached the original patch without whitespace, and am also including
modifications to this portion of the interpreter which remove ROT_FOUR,
DUP_TOPX while adding ROT_THREE_TWO, DUP_TOP_TWO, DUP_ROT_THREE. I've seen a 5%
speed increase with ti
Demur Rumed added the comment:
I've attached the original patch without whitespace, and am also including
modifications to this portion of the interpreter which remove ROT_FOUR,
DUP_TOPX while adding ROT_THREE_TWO, DUP_TOP_TWO, DUP_ROT_THREE. I've seen a 4%
speed increase with ti
Changes by Demur Rumed :
Removed file: http://bugs.python.org/file17859/cmpoprotdup.diff
___
Python tracker
<http://bugs.python.org/issue9155>
___
___
Python-bugs-list m
Demur Rumed added the comment:
Fixed regression in ROT_THREE_TWO and a missed DUP_TOP2 -> DUP_TOP_TWO. Now
there are only the odd segfaults
--
Added file: http://bugs.python.org/file17861/cmpoprotdup2.diff
___
Python tracker
&l
Demur Rumed 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 compa
Demur Rumed 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
Demur Rumed 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 onl
Demur Rumed 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
New submission from Demur Rumed :
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
Changes by Demur Rumed :
--
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/issue9225>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 trac
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
Demur Rumed added the comment:
Oops wrong issue, sorry. Please delete?
--
___
Python tracker
<http://bugs.python.org/issue27129>
___
___
Python-bugs-list mailin
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
Changes by Demur Rumed :
Removed file: http://bugs.python.org/file43048/forbegin.patch
___
Python tracker
<http://bugs.python.org/issue27129>
___
___
Python-bugs-list m
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 we
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 p
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
<http://bugs.python.o
Demur Rumed added the comment:
Summer heat is getting to me. Please ignore this issue until I've uploaded a
fixed patch
--
___
Python tracker
<http://bugs.python.org/is
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,
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
Thi
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
<http://bugs.python.org/is
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 block
Demur Rumed added the comment:
I'd like to take on creating a patch for this proposal once #27140 lands
--
___
Python tracker
<http://bugs.python.org/is
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
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
<http://bugs.python.org/iss
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
Changes by Demur Rumed :
Removed file: http://bugs.python.org/file43270/forbegin2.patch
___
Python tracker
<http://bugs.python.org/issue27127>
___
___
Python-bugs-list m
Changes by Demur Rumed :
Added file: http://bugs.python.org/file43271/forbegin2.patch
___
Python tracker
<http://bugs.python.org/issue27127>
___
___
Python-bugs-list m
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_
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
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
Changes by Demur Rumed :
--
resolution: -> rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue27127>
___
___
Python-bugs-list
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
<http://bugs.python.or
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
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
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
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
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
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
Changes by Demur Rumed :
--
components: +Interpreter Core
type: -> performance
versions: +Python 3.6
___
Python tracker
<http://bugs.python.org/issu
Changes by Demur Rumed :
--
nosy: +serhiy.storchaka
___
Python tracker
<http://bugs.python.org/issue27358>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 dictob
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 track
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
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 e
Demur Rumed added the comment:
Pybench is now only ~200ms slower instead of 1200ms slower. But the whole point
of this patch is that CALL_FUNCTION_EX shouldn't be optimized for, so I'd much
prefer real benchmarking results
--
Added file: http://bugs.python.org/file43669
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
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: ht
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 & the
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 &
Changes by Demur Rumed :
--
type: enhancement -> performance
___
Python tracker
<http://bugs.python.org/issue27078>
___
___
Python-bugs-list mailing list
Un
Changes by Demur Rumed :
--
nosy: +rhettinger
___
Python tracker
<http://bugs.python.org/issue27078>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
---
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
<https://bugs.python.org/is
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
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
<http://bugs.py
Demur Rumed added the comment:
Also missing from this patch is modification of the bytecode magic number
--
___
Python tracker
<http://bugs.python.org/issue26
Demur Rumed added the comment:
Fixes syntax & line length issues in previous patch
--
Added file: http://bugs.python.org/file42312/imaplib2.patch
___
Python tracker
<http://bugs.python.org/iss
Demur Rumed added the comment:
Implementing tp_traverse & tp_clear seems to runs into complications due to
slice_cache
--
nosy: +Demur Rumed
___
Python tracker
<http://bugs.python.org/iss
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 a
Changes by Demur Rumed :
--
nosy: +abarnert
___
Python tracker
<http://bugs.python.org/issue26647>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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 benchmark
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.p
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
<http://bugs.python.org/issue26
Changes by Demur Rumed :
Removed file: http://bugs.python.org/file42338/wpy3.patch
___
Python tracker
<http://bugs.python.org/issue26647>
___
___
Python-bugs-list mailin
Changes by Demur Rumed :
Added file: http://bugs.python.org/file42339/wpy3.patch
___
Python tracker
<http://bugs.python.org/issue26647>
___
___
Python-bugs-list mailin
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 th
Demur Rumed added the comment:
Do you have any numbers on how common constant comparisons are in real code?
--
nosy: +Demur Rumed
___
Python tracker
<http://bugs.python.org/issue26
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
<http://bu
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 :
>
> Alexander Marshalov added the comment:
>
>
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 /tm
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 RE
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 rem
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
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 va
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
--
___
Changes by Demur Rumed :
Added file: http://bugs.python.org/file42835/wpy8.patch
___
Python tracker
<http://bugs.python.org/issue26647>
___
___
Python-bugs-list mailin
Changes by Demur Rumed :
Removed file: http://bugs.python.org/file42835/wpy8.patch
___
Python tracker
<http://bugs.python.org/issue26647>
___
___
Python-bugs-list mailin
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
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
follow
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
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
1 - 100 of 116 matches
Mail list logo
