Measure Windows performance (and improve if lacking)

[gvanrossum]

There was a report that on Windows the performance on the PyPerformance benchmark is only 3% better than for 3.10. We should try to confirm or refute this result, and if confirmed, attempt to improve the situation.

Likely culprit is the optimizer (or PGO or LTO) giving up on inlining in the main function in ceval.c. In particular it might be the INCREF/DECREF inline functions. A possible hack would be to turn these back into macros again at the top of ceval.c (if no debugging options are defined).

[markshannon]

Would it be a viable option to use Clang instead of MSVC for Windows?

[kumaraditya303]

I have got it compiling under clang on windows in debug build

[gvanrossum]

FWIW my own measurements on Windows show much better perf than that, but are inconclusive due to noise (we're waiting for a dedicated perf machine running Windows). See #315 (comment) .

[gvanrossum]

@zooba Do you see a problem with using clang instead of MSVC on Windows, assuming we can get it working?

[ivoflipse]

Wouldn't that mean that anyone building C extensions would also have to switch over to Clang?

If so, that would require some coordination (e.g. cibuildwheel, conda-forge, numpy/scipy) to make such a switch and support two compilers if you want to make C extensions available for multiple Python versions.

[gvanrossum]

@ivoflipse

Wouldn't that mean that anyone building C extensions would also have to switch over to Clang?

I don't know. I have no experience with this topic at all, which is why I'm asking @zooba for advice.

@kumaraditya303 Can you point to your branch here?

[zooba]

Yeah, that's a massive ecosystem change that we're not ready for. It almost certainly will affect the ABI in some way, though it might be manageable, and it'll definitely impact/break any build scripts that implicitly or explicitly assume MSVC. As I work through ARM64 support, I'm finding that is "many"... (unless, of course, it turns out to be perfectly safe to link between the two compilers, and then it'll only affect static lib users, which is practically nobody AFAIK).

Figuring out for certain if the size of ceval is causing it to de-optimise and then sensibly breaking it up is much easier.

[gvanrossum]

FWIW @neonene came up with a PR that temporarily enables a flag that shows the inlining decisions. I'll look into this.

https://bugs.python.org/issue45116#msg406471

[sweeneyde]

I have a branch python/cpython@main...sweeneyde:ops_to_funcs that converts several of the longer opcodes into functions, in case that is useful for comparison.

[neonene]

Macro benchmarks' improvements are unstable for me in the range of 8~20% compared to 3.10.1+.

When building with PGO (only), changing the definition of Py_UNREACHABLE() could be an improvement. For example, replacing __assume(0) with a no-return-noop function in pymacro.h. But __assume(0) is not the only suspect that stops the optimizer.

https://devblogs.microsoft.com/cppblog/visual-studio-2017-throughput-improvements-and-advice/#remove-usages-of-__assume