[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx

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 _

[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx

Changes by Skip Montanaro : -- nosy: -skip.montanaro ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx

Changes by Collin Winter : -- nosy: +collinwinter ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx

Changes by Antoine Pitrou <[EMAIL PROTECTED]>: -- nosy: +pitrou __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe:

[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx

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 s

[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx

Changes by Jeffrey Yasskin <[EMAIL PROTECTED]>: -- type: behavior -> performance __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing

[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx

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 P

[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx

Changes by Jeffrey Yasskin <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file9649/elim_mem_refs.patch __ Tracker <[EMAIL PROTECTED]> __ ___ Py

[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx

Changes by Jeffrey Yasskin <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file9648/elim_mem_refs.patch __ Tracker <[EMAIL PROTECTED]> __ ___

[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx

Changes by Jeffrey Yasskin <[EMAIL PROTECTED]>: Added file: http://bugs.python.org/file9648/elim_mem_refs.patch __ Tracker <[EMAIL PROTECTED]> __ ___ Py

[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx

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 insig

[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx

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 repr

[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx

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 (Compare

[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx

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 ../Py

[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx

Neal Norwitz <[EMAIL PROTECTED]> added the comment: Can't next_instr and stack_pointer move inside the for loop too? __ Tracker <[EMAIL PROTECTED]> __ __

[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx

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

[issue2262] Helping the compiler avoid memory references in PyEval_EvalFrameEx

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(;;)