Paolo 'Blaisorblade' Giarrusso <p.giarru...@gmail.com> added the comment:
> I attached some additional benchmarks on SunOS. So far, it seems the benefits of the proposed optimization are highly compiler-dependent. Well, it would be more correct to say that as you verified for GCC 3.4, "miscompilation" of the code happens easily. Any literature research shows that threading in a fast interpreter does help. My experience shows two exceptions to this rule: a) bad compiler output b) interpreters which are not efficient enough - when other operations are even slower than instruction dispatch (which is really slow due to costly mispredictions), threading can't help. This is shown by the number of interpreters using threading. Wikipedia has more pointers on this: http://en.wikipedia.org/wiki/Threaded_code Note that what I called "indirect threading" is called there instead "token threading". Another example of the importance of threading is also shown in this article: http://webkit.org/blog/189/announcing-squirrelfish/ Some clues about why Python does not use threading: http://mail.python.org/pipermail/python-list/1999-May/002003.html It is important to note that people in that mail are not aware of why threading gives a speedup. == For SunCC, I can't say anything without looking at: a) the generated code; if jump targets were aligned only for switch but not for computed gotos, for instance, that could maybe explain such a slowdown. Lots of other details might be relevant. b) performance counters results, especially regarding mispredictions of indirect branches. _______________________________________ 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
