Provide detection for SIMD features in autoconf and at runtime #125022
Comments
picnixz
added
type-feature
|
My general opinion about managing SIMD logics in CPython side: #124951 (comment) |
|
I do have concerns and that's why I'd like to hear from people that 1) know about weird architectures 2) deal with real-life scenarios. What I have in mind:
So, yes, I definitely have concerns on the differences. Using SIMD instructions could probably make local builds faster or builds managed by distributions themselves though we should be really careful. This is also the reason why I want to keep runtime detection to avoid issues. The idea was to open a wider discussion on SIMD support itself. If you want we can move to Discourse though I'm not sure whether it's better to keep it internal for now (the PR is just a PoC and it probably won't cover those cases we're worried about). I don't think we should add SIMD for every possible parts of the library, only those that are critical enough IMO. And they should be carefully worked out. However, in order to investigate them (and test them using the CI), I think having an internal detection framework would at least be the first step (or maybe I'm wrong here?). |
|
I've harden the detection of AVX instructions. I've also learned that macOS may not like AVX-512 at all (or at least some registers states won't be restored correctly upon context-switching). So there are real-life issues that we should address. What I'll maybe do is first try to make a PoC for |
Feature or enhancement
Proposal:
In #124951, there has been some initial discussion on improving the performances of
base64and possibly{bytearray,bytes,str}.translateusing SIMD instructions.More generally, if we want to use specific SIMD instructions, it'd be good if we at least know whether the processor supports them or not. Note that we already support SIMD in
blake2when possible. As such, I suggest an internal framework for detecting SIMD features for other part of the library as well as a compiler flag support detection.Note that a single part of the code could benefit from some SIMD calls without having to link the entire library against the entire SIMD-128 or SIMD-256 instruction sets. Note that having a way to detect SIMD support should probably be independent of whether we would use them or not apart from the blake2 module because it could only benefit the standard library if we were to include them.
The blake2 module SIMD support is fairly... complicated due to the wide variety of platforms that need to be supported and due to the mixture of many SIMD instructions. So I don't think I want to touch that part and make it work under the new interface (at least, not for now). While I can say that I'm confident in detecting features on "widely used" systems, there are definitely systems that I don't know so I'd appreciate any help on this topic.
Has this already been discussed elsewhere?
I don't want to open a Discourse thread for now since it's mainly something that will be used internally and not to be exposed to the world.
Links to previous discussion of this feature:
There has been some discussion on Discourse already about SIMD in general and whether to include them (e.g., https://discuss.python.org/t/standard-library-support-for-simd/35138) but the number of results containing "SIMD" or "AVX" is very small. Either this is because the topic is too advanced (detecting CPU features is NOT funny and there is a lack of documentation, the best one being the Wikipedia page) or the feature request is too broad.
Linked PRs
The text was updated successfully, but these errors were encountered: