Author vstinner
Recipients serhiy.storchaka, vstinner
Date 2017-02-06.09:41:24
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Attached patch is an attempt to use the GCC/Clang __builtin_expect() attribute to provide the compiler with branch prediction information, it adds _Py_likely() and _Py_unlikely() macros, similar to the Linux kernel macros.

I always wanted to experiment this change. I opened this issue to collect information and benchmark results to take a decision. I doubt that the change will really make Python faster, there is a risk of modifying a lot of code for no value, or worse: make Python slower. Extract of GCC doc:

  "as programmers are notoriously bad at predicting how their programs actually perform."

My patch marks error cases as unlikely. A profiler like Linux perf should be used to check which branches are less likely, but I tried to use my guesses to expeeriment a first change.

Since there is a risk that using such macro makes the code slower, or has no effect, I tried to restrict changes to the hot code and the most common functions/macros:

* Py_EnterRecursiveCall()
* _PyArg_NoKeywords()
* Py_DECREF()... not sure about this case, is it really more likely that refcnt != 0 than refcnt==0?
* Functions to call functions: _PyObject_FastCallKeywords(), fast_function(), etc.
* etc.

I'm not sure about the methodology to benchmark such patch neither. Is it worth it to benchmark a Python compiled without PGO?

By the way, does GCC/Clang use __builtin_expect() information when Python is compiled with PGO? If PGO ignores this information, it would be better to not use it, since I now strongly recommend to use PGO. Otherwise, Python performance is too random because of the joy of code placement.

Some links on __builtin_expect():

Date User Action Args
2017-02-06 09:41:30vstinnersetrecipients: + vstinner, serhiy.storchaka
2017-02-06 09:41:28vstinnersetmessageid: <>
2017-02-06 09:41:28vstinnerlinkissue29461 messages
2017-02-06 09:41:28vstinnercreate