-----Original Message----- From: Victor Stinner [mailto:victor.stinner@gmail.com] Sent: 27. febrúar 2014 10:47 To: Kristján Valur Jónsson Cc: Python-Dev (python-dev@python.org) Subject: Re: [Python-Dev] Start writing inlines rather than macros? In practice, recent versions of GCC and Clang are used. On Windows, it's Visual Studio 2010. I'm pretty sure that these compilers support inline functions.

I'm also in favor of using inline functions instead of long macros using ugly hacks like "instr1,instr2" syntax where instr1 used assert(). See for example unicodeobject.c to have an idea of what horrible macros mean.

I'm in favor of dropping C89 support and require at least C99. There is now C11, it's time to drop the old C89. http://en.wikipedia.org/wiki/C11_%28C_standard_revision%29

well, requiring C99 is another discussion which I'm not so keen on instigating :) As you point out, most of our target platforms probably do support inline already. My question is more of the nature: What about those that don't support inline, is there any harm in defaulting to "static" in that case and leave the inlining to the optimizer on those platforms? K

On Thu, Feb 27, 2014 at 5:47 AM, Victor Stinner wrote:

Hi,

2014-02-27 11:22 GMT+01:00 Kristján Valur Jónsson :

...

Now, Larry Hastings pointed out that we support C89 which doesn’t support Inlines. Rather than suggesting here that we update that compatibility requirement,

In practice, recent versions of GCC and Clang are used. On Windows, it's Visual Studio 2010. I'm pretty sure that these compilers support inline functions.

I'm also in favor of using inline functions instead of long macros using ugly hacks like "instr1,instr2" syntax where instr1 used assert(). See for example unicodeobject.c to have an idea of what horrible macros mean.

I'm in favor of dropping C89 support and require at least C99. There is now C11, it's time to drop the old C89. http://en.wikipedia.org/wiki/C11_%28C_standard_revision%29

The Visual Studio team has publicly stated they will never support C99, so dropping C89 blindly is going to alienate a big part of our user base unless we switch to C++ instead. I'm fine with trying to pull in C99 features, though, that we can somehow support in a backwards-compatible way with VS.

On Thu, Feb 27, 2014 at 12:22 PM, Sturla Molden wrote:

Brett Cannon wrote:

...

The Visual Studio team has publicly stated they will never support C99, so dropping C89 blindly is going to alienate a big part of our user base unless we switch to C++ instead. I'm fine with trying to pull in C99 features, though, that we can somehow support in a backwards-compatible way with VS.

So you are saying that Python should use "the C that Visual Studio supports"?

Well, C89 + Amendments which happens to be what all C compilers support, including VS.

I believe Microsoft is not competent to define the C standard.

Maybe, but they still control a large install base.

If they cannot provide a compiler that is their bad.

And unfortunately ours if we want Windows developers to be able to use CPython for things like embedding,

There are plenty of other standard-compliant compilers we can use, including Intel, clang and gcc (MinGW).

You manage to convince a majority of Windows developers to switch compilers and then I would be happy to promote we drop VS support and switch entirely to C99. Until then, though, this is like suggesting we cut off Windows XP because MS doesn't have long-term support anymore: it's a choice between being pragmatic for serving our install base or doing something to simplify our lives.

I think it's at least worthwhile to investigate the use of inline/static functions over the current macros. It's been many years since I looked at them. I doubt they have gotten any easier to read or edit with all their backslashes. I do have one question though. Suppose you encounter a compiler that doesn't understand the inline keyword, so you choose the static declaration as Kristján suggested. The resulting Python executable should be functionally correct, but if the optimizer doesn't happen to inline a given static function you might be stuck with some bad performance across-the-board (if it never inlines, or doesn't inline where we really need it to), or only under some circumstances (as a hypothetical example, inlining in dictobject.c, but not in ceval.c). Is there a configurable way to tell if a compiler will inline functions which are declared static, and possibly under what conditions they might not? It might still be necessary to maintain macros for those platforms. Skip

On Thu, Feb 27, 2014 at 1:23 PM, Antoine Pitrou wrote:

Well, if we must maintain macros, let's maintain them everywhere and avoid the burden of two different implementations for the same thing.

Would it be possible to generate the macro versions from the inline/static versions where necessary, as some sort of pre-compile step? S

Skip Montanaro writes:

On Thu, Feb 27, 2014 at 1:23 PM, Antoine Pitrou wrote:

...

Well, if we must maintain macros, let's maintain them everywhere and avoid the burden of two different implementations for the same thing.

Would it be possible to generate the macro versions from the inline/static versions where necessary, as some sort of pre-compile step?

To do that in general is a hard problem, unless you're a C compiler that already supports inlining. I'm not sure how easy it would be to define rules that support the inlines Python demands for performance, and yet makes function to macro conversion easy. I think it makes much more sense to look at rewriting the macros by hand so that they emulate the necessary amount of function semantics (eg, providing argument type-checking in debug builds, not mutating arguments unless passed by reference, evaluating arguments exactly once, etc). XEmacs has a lot of these for precisely the reason this thread started (plus the recognition at the time we started this practice that a number of our platforms could not be trusted to inline certain performance-critical routines). They're spelled using the same conventions as functions, so macros that don't obey those rules stick out. Then these function-like macros could be #ifdef'd with the inline functions, with some (automated) comparison testing on appropriate benchmarks by building with and without -dDONT_TRUST_INLINE. And then beta-testing by defaulting to #undef DONT_TRUST_INLINE. Then wait for cries of pain -- if none, remove the dead #ifdef branches in the last beta or so. Yes, this involves a certain amount of work, but I think it's bounded. There should be no extra maintenance of the #ifdef'd parts compared to the maintenance required to fix bugs resulting from change from macro semantics to inline semantics anyway, unless changing the macros is mistake-prone -- which will be recognized immediately.

Skip Montanaro wrote:

I do have one question though. Suppose you encounter a compiler that doesn't understand the inline keyword, so you choose the static declaration as Kristján suggested. The resulting Python executable should be functionally correct, but if the optimizer doesn't happen to inline a given static function you might be stuck with some bad performance across-the-board (if it never inlines, or doesn't inline where we really need it to), or only under some circumstances (as a hypothetical example, inlining in dictobject.c, but not in ceval.c). Is there a configurable way to tell if a compiler will inline functions which are declared static, and possibly under what conditions they might not? It might still be necessary to maintain macros for those platforms.

I think that all modern compilers can handle "static inline" in header files. If you have a compiler that cannot, chances are that the platform is horribly outdated and this particular performance issue will be relatively benign compared to other ones. Stefan Krah