[HN Gopher] Convert macros to functions in the Python C API
___________________________________________________________________
Convert macros to functions in the Python C API
Author : genericlemon24
Score : 22 points
Date : 2021-10-20 15:45 UTC (2 days ago)
(HTM) web link (www.python.org)
(TXT) w3m dump (www.python.org)
| latenightcoding wrote:
| This is great, if you want to see what the other extreme looks
| like check the source code of the perl5 interpreter, it's all
| weird macros.
| RcouF1uZ4gsC wrote:
| > _Py_NewReference()
|
| Actually just the name is undefined behavior per C and C++. The
| standards reserve all identifiers starting with underscore and
| followed by a capital letter to the implementation.
| zabzonk wrote:
| Quite right. I have never understood this obsession that people
| have with underscores. Here's something I wrote about them some
| time ago: https://punchlet.wordpress.com/2009/12/01/letter-the-
| second/
| kevin_thibedeau wrote:
| They make up for C's lack of namespaces. If you're not
| writing a compiler or OS you shouldn't be profligate with
| them.
| mayli wrote:
| Agreed, the obsession pretty much true, but without really
| practical reason behind it.
| matzf wrote:
| This is not the point of the article, and maybe I'm just tired,
| but I'm confused; multiple paragraphs mention increased stack
| size with inlining:
|
| > When a C compiler decides to not inline, there is likely a good
| reason. For example, inlining would reuse a register which
| require to save/restore the register value on the stack and so
| increase the stack memory usage or be less efficient.
|
| > On the other side, the Py_NO_INLINE macro can be used to
| disable inlining. It is useful to reduce the stack memory usage.
|
| This seems completely backwards, what are they talking about?
| Spivak wrote:
| So this one is counterintuitive. You only spend stack space for
| local variables _that don't fit in registers_. If you in-line a
| function with lots of local variables into a function with lots
| of local variables you use more stack space. And then that
| additional stack space can't be reclaimed until the function it
| was inlined into returns. So it's more stack space used
| temporarily but less used on average.
| kevin_thibedeau wrote:
| Reading between the lines, they're probably pointing out that
| inlining non-trivial functions increases register pressure
| which leads to larger stack frames as variables spill onto the
| stack. That's a bit of a strawman since calling the non-inlined
| function will need to build an entire new stack frame anyway.
| Which one is most beneficial depends on other circumstances
| like cache behavior and how often the code is called.
| rstuart4133 wrote:
| I think their reasoning appears earlier:
|
| > When a C compiler decides to not inline, there is likely a
| good reason. For example, inlining would reuse a register which
| require to save/restore the register value on the stack and so
| increase the stack memory usage or be less efficient.
|
| And ... that removes all doubt. They are wrong. If a
| calculation requires an extra register, doing a function call
| won't conjure it out of thin air. It has to spill the register
| too, and it will push the PC along with it.
|
| It's still possible a doing function call rather than inlining
| will speed up code on modern CPU's. The repeated code the
| inlining generates extra demands on the caches.
| stefanos82 wrote:
| I guess `flatten` attribute could be used here to help the
| situation? flatten Generally,
| inlining into a function is limited. For a
| function marked with this attribute, every call
| inside this function is inlined, if possible.
| Functions declared with attribute noinline and similar are not
| inlined. Whether the function itself is
| considered for inlining depends on its size and the
| current inlining parameters.
___________________________________________________________________
(page generated 2021-10-22 23:00 UTC)