On 8/21/2011 7:17 PM, Andreas Löscher wrote:
Am Sonntag, den 21.08.2011, 14:52 -0400 schrieb Roy Smith:
In article<mailman.282.1313951079.27778.python-l...@python.org>,
Christian Heimes<li...@cheimes.de> wrote:
Am 21.08.2011 19:27, schrieb Andreas Lscher:
As for using Integers, the first case (line 1319 and 1535) are true and
there is no difference in Code. However, Python uses a huge switch-case
construct to execute it's opcodes and INPLACE_ADD cames after
BINARY_ADD, hence the difference in speed.
I don't think that's the reason. Modern compiles turn a switch statement
into a jump or branch table rather than a linear search like chained
elif statements.
This is true even for very small values of "modern". I remember the
Unix v6 C compiler (circa 1977) was able to do this.
What is the difference in speed between a jump table that is searched
from top to bottom in comparison to an ordinary if-then-elif...? The
difference can only be in the search algorithm regarding the table.
Without optimization (linear search) both are the same. If the compiler
applies some magic the difference can be relevant (linear complexity for
if-then-elif... and O(1) if you would use a dictionary).
A jump or branch table is applicable when the case value values are all
small ints, like bytes or less. For C, the table is simply an array of
pointers (addressess, with entries for unused byte codes would be a void
pointer). Hence, O(1) access.
https://secure.wikimedia.org/wikipedia/en/wiki/Jump_table
Hence the executed code for integers is the same, there must be a slower
path to the code of BINARY_ADD than to INPLACE_ADD.
How would such an jump table work to behave the same liek a
switch-case-statement? Beware, that things like
case PRINT_NEWLINE_TO:
1802 w = stream = POP();
1803 /* fall through to PRINT_NEWLINE */
add jump to address of the code for PRINT_NEWLINE
1804
1805 case PRINT_NEWLINE:
must be supported.
--
Terry Jan Reedy
--
http://mail.python.org/mailman/listinfo/python-list
