Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[C++] Use existing library for CPU detection #45331

Open
pitrou opened this issue Jan 22, 2025 · 11 comments
Open

[C++] Use existing library for CPU detection #45331

pitrou opened this issue Jan 22, 2025 · 11 comments

Comments

@pitrou
Copy link
Member

pitrou commented Jan 22, 2025

Describe the enhancement requested

We currently use our own home-grown module for detecting CPU features, but it mainly supports x86, which implies that for now we cannot do dynamic dispatch on non-x86 CPUs (for example ARM where we might want to detect ARM or even SVE support at runtime).

We could probably reuse https://github.com/google/cpu_features instead. It doesn't seem to have any dependencies, and could be bundled as a private static library.

This was already proposed years ago as #16715

Component(s)

C++

@pitrou
Copy link
Member Author

pitrou commented Jan 22, 2025

Looking at https://github.com/google/cpu_features/blob/main/include/cpuinfo_aarch64.h , it's not obvious to me how we could get the supported SVE vector widths. Do you have any idea @cyb70289 ?

@pitrou
Copy link
Member Author

pitrou commented Jan 22, 2025

Edit: apparently there's an intrinsic to get the vector width: https://lemire.me/blog/2022/11/29/how-big-are-your-sve-registers-aws-graviton/

@kou
Copy link
Member

kou commented Jan 22, 2025

+1

1 similar comment
@cyb70289
Copy link
Contributor

+1

@wgtmac
Copy link
Member

wgtmac commented Jan 23, 2025

The library itself looks good. My main concern is the slowdown of its release cadence: https://github.com/google/cpu_features/releases

@pitrou
Copy link
Member Author

pitrou commented Jan 23, 2025

Hmm, that's a good point. Maintenance also seems to have slowed down a bit: https://github.com/google/cpu_features/graphs/contributors?from=20%2F01%2F2024

@pitrou
Copy link
Member Author

pitrou commented Jan 23, 2025

There's also https://github.com/anrieff/libcpuid , which only supports x86 and ARM but exposes a lot of information.

@pitrou
Copy link
Member Author

pitrou commented Jan 23, 2025

And by the way, xsimd has a more limited functionality for CPU feature detection: https://xsimd.readthedocs.io/en/latest/api/arch.html . It only supports x86 and ARM, does not offer detailed CPU information, does not expose things like BMI2 etc.

@h-vetinari
Copy link
Contributor

For completeness, you might be interested in https://github.com/archspec/archspec - it supports x64, aarch, ppc & risc, plus a lot of meta-information about the (partial) inclusion ordering of the various CPUs in terms of feature sets.

I think it doesn't have a C/C++ API though, so this is probably a long shot (slow to call python from C++), but OTOH, querying CPU features is not a common occurrence (once per session...?) and could be cached.

Numpy does it the other way around, detecting individual CPU features, rather than processor models, with a result à la:

Supported SIMD extensions in this NumPy install:
    baseline = SSE,SSE2,SSE3
    found = SSSE3,SSE41,POPCNT,SSE42,AVX,F16C,FMA3,AVX2
    not found = AVX512F,AVX512CD,AVX512_KNL,AVX512_KNM,AVX512_SKX,AVX512_CLX,AVX512_CNL,AVX512_ICL

It's implemented in C, but I don't think it has a public API.

@pitrou
Copy link
Member Author

pitrou commented Jan 23, 2025

@h-vetinari Well, we don't want the core Arrow C++ library to depend on the existence of a Python interpreter and Python libraries. As for the NumPy C code, since it's internal it's probably not trivial to vendor, and I suppose its APIs have no stability guarantee either.

@h-vetinari
Copy link
Contributor

Yeah, I understand. That's why I said "for completeness". :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants