(WIP) Generic float

[maksimryndin]

Issue #3333

Approach - use a generic Float type (trait-based) with zero-cost Newtype pattern with the same memory layout, float size to be set per collection

Design goals

• Be sure not to impact performance or current logic
• Extendable for different float type (not only f16 but also f64 and f128 for high precision applications)
• Backward-compatibe api changes
• Flexible for user

Pros

• Straightforward (no change for any logic) and natural (type aliases (VectorElementType, ScoreType) were already introduced)
• No performance penalties for runtime
• Extendable for other possible Float types (e.g. f64, and also https://rust-lang.github.io/rfcs/3453-f16-and-f128.html and Tracking Issue for f16 and f128 float types rust-lang/rust#116909) as opposed to “features creep” (https://effective-rust.com/features.html). f16 from half crate also implements Float (https://docs.rs/half/latest/half/struct.f16.html#impl-Float-for-f16)
• Allows for future dynamic switching as opposed to features
• Use num-traits which is already in the dependencies tree so no new dependency is introduced
• Num-traits is widely used in the ecosystem and its traits are implemented by related libs (like half)

Cons

• Slower compilation time (to be measured)
• Binary size increases (to be measured)

Steps for this PR

• Introduce generic VectorElementType and ScoreType with default f32 - the binary compiles 🎉
• Accommodate tests

Roadmap

• Introduce Float trait with a default type (f32) - to show a POC, goal - minimal changes and a digestible PR - code compiles and runs as before <-- this PR
• Make DimWeight generic for SparseVector
• Extend quantization crate to work with f16
• Neon cpu specific should be extended to work with f16
• Add generic params over the whole codebase, accommodate tests - at this stage compile-switched binary should work (Float is selected for all collections)
• Add support for API to setup float size per collection
• Duplicate boilerplate trait impls for ScoreType, DimWeight and VectorElementType can be abstracted with macros

Future investigations

• Float type uniformity check across distributed nodes
• User can upgrade (via VectorParamsDiff) to the bigger-sized floats (create collection, update collection)
• (Backlog) Quantization and neon support for f64, f128
• (Backlog) Protobuf API only support f32 and f64 so any greater precision (e.g. f128) requires additions/changes to API

All Submissions:

• Contributions should target the dev branch. Did you create your branch from dev?
• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

New Feature Submissions:

1. Does your submission pass tests?
2. Have you formatted your code locally using cargo +nightly fmt --all command prior to submission?
3. Have you checked your code using cargo clippy --all --all-features command?

Changes to Core Features:

• Have you added an explanation of what your changes do and why you'd like us to include them?
• Have you written new tests for your core changes, as applicable?
• Have you successfully ran tests with your changes locally?

[generall]

Hey @maksimryndin, thanks for the PR! I see that you changes have a significant impact on everything from storage to API (I have seen that you change types for Score).

This is goes a bit beyond the original intent of the issue to only change stored types and keep interface intact. So most likely we will not merge it.

For the reference: here is a PR that makes storage generic against datatype #3900

[maksimryndin]

Hey @maksimryndin, thanks for the PR! I see that you changes have a significant impact on everything from storage to API (I have seen that you change types for Score).

This is goes a bit beyond the original intent of the issue to only change stored types and keep interface intact. So most likely we will not merge it.

For the reference: here is a PR that makes storage generic against datatype #3900

Hi @generall ! The HTTP and gRPC API interface should be the same (I run the server and use the client as before), lib interfaces have changed a bit (for example for Rust via mere Deref) which is handled by version bump.

ScoreType can preserved for now as f32 while introducing f16 only.
I thought about the issue in a generic setting to allow for different floats and to make it dynamic per collection in the future (feature-based doesn't allow for that).

Should I close this PR and take another issue?

[generall]

Closing in favor of #4122