Closed i18nsite closed 8 months ago
Hi @i18n-now, can you please share the output of lscpu
?
same as. https://github.com/ogxd/gxhash/issues/43 ( yes, I am 3tieto )
I am also running into this probably, 3.1.0, compiling on AMD Ryzen 7:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 48 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Vendor ID: AuthenticAMD
Model name: AMD Ryzen 7 PRO 6850H with Radeon Graphics
CPU family: 25
Model: 68
Thread(s) per core: 2
Core(s) per socket: 8
Socket(s): 1
Stepping: 1
CPU(s) scaling MHz: 47%
CPU max MHz: 4785.0000
CPU min MHz: 400.0000
BogoMIPS: 6388.16
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm c
onstant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes
xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core pe
rfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a
rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rd
pru wbnoinvd cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif
v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid overflow_recov succor smca fsrm
Virtualization features:
Virtualization: AMD-V
Caches (sum of all):
L1d: 256 KiB (8 instances)
L1i: 256 KiB (8 instances)
L2: 4 MiB (8 instances)
L3: 16 MiB (1 instance)
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0-15
Vulnerabilities:
Gather data sampling: Not affected
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Retbleed: Not affected
Spec rstack overflow: Mitigation; safe RET, no microcode
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Spectre v2: Mitigation; Retpolines, IBPB conditional, IBRS_FW, STIBP always-on, RSB filling, PBRSB-eIBRS Not affected
Srbds: Not affected
Tsx async abort: Not affected
with compile failures:
Compiling gxhash v3.1.0
error[E0432]: unresolved import `platform`
--> /home/ryan/.cargo/registry/src/index.crates.io-6f17d22bba15001f/gxhash-3.1.0/src/gxhash/platform/mod.rs:9:9
|
9 | pub use platform::*;
| ^^^^^^^^ help: a similar path exists: `crate::platform`
|
= note: `use` statements changed in Rust 2018; read more at <https://doc.rust-lang.org/edition-guide/rust-2018/module-system/path-clarity.html>
error[E0412]: cannot find type `State` in this scope
--> /home/ryan/.cargo/registry/src/index.crates.io-6f17d22bba15001f/gxhash-3.1.0/src/gxhash/platform/mod.rs:13:49
|
13 | pub(crate) const VECTOR_SIZE: usize = size_of::<State>();
| ^^^^^ not found in this scope
|
help: you might be missing a type parameter
|
13 | pub(crate) const VECTOR_SIZE<State>: usize = size_of::<State>();
| +++++++
I believe I caused this (see #53), oops. This doesn't make a whole lot of sense, since both of your systems support both AES-NI
and SSE2
, which are the only requirements on x86, but I'll try to get this fixed ASAP.
On my AMD Ryzen 5 machine cargo build
works but I get the error at the docs-test
stage with cargo test
(weird). I no longer have the issue by removing the target_feature = "aes"
but I don't get why since the feature is supposed to exist.
That's indeed a regression from v3.1.0, v3.0.0 should work as expected in the meantime.
v3.1.0 will work just fine if used with the RUSTFLAGS
environment variable set to -C target-cpu=native
or -C target-feature=+aes,+sse2
, but I think it would be better to look into runtime feature detection.
Yeah I just saw this issue https://github.com/rust-lang/rust/issues/80633 and ahash
crate author was having the same issues. The docs-test issue is a bit different, I think it is ran ignoring the target-cpu=native
, and there is a workaround for it https://github.com/tkaitchuck/aHash/blob/1e6f01a4060d20a6a407b5cd89d0f5556405c5bc/Cargo.toml#L103
v3.1.0 will work just fine if used with the RUSTFLAGS environment variable set to -C target-cpu=native or -C target-feature=+aes,+sse2, but I think it would be better to look into runtime feature detection.
Maybe, but runtime feature detection has drawbacks. In the meantime it's best to address this regression even if the solution isn't perfect
I've tried doing build-time feature detection. It's not perfect in the current state but it works nicely on my side.
You can try it by referencing the branch:
gxhash = { git = "https://github.com/ogxd/gxhash.git", branch = "build-time-feature-detection" }
Please let me know if that works for you (or doesn't).
Also experiencing this issue on an Intel i5-1035G4, using Linux Mint 21.2. Same errors as others have sent.
After trying the git =
dep above:
error[E0425]: cannot find function `check_hardware_support` in this scope
--> /home/ryan/.cargo/git/checkouts/gxhash-16f86614ecda3cfe/f42b025/build.rs:6:21
|
6 | if let Err(e) = check_hardware_support() {
| ^^^^^^^^^^^^^^^^^^^^^^ help: a function with a similar name exists: `has_hardware_support`
...
19 | fn has_hardware_support() -> Result<(), Box<dyn std::error::Error>> {
| ------------------------------------------------------------------- similarly named function `has_hardware_support` defined here
error[E0425]: cannot find function "check_hardware_support" in this scope
Oops my bad, I just fixed that
I'm not sure if the solution I proposed above is the correct way to address this. It introduces issues with cross-compilation.
I agree with @notsatvrn
v3.1.0 will work just fine if used with the RUSTFLAGS environment variable set to -C target-cpu=native or -C target-feature=+aes,+sse2, but I think it would be better to look into runtime feature detection.
I gave runtime feature detection a try with #[target_feature(enable = "aes")]
and for some reason, I don't get the expected performance out of it. It needs to be investigated further.
Issue addressed with https://github.com/ogxd/gxhash/pull/62, which is simply about adding a check at build-time with a message for better DX to tell the user to enable required target features.
Please let me know if this solution works for you (or if it does not)
I would have preferred the crate to compile for required target features by itself, but rust does not currently allow this without compromises (such as inlining issues). See this issue for more details: https://github.com/ogxd/gxhash/pull/61