Paolo 'Blaisorblade' Giarrusso <p.giarru...@gmail.com> added the comment:
Some other comments. The time saving of indirect threading are also associated with the removal of the range check, but better branch prediction is the main advantage. > Also, the macro USE_THREADED_CODE should be renamed to something else; > the word "thread" is too tightly associated with multi-threading. That's true. > Furthermore, threaded code simply refers to code consisting only of > function calls. Maybe, USE_COMPUTED_GOTO or USE_DIRECT_DISPATCH would be > better. I'd prefer USE_DIRECT_DISPATCH (or better, USE_THREADED_DISPATCH) rather than USE_COMPUTED_GOTO, since the latter is just the used language construct. "indirect threading" is the standard name in CS literature to define this technique. "Direct threading" is a variation where in the bytecode array, opcode is replaced by the pointer opcode_handler[opcode], so that dispatch is slightly faster. Most interpreters use indirect threading to save memory, and because it enables to switch the opcode handlers table to activate for instance debugging. The best paper about this is: "The Structure and Performance of Efficient Interpreters, M. Anton Ertl and David Gregg, 2003". The original paper about (direct) threaded code is this: "Threaded Code, James R. Bell, Comm. of ACM, 1973", but I don't feel it relevant at all today. Indirect threading was introduced in "Indirect Threaded Code, Robert B. K. Dewar, Communications of the ACM, 1975" (that's just a bit more relevant, but still). _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4753> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com