perf(python): Specify tune-cpu & add more features

[ruihe774]

This PR makes use of standard x86 microarhitecture levels¹ for target-cpu instead of manually specified target-features when building the release wheels. This brings the following benefits:

• Consistent with the standard: Many Linux distros, e.g. openSUSE² and CachyOS³, use x86 microarhitecture levels when compiling optimized versions of packages. Using standard levels better aligns with the downstream packaging.
• Reduce maintain burden: No need to define and update⁴ a list of features. Each level includes all supported features.
• Performance improvement: Setting target-cpu implies tune-cpu, while setting target-features does not. e.g., target-cpu=x86-84-v3 enables tuning for those v3 cpu models⁵.

This PR uses:

• x86-64-v3 for normal release; it includes sse, avx, avx2, etc.
• x86-64-v2 for lts-cpu release; it includes sse, etc.

Supported CPU models (i.e. compatibility) of either of them is not changed.

The special configuration for macOS is removed. I cannot find a cpu model that support fma but not avx2. Please correct me if I'm wrong.

This PR does not affect _cpu_check.py. A list of features is still given to it.

XXX:

• Is it worthy to also set tune-cpu? x86-64-v3 is tuned for a kind of old cpu model (Haswell). We may set target-cpu and tune-cpu to different values, e.g. -C target-cpu=x86-64-v3 -Z tune-cpu=skylake.
• It is not necessary to check every feature in _cpu_check.py. e.g. a cpu that has avx also has sse. We can simplify its logic and only check a sentinel feature.

Footnotes

1. https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels ↩

2. https://news.opensuse.org/2023/03/02/tw-gains-optional-optimizations ↩

3. https://wiki.cachyos.org/cachyos_repositories/what_are_the_cachyos_repo/#performance-and-optimizations ↩

4. https://github.com/pola-rs/polars/pull/14746 ↩

5. https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/X86/X86.td ↩

[ritchie46]

@orlp can you take a look here?

[orlp]

I'd prefer to keep using a manual list of features, on an as-needed basis. This also makes it easy to keep the CPU check module up-to-date.

Another example of a pitfall of x86-64-v3 is that your PR would have silently disabled pclmulqdq.

[ruihe774]

Another example of a pitfall of x86-64-v3 is that your PR would have silently disabled pclmulqdq.

Sorry, I did not notice that.

I'd prefer to keep using a manual list of features, on an as-needed basis. This also makes it easy to keep the CPU check module up-to-date.'

I want to argue that the compiler can implicitly make use of arch features. An "as-needed basis" is sub-optimal for the compiler. For example, if x86-64-v3 is specified, the compiler can use movbe and f16c, which are present in all AVX2-equppied CPU models and are not specified in the current "manual list of features".

Another point, as I've mentioned, is the tunings. Specifying a manual list of features does not turn on the tunings for the target CPU - tunings for generic CPU is used. Tunings in x86-64-v3 like TuningFastScalarFSQRT, TuningFastVariableCrossLaneShuffle, TuningFastVariablePerLaneShuffle, etc, are not enabled. This prevent the compiler from e.g. using a native sqrt implementation, and fallbacks to software Newton-Raphson.

Despite the aforementioned benefits of using microarch levels, if a manual list of features is still preferred, IMO we can at least complete the list with all features that the target CPU supports, and manually specify a -Z tune-cpu. @orlp Would you plz reconsider it?

[orlp]

@ruihe774 I would be open to adding more features if it means we don't exclude any CPUs we support now, and adding a reasonable tuning target. movbe sounds useful, f16c I wouldn't bother with since we don't use that.

I'm not very open to relaxing the CPU check. It's not that expensive and it means users get a proper explained error rather than a segfault. Also please consider that there are 'CPUs' which support weird combinations of feature sets, such as certain emulators like Rosetta.

[ruihe774]

@ruihe774 I would be open to adding more features if it means we don't exclude any CPUs we support now, and adding a reasonable tuning target. movbe sounds useful, f16c I wouldn't bother with since we don't use that.

OK. I'm going to work on this.

BTW what is the "reasonable tuning target" in your opinion? IMO I would choose tune-cpu=skylake because 1) skylake and later cpu models are widely used while prior cpu models are rare now, 2) it has TuningFastGather and TuningAllowLight256Bit which allow more efficient auto-vectorization, 3) it has similar tunings to ryzen.

such as certain emulators like Rosetta.

Rosetta does not support AVX at all¹; it can only run polars-lts-cpu.

BTW, I'm still wondering what the purpose of the macOS branch is:

elif [[ "$IS_MACOS" = true ]]; then
    FEATURES=+sse3,+ssse3,+sse4.1,+sse4.2,+popcnt,+avx,+fma,+pclmulqdq

I cannot find a cpu model that support fma but not avx2.

Footnotes

1. https://developer.apple.com/documentation/apple-silicon/about-the-rosetta-translation-environment#What-Cant-Be-Translated ↩

[ruihe774]

tune-cpu is set to skylake for polars and x86-64-v2 for polars-lts-cpu; movbe and cmpxchg16b are added.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 80.66%. Comparing base (f304a0c) to head (624a6b2).
Report is 27 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #17615      +/-   ##
==========================================
+ Coverage   80.64%   80.66%   +0.01%     
==========================================
  Files        1484     1490       +6     
  Lines      195509   195931     +422     
  Branches     2780     2789       +9     
==========================================
+ Hits       157675   158043     +368     
- Misses      37324    37375      +51     
- Partials      510      513       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[orlp]

@ruihe774 We talked internally and it seems no one can remember the reason why that MacOS check was there. So let's just get rid of it and we'll see if it turns out to be a regression. If so we can always fix it again and place a comment why it's so then :)