| Crates.io | cfavml |
| lib.rs | cfavml |
| version | 0.3.0 |
| created_at | 2024-08-04 15:23:30.117168+00 |
| updated_at | 2024-08-21 22:46:54.380396+00 |
| description | CF's Accelerated Vector Math Library providing SIMD optimzied routines for vector operations |
| homepage | |
| repository | https://github.com/ChillFish8/cfavml |
| max_upload_size | |
| id | 1325057 |
| size | 876,794 |
CF's Accelerated Vector Math Library
Various accelerated vector operations over Rust primitives with SIMD.
This is the core base library, it has no dependencies and only depends on the core library,
it does not perform any allocations.
This library is guaranteed to be no-std compatible and can be adjusted by disabling the std
feature flag:
cfavml = "0.3.0"
cfavml = { version = "0.3.0", default-features = false }
If you are upgrading on a breaking release, i.e. 0.2.0 to 0.3.0 there may be some important
changes that affects your system, although the public safe APIs I try my best to avoid breaking.
0.3.0+
0.3.0 avx512 was used when only the avx512f cpu feature was available
since this is the base/foundation version of AVX512. However, in 0.3.0 we introduced more extensive
cmp operations (eq/neq/lt/lte/gt/gte) which changed our required CPU features to include avx512bwavx512bw.avx512f + avx512bw) nightly onlyf32f64i8i16i32i64u8u16u32u64f32/f64 divisionDivision operations on non-floating point primitives are currently still scalar operations, as performing integer division is incredibly hard to do anymore efficiently with SIMD and adds a significant amount of cognitive overhead when reading the code.
Although to be honest I have some serious questions about your application if you're doing heavy integer division...
These are routines that can be used for things like KNN classification or index building.
If you've looked at the danger folder at all, you'll notice a few things, one SIMD operations
are gated behind the SimdRegister<T> trait, this provides us with a generic abstraction
over the various SIMD register types and architectures.
This trait, combined with the Math<T> trait form the core of all operations and are
provided as generic functions (with no target features):
generic_dotgeneric_squared_euclideangeneric_cosinegeneric_squared_normgeneric_cmp_maxgeneric_cmp_max_vectorgeneric_cmp_max_valuegeneric_cmp_mingeneric_cmp_min_vectorgeneric_cmp_min_valuegeneric_cmp_eq_vectorgeneric_cmp_eq_valuegeneric_cmp_neq_vectorgeneric_cmp_neq_valuegeneric_cmp_lt_vectorgeneric_cmp_lt_valuegeneric_cmp_lte_vectorgeneric_cmp_lte_valuegeneric_cmp_gt_vectorgeneric_cmp_gt_valuegeneric_cmp_gte_vectorgeneric_cmp_gte_valuegeneric_sumgeneric_add_valuegeneric_sub_valuegeneric_mul_valuegeneric_div_valuegeneric_add_vectorgeneric_sub_vectorgeneric_mul_vectorgeneric_div_vectorWe also export functions with the target_features pre-specified for
each SIMD register type and is found under the cfavml::danger::export_*
modules. Although it is not recommended to use these routines directly
unless you know what you are doing.
nightly Enables optimizations available only on nightly platforms.
No. At least, not unless you're only doing dot product... BLAS and LAPACK are huge and I am certainly not in the market for implementing all BLAS routines in Rust, but that being said if your application is similar to that of ndarray where it is only using BLAS for the dot product, then maybe.