This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author jyasskin
Recipients jyasskin
Date 2008-03-09.17:38:47
SpamBayes Score 0.009165745
Marked as misclassified No
Message-id <1205084332.03.0.568369699233.issue2262@psf.upfronthosting.co.za>
In-reply-to
Content
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(;;) loop. That shortens their lifetimes so that the compiler can
skip spilling them to memory in some cases. Pushing them further down
into the individual case statements didn't change the generated assembly
in most cases, although there are probably a few opcodes where it would.
 2) Eliminates the initialization of w, and fixes the "possibly used
uninitialized" warning by changing how the PRINT opcodes initialize it
from stream. That lets my compiler avoid using its stack entry most of
the time.
 3) In two hot opcodes, LOAD_FAST and LOAD_CONST, changes the 'x' to a
'w'. 'x' is always written to memory because it's used for error
detection, while 'w' can stay on the stack.
 4) Changes --_Py_Ticker in the periodic things check to _Py_Ticker--.
Because _Py_Ticker is volatile, predecrement (at least on my compiler)
needs 3 memory accesses, while postdecrement gets away with 2.

Together, these changes are worth about 3% on pybench on my machine.
History
Date User Action Args
2008-03-09 17:38:52jyasskinsetspambayes_score: 0.00916575 -> 0.009165745
recipients: + jyasskin
2008-03-09 17:38:52jyasskinsetspambayes_score: 0.00916575 -> 0.00916575
messageid: <1205084332.03.0.568369699233.issue2262@psf.upfronthosting.co.za>
2008-03-09 17:38:50jyasskinlinkissue2262 messages
2008-03-09 17:38:49jyasskincreate