Detect x86_64 microarchitecture variant automatically#9788
Detect x86_64 microarchitecture variant automatically#9788
Conversation
zanieb
added
the
enhancement
| if is_x86_feature_detected!("avx512f") | ||
| && is_x86_feature_detected!("avx512bw") | ||
| && is_x86_feature_detected!("avx512cd") | ||
| && is_x86_feature_detected!("avx512dq") | ||
| && is_x86_feature_detected!("avx512vl") |
There was a problem hiding this comment.
tbh no clue if we should check for all of these or not
There was a problem hiding this comment.
All those checks are necessary I think.
I'd even go further and do it similar to https://github.com/HenrikBengtsson/x86-64-level (fyi, it takes the values from /proc/cpuinfo so the names slightly differ)
determine_cpu_version() {
## x86-64-v0 (can this happen?)
level=0
## x86-64-v1
has_cpu_flags lm cmov cx8 fpu fxsr mmx syscall sse2 || return 0
level=1
## x86-64-v2
has_cpu_flags cx16 lahf_lm popcnt sse4_1 sse4_2 ssse3 || return 0
level=2
## x86-64-v3
has_cpu_flags avx avx2 bmi1 bmi2 f16c fma abm movbe xsave || return 0
level=3
## x86-64-v4
has_cpu_flags avx512f avx512bw avx512cd avx512dq avx512vl || return 0
level=4
}I think going bottom-up like this is more robust although not really necessary in practice I guess. A CPU supporting AVX512 will support AVX2 😃 Unless someone is running uv in a crazy emulated environment. Nevertheless, it could be a good idea to comment that each level is a superset of the level below and that in practice it's okay to check top-down instead of bottom-up.
But that abm feature is confusing me, I couldn't find it directly mentioned in these sources
- https://en.wikipedia.org/wiki/X86-64#Microarchitecture_levels
- https://gitlab.com/x86-psABIs/x86-64-ABI/-/blob/master/x86-64-ABI/low-level-sys-info.tex
- https://clang.llvm.org/docs/UsersManual.html#x86
zanieb
force-pushed
the
zb/micro-detect
branch
11 times, most recently
from
e8ace72 to
359b5bb
Compare
|
While mostly I would want uv to automatically detect which microarchitecture variant to grab, I have a concern here related to docker images, specifically if uv is used to install Python in the dockerfile, what happens when the build machine and execution machine support different instruction sets? |
zanieb
force-pushed
the
zb/micro-detect
branch
from
359b5bb to
cd5f82c
Compare
I think it's fair to say the build machine will need to be on the same (or an older) microarchitecture than your execution machine. Do you think that's unreasonable? |
Only in the sense it's not something I have to think about right now, and without being familiar with this I'm not sure it would be easy to diagnose when a failure happened? |
Yeah the interpreter would probably just crash at runtime, or, if you use uv as your entry point, it would be "missing" |
|
Maybe this is already an issue with other tools that are installed into docker images, and it's not that common to face, and people who do face this problem are familiar with the symptom and cause. I just never thought about it before now. |
zanieb
force-pushed
the
zb/micro-detect
branch
2 times, most recently
from
c3ec284 to
d51e5d7
Compare
I don't think this is a common issue right now, and you raised a very valid concern. For pre-built binary artifacts, for example most Linux distros AFAIK use conservative microarchitecture and don't do any runtime detection. There has been some discussion about this in Fedora but the proposal to bump microarchutecture has been withdrawn? |
|
Assuming this feature is eventually implemented, it would be helpful to have a way to disable CPU microarchitecture detection to retain the current behavior that v1 is used by default. This would make it possible for folks who are mirroring |
|
@drmikehenry thanks for the feedback! |
5 participants
e.g., on my test machine
Note this is split into two commits: