Antoine Pitrou added the comment:
This avenue doesn't look promising at all. Closing.
--
resolution: - works for me
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2262
Changes by Skip Montanaro s...@pobox.com:
--
nosy: -skip.montanaro
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2262
___
___
Python-bugs-list
Changes by Collin Winter coll...@gmail.com:
--
nosy: +collinwinter
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2262
___
___
Python-bugs-list
Changes by Antoine Pitrou [EMAIL PROTECTED]:
--
nosy: +pitrou
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2262
__
___
Python-bugs-list mailing list
Unsubscribe:
Gregory P. Smith [EMAIL PROTECTED] added the comment:
We really could use an automated pybench runner on a dedicated machine
driven by a buildbot feeding its results into a database so that we had
a record of exactly when/what caused performance changes over time.
This sounds remarkably like
Jeffrey Yasskin [EMAIL PROTECTED] added the comment:
Another data point: I just installed gcc-4.3.0, and the second patch
gives it a 6% speedup. On the downside, 4.3 is still about 9% slower
than 4.0. :-( Neal, do you have your measurements?
__
Tracker [EMAIL
Changes by Jeffrey Yasskin [EMAIL PROTECTED]:
--
type: behavior - performance
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2262
__
___
Python-bugs-list mailing list
Skip Montanaro [EMAIL PROTECTED] added the comment:
Jeffrey ... but I'm really surprised to see the same tests affected in
Jeffrey opposite directions. Is that common with pybench and compiler
Jeffrey changes?
I've no idea. Marc-André Lemburg would be the person with the most insight
Changes by Jeffrey Yasskin [EMAIL PROTECTED]:
Added file: http://bugs.python.org/file9648/elim_mem_refs.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2262
__
___
Changes by Jeffrey Yasskin [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file9648/elim_mem_refs.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2262
__
___
Changes by Jeffrey Yasskin [EMAIL PROTECTED]:
Added file: http://bugs.python.org/file9649/elim_mem_refs.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2262
__
___
New submission from Jeffrey Yasskin [EMAIL PROTECTED]:
I'm using Apple's gcc-4.0.1 on a 2.33GHz Intel Core 2 Duo to test this.
Measurements from other compilers or other chips would be cool.
Specifically, this patch:
1) Moves the declarations of most of the local variables inside the
for(;;)
Neal Norwitz [EMAIL PROTECTED] added the comment:
I bet with just a little more work, you could get rid of t and stream.
t is only used for a single set of opcodes (STORE_SLICE+n). stream is
only used for the PRINT opcodes. The code in print could be moved to a
function which might allow the
Neal Norwitz [EMAIL PROTECTED] added the comment:
Can't next_instr and stack_pointer move inside the for loop too?
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2262
__
___
Skip Montanaro [EMAIL PROTECTED] added the comment:
I've yet to run pybench, but I came get these warnings from
the compiler after applying the patch:
../Python/ceval.c: In function 'PyEval_EvalFrameEx':
../Python/ceval.c:772: warning: 'x' may be used uninitialized in this
function
Skip Montanaro [EMAIL PROTECTED] added the comment:
Pybench doesn't show much difference for me, about 0.1% better on minimum
times. A few tests are quite a bit worse ( 10%) with the patch
(Recursion, SimpleFloatArithmetic, StringPredicates, TryFinally). A few
are quite a bit better
Jeffrey Yasskin [EMAIL PROTECTED] added the comment:
Neal, t and stream aren't likely to have much effect since they're used
so little. next_instr and stack_pointer are used to communicate between
loops, so they can't move inside. I eagerly await your benchmark runs. :)
Skip, I managed to
17 matches
Mail list logo
