Well, maybe it's a bad example. I just wanted to say that converting macros to static inline functions provide more accurate profiler data and debuggers can more easily show static inline functions names when they are inlined and put breakpoints of them. But you're right, it's not a silver bullet ;-)
Victor On Mon, Feb 14, 2022 at 11:29 AM Antoine Pitrou <anto...@python.org> wrote: > > On Wed, 9 Feb 2022 17:49:19 +0100 > Victor Stinner <vstin...@python.org> wrote: > > On Wed, Feb 9, 2022 at 1:04 PM Petr Viktorin <encu...@gmail.com> wrote: > > > > Right now, a large number of macros cast their argument to a type. A > > > > few examples: > > > > > > > > #define PyObject_TypeCheck(ob, type) > > > > PyObject_TypeCheck(_PyObject_CAST(ob), type) > > > > #define PyTuple_GET_ITEM(op, i) (_PyTuple_CAST(op)->ob_item[i]) > > > > #define PyDict_GET_SIZE(mp) (assert(PyDict_Check(mp)),((PyDictObject > > > > *)mp)->ma_used) > > > > > > When I look at the Rationale points, and for the first three of these > > > macros I didn't find any that sound very convincing: > > > - Functions don't have macro pitfalls, but these simple macros don't > > > fall into the pits. > > > - Fully defining the argument types means getting rid of the cast, > > > breaking some code that uses the macro > > > - Debugger support really isn't that useful for these simple macros > > > - There are no new variables > > > > Using a static inline function, profilers like Linux perf can count > > the CPU time spend in static inline functions (on each CPU instruction > > when using annotated assembly code). For example, you can see how much > > time (accumulated time) is spent in Py_INCREF(), to have an idea of > > the cost of reference counting in Python. > > The "time spent in Py_INCREF" doesn't tell you the cost of reference > counting. Modern CPUs execute code out-of-order and rely on many > internal structures (such as branch predictors, reorder buffers...). > The *visible* time elapsed between the instruction pointer entering and > leaving a function doesn't tell you whether Py_INCREF had adverse > effects on the utilization of such internal structures (making > reference counting more costly than it appears to be), or on the > contrary whether the instructions in Py_INCREF were successfully > overlapped with other computations (making reference counting > practically free). > > The only reliable way to evaluate the cost of reference counting is to > compare it against alternatives in realistic scenarios. > > Regards > > Antoine. > > > > > It's not possible when using > > macros. > > > > For debuggers, you're right that Py_INCREF() and PyTuple_GET_ITEM() > > macros are very simple and it's not so hard to guess that the debugger > > is executing their code in the C code or the assembly code. But the > > purpose of PEP 670 is to convert way more complex macros. I wrote a PR > > to convert unicodeobject.h macros, IMO there are one of the worst > > macros in Python C API: > > https://github.com/python/cpython/pull/31221 > > > > I always wanted to convert them, but some core devs were afraid of > > performance regressions. So I wrote a PEP to prove that there is no > > impact on performance. > > > > IMO the new unicodeobject.h code is way more readable. I added two > > "kind" variables which have a well defined scope. In macros, no macro > > is used currently to avoid macro pitfalls: name conflict if there is > > already a "kind" macro where the macro is used. > > > > The conversion to static inline macros also detected a bug with "const > > PyObject*": using PyUnicode_READY() on a const Unicode string is > > wrong, this function modifies the object if it's not ready (WCHAR > > kind). It also detected bugs on "const void *data" used to *write* > > into string characters (PyUnicode_WRITE). > > > > > > > - Macro tricks (parentheses and comma-separated expressions) are needed, > > > but they're present and tested. > > > > The PEP rationale starts with: > > "The use of macros may have unintended adverse effects that are hard > > to avoid, even for experienced C developers. Some issues have been > > known for years, while others have been discovered recently in Python. > > Working around macro pitfalls makes the macro coder harder to read and > > to maintain." > > > > Are you saying that all core devs are well aware of all macro pitfalls > > and always avoid them? I'm well aware of these pitfalls, and I fall > > into their trap multiple times. > > > > The bpo-30459 issue about PyList_SET_ITEM() is a concrete example of > > old bugs that nobody noticed before. > > > > > > > The "massive change to working code" part is important. Such efforts > > > tend to have unexpected issues, which have an unfortunate tendency to > > > surface before release and contribute to release manager burnout. > > > > Aren't you exaggerating a bit? Would you mind to elaborate? Do you > > have examples of issues caused by converting macros to static inline > > functions? > > > > I'm not talking about incompatible C API changes made on purpose, but > > about PEP 670 changes. > > > > The PEP lists many macros converted to static inline functions and > > static inline functions converted to regular functions: > > https://www.python.org/dev/peps/pep-0670/#macros-converted-to-functions-since-python-3-8 > > > > Are you aware of release manager burnout caused by these changes? > > > > Victor > > > > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/2FWINTMNGHDTDSGV6BRZ6NEDNBDDDAHF/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/7C2JXVQASVCFJLOX5YHAERDQJKDPP5PY/ Code of Conduct: http://python.org/psf/codeofconduct/
