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 blaisorblade
Recipients alexandre.vassalotti, blaisorblade, christian.heimes, lemburg, pitrou, rhettinger, skip.montanaro
Date 2009-01-02.02:53:54
SpamBayes Score 4.82947e-15
Marked as misclassified No
Message-id <>
> 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:
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

Some clues about why Python does not use threading:

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.
Date User Action Args
2009-01-02 02:53:59blaisorbladesetrecipients: + blaisorblade, lemburg, skip.montanaro, rhettinger, pitrou, christian.heimes, alexandre.vassalotti
2009-01-02 02:53:58blaisorbladesetmessageid: <>
2009-01-02 02:53:57blaisorbladelinkissue4753 messages
2009-01-02 02:53:54blaisorbladecreate