usearch 0.2.3 → 0.2.4

package/README.md

@@ -33,123 +33,110 @@ Euclidean • Angular • Jaccard • Hamming • Haversine • User-Defined Met
 Linux • MacOS • Windows
 </p>
 
-- [x] [Single C++11 header][usearch-header] implementation, easily extendible.
-- [x] [4B+](#go-beyond-4b-entries) sized space efficient point-clouds with `uint40_t`.
-- [x] [Half-precision](#quantize-on-the-fly) support with [`fp16`](https://github.com/maratyszcza/fp16).
+---
+
+- [x] Industry-leading [performance](#performance).
+- [x] Easily-extendible [single C++11 header][usearch-header] implementation.
+- [x] [User-defined](#define-custom-metrics) and pre-packaged SIMD-accelerated metrics.
+- [x] [Half-precision `f16` and Quarter-precision `f8`](#quantize-on-the-fly) support on any hardware.
 - [x] [View from disk](#view-larger-indexes-from-disk), without loading into RAM.
-- [x] [User-defined](#define-custom-metrics) and hardware-accelerated metrics with [`simsimd`](https://github.com/ashvardanian/simsimd). 
-- [x] Variable dimensionality vectors.
-- [x] Don't copy vectors if not needed.
+- [x] [4B+](#go-beyond-4b-entries) sized space efficient point-clouds with `uint40_t`.
+- [x] Variable dimensionality vectors - for [obscure use-cases][obscure-use-cases].
 - [x] [Bring your threads](#bring-your-threads), like OpenMP.
 - [x] Multiple vectors per label.
 - [ ] Thread-safe `reserve`.
-- [x] Compatible with Linux, MacOS, and Windows.
-- [x] AI + Vector Search = Semantic Search.
+- [x] AI + Vector Search = [Semantic Search](#ai--vector-search--semantic-search).
 
 [usearch-header]: https://github.com/unum-cloud/usearch/blob/main/include/usearch/usearch.hpp
-
-## Features
-
-### Define Custom Metrics
+[obscure-use-cases]: https://ashvardanian.com/posts/abusing-vector-search
+
+---
+
+|                    | FAISS                         | USearch                            |
+| :----------------- | :---------------------------- | :--------------------------------- |
+| Implementation     | 84 K [SLOC][sloc] in `faiss/` | 1 K [SLOC][sloc] in `usearch/`     |
+| Supported metrics  | 9 fixed metrics               | Any User-Defined metrics           |
+| Supported ID types | `uint32_t`, `uint64_t`        | `uint32_t`, `uint40_t`, `uint64_t` |
+| Dependencies       | BLAS, OpenMP                  | None                               |
+| Bindings           | SWIG                          | Native                             |
+| Acceleration       | Learned Quantization          | Downcasting                        |
+
+FAISS is the industry standard for a high-performance batteries-included vector search engine.
+Both USearch and FAISS implement the same HNSW algorithm.
+But they differ in a lot of design decisions.
+USearch is designed to be compact and broadly compatible without sacrificing performance.
+
+|            | FAISS, `f32` | USearch, `f32` | USearch, `f16` | USearch, `f8` |
+| :--------- | -----------: | -------------: | -------------: | ------------: |
+| Insertions |       76 K/s |         89 K/s |         73 K/s |   **137 K/s** |
+| Queries    |      118 K/s |        167 K/s |        140 K/s |   **281 K/s** |
+| Recall @1  |          99% |          99.2% |            98% |     **99.2%** |
+
+> Dataset: 1M vectors sample of the Deep1B dataset.
+> Hardware: `c7g.metal` AWS instance with 64 cores and DDR5 memory.
+> HNSW was configured with identical hyper-parameters:
+> connectivity `M=16`,
+> expansion @ construction `efConstruction=128`,
+> and expansion @ search `ef=64`.
+> Both libraries were compiled for the target architecture.
+> Jump to the [Performance Tuning][benchmarking] section to read about the effects of those hyper-parameters.
+
+[sloc]: https://en.wikipedia.org/wiki/Source_lines_of_code
+[benchmarking]: https://github.com/unum-cloud/usearch
+
+## User-Defined Functions
 
 Most vector-search packages focus on just 2 metrics - "Inner Product distance" and "Euclidean distance".
-The lack of dedicated "Cosine distance" can be justified with the simplicity of normalizing such vectors on the fly.
-But that hardly exhausts the list of possible metrics.
+That only partially exhausts the list of possible metrics.
+A good example would be the rare [Haversine][haversine] distance, used to compute the distance between geo-spatial coordinates, extending Vector Search into the GIS domain.
+Another example would be designing a custom metric for **composite embeddings** concatenated from multiple AI models in real-world applications. 
+USearch supports that: [Python](#user-defined-functions-in-python) and [C++](#user-defined-functions-in-c) examples.
 
 ![USearch: Vector Search Approaches](assets/usearch-approaches-white.png)
 
-Older approaches indexing high-dimensional spaces, like KD-Trees and Locality Sensitive Hashing are hardly extendible to vectors/objects of variable length.
-Modern NSW-like approaches, however, only require two objects to be comparable.
-This means, the index can be extended to support fuzzy search with Levenstein distance over strings.
-USearch implements HNSW, and provides some uncommon-to-vector-search "similarity measures" and "distances" out of the box: Haversine, Jaccard, Hamming, etc.
-
-### Bring your Threads
+Unlike older approaches indexing high-dimensional spaces, like KD-Trees and Locality Sensitive Hashing, HNSW doesn't require vectors to be identical in length.
+They only have to be comparable.
+So you can apply it in [obscure][obscure] applications, like searching for similar sets or fuzzy text matching.
 
-Most AI, HPC, or Big Data packages use some form of a thread pool.
-Instead of spawning additional threads within USearch, we focus on thread-safety of the `add` function.
-
-```cpp
-#pragma omp parallel for
-    for (std::size_t i = 0; i < n; ++i)
-        native.add(label, span_t{vector, dims}, omp_get_thread_num());
-```
+[haversine]: https://ashvardanian.com/posts/abusing-vector-search#geo-spatial-indexing
+[obscure]: https://ashvardanian.com/posts/abusing-vector-search
 
-During initialization we allocate enough temporary memory for all the cores on the machine.
-On call, the user can simply supply the identifier of the current thread, making this library easy to integrate with OpenMP and similar tools.
+## Memory Efficiency, Downcasting, and Quantization
 
-### Go Beyond 4B Entries
-
-Constructing a vector index is a memory-intensive task.
-Depending on your configuration parameters, part of the memory will be allocated towards copies of vectors, and another part to the Small World Graph, common to NSW-like algorithms.
-Choosing the right data-structures and numeric types can have profound implications on both.
+Training a quantization model and dimension-reduction is a common approach to accelerate vector search.
+Those, however, are only sometimes reliable, can significantly affect the statistical properties of your data, and require regular adjustments if your distribution shifts.
 
 ![USearch uint40_t support](assets/usearch-neighbor-types.png)
 
-Internally, some point "label" is mapped into an integer identifier for every stored vector.
-Most implementations hard-code it to `uint32_t`, as people rarely store more than 4 Billion vectors.
-But when they do, software becomes unusable.
-Others hard-code it to `uint64_t`, which hardly space-efficient.
-We added a tiny class - `uint40_t`, that should be enough for collections up to 1 Trillion vectors.
-
-### View Larger Indexes from Disk
-
-To construct a large index one may use a beefy RAM-optimized machine, like the AWS `u-24tb1.metal` instances with 24 TB of RAM.
-Those are, however, pricy, and would cost you over $200/hour.
-
-|          |   To Build    |    To Serve    |
-| :------- | :-----------: | :------------: |
-| Instance | u-24tb1.metal | is4gen.8xlarge |
-| Price    |   ~ $200/h    |    ~$4.5/h     |
-| RAM      |     24 TB     |     192 GB     |
-| SSD      |      EBS      |     30 TB      |
-
-You wouldn't want to have them running all the time.
-So, if you are working on large datasets, but don't need the in-RAM throughput, you can simply view an existing dataset from disk, without ever loading it fully into memory.
-
-> Construct on large machines, deploy on the cheap ones.
+Instead, we have focused on high-precision arithmetic over low-precision downcasted vectors.
+The same index, and `add` and `search` operations will automatically down-cast or up-cast between `f32_t`, `f16_t`, `f64_t`, and `f8_t` representations, even if the hardware doesn't natively support it.
+Continuing the topic of memory-efficiency, we provide a `uint40_t` to allow collection with over 4B+ vectors without allocating 8 bytes for every neighbor reference in the proximity graph.
 
-### Quantize on the Fly
+## View Larger Indexes from Disk
 
-Most modern CPU have at least partial support for `half`-precision `f16_t` arithmetic.
-USearch supports automatic down-casting and up-casting between `f32_t`, `f16_t`, `f64_t`, and `f8_t` representations.
+Modern search systems often suggest using different servers to maximize indexing speed and minimize serving costs.
+Memory-optimized for the first task, and storage-optimized for the second, if the index can be served from external memory, which USearch can.
 
-> Making vectors smaller will help pack more of them in-memory, while also increasing performance on CPUs implementing native support for target type.
+|          |    To Build     |        To Serve        |
+| :------- | :-------------: | :--------------------: |
+| Instance |  u-24tb1.metal  |     is4gen.8xlarge     |
+| Price    |    ~ $200/h     |        ~$4.5/h         |
+| Memory   | 24 TB RAM + EBS | 192 GB RAM + 30 TB SSD |
 
-## Performance
-
-Below are the performance numbers for a benchmark running on the 64 cores of AWS `c7g.metal` "Graviton 3"-based instances.
-We fix the default configuration in the top line and show the affects of various parameters by changing one parameter at a time.
-
-|  Vectors   | Connectivity | EF @ A | EF @ S | **Add**, QPS | **Search**, QPS | **Recall @1** |
-| :--------: | :----------: | :----: | :----: | :----------: | :-------------: | ------------: |
-| `f32` x256 |      16      |  128   |   64   |    75'640    |     131'654     |         99.3% |
-|            |              |        |        |              |                 |               |
-| `f32` x256 |      12      |  128   |   64   |    81'747    |     149'728     |         99.0% |
-| `f32` x256 |      32      |  128   |   64   |    64'368    |     104'050     |         99.4% |
-|            |              |        |        |              |                 |               |
-| `f32` x256 |      16      |   64   |   32   |   128'644    |     228'422     |         97.2% |
-| `f32` x256 |      16      |  256   |  128   |    39'981    |     69'065      |         99.2% |
-|            |              |        |        |              |                 |               |
-| `f16` x256 |      16      |   64   |   32   |   128'644    |     228'422     |         97.2% |
-| `f32` x256 |      16      |  256   |  128   |    39'981    |     69'065      |         99.2% |
-
-The main columns are:
-
-- Add: Number of insertion Queries Per Second.
-- Search: Number search Queries Per Second.
-- Recall @1: How often does approximate search yield the exact best match?
-
-To read more and reproduce, jump to [benchmarking section](#benchmarking).
+There is a 50x difference between the cost of such instances for identical capacity.
+Of course, the latency of external memory access will be higher, but it is in part compensated with an excellent prefetching mechanism.
 
 ## Usage
 
 There are two usage patters:
 
-- Bare-bones with `usearch/usearch.hpp`, only available in C++.
-- Full-fat version with it's own threads, mutexes, type-punning, quantization, that is available both in C++ and is wrapped for higher-level bindings.
+1. Bare-bones with `usearch/usearch.hpp`, only available in C++.
+2. Full-fat version with it's own threads, mutexes, type-punning, quantization, that is available both in C++ and is wrapped for higher-level bindings.
 
 ### C++
 
+#### Installation
+
 To use in a C++ project simply copy the `include/usearch/usearch.hpp` header into your project.
 Alternatively fetch it with CMake:
 
@@ -158,19 +145,10 @@ FetchContent_Declare(usearch GIT_REPOSITORY https://github.com/unum-cloud/usearc
 FetchContent_MakeAvailable(usearch)
 ```
 
-The simple usage example would require including the `unum::usearch` namespace and choosing the right "distance" function.
-That can be one of the following templates:
+#### Quickstart
 
-- `cos_gt<float>` for "Cosine" or "Angular" distance.
-- `ip_gt<float>` for "Inner Product" or "Dot Product" distance.
-- `l2sq_gt<float>` for the squared "L2" or "Euclidean" distance.
-- `jaccard_gt<int>` for "Jaccard" distance between two ordered sets of unique elements.
-- `bit_hamming_gt<uint>` for "Hamming" distance, as the number of shared bits in hashes.
-- `pearson_correlation_gt<float>` for "Pearson" correlation between probability distributions.
-- `haversine_gt<float>` for "Haversine" or "Great Circle" distance between coordinates.
-
-That list is easily extendible, and can include similarity measures for vectors that have a different number of elements/dimensions.
-The minimal example would be.
+Once included, the low-level C++11 interface is as simple as it gets: `reserve()`, `add()`, `search()`, `size()`, `capacity()`, `save()`, `load()`, `view()`.
+This covers 90% of use-cases.
 
 ```c++
 using namespace unum::usearch;
@@ -183,14 +161,21 @@ index.add(/* label: */ 42, /* vector: */ {&vec, 3});
 index.search(
   /* query: */ {&vec, 3}, /* top */ 5 /* results */,
   /* with callback: */ [](std::size_t label, float distance) { });
+```
+
+The `add` is thread-safe for concurrent index construction.
 
-index.save("index.usearch"); // Serializing to disk
-index.load("index.usearch"); // Reconstructing from disk
+#### Serialization
+
+```c++
+index.save("index.usearch");
+index.load("index.usearch"); // Copying from disk
 index.view("index.usearch"); // Memory-mapping from disk
 ```
 
-The `add` is thread-safe for concurrent index construction.
-For advanced users, more compile-time abstraction are available.
+#### User-Defined Metrics in C++
+
+For advanced users, more compile-time abstractions are available.
 
 ```cpp
 template <typename metric_at = ip_gt<float>,            //
@@ -201,8 +186,8 @@ template <typename metric_at = ip_gt<float>,            //
 class index_gt;
 ```
 
-One may also define a custom metric, such as Damerau–Levenshtein distance, to compute the similarity between variable length strings.
-The only constraint is the function signature:
+You may want to use a custom memory allocator or a rare scalar type, but most often, you would start by defining a custom similarity measure.
+The function object should have the following signature to support different-length vectors.
 
 ```cpp
 struct custom_metric_t {
@@ -210,102 +195,184 @@ struct custom_metric_t {
 };
 ```
 
+The following distances are pre-packaged:
+
+- `cos_gt<scalar_t>` for "Cosine" or "Angular" distance.
+- `ip_gt<scalar_t>` for "Inner Product" or "Dot Product" distance.
+- `l2sq_gt<scalar_t>` for the squared "L2" or "Euclidean" distance.
+- `jaccard_gt<scalar_t>` for "Jaccard" distance between two ordered sets of unique elements.
+- `bit_hamming_gt<scalar_t>` for "Hamming" distance, as the number of shared bits in hashes.
+- `pearson_correlation_gt<scalar_t>` for "Pearson" correlation between probability distributions.
+- `haversine_gt<scalar_t>` for "Haversine" or "Great Circle" distance between coordinates.
+
+#### Bring your Threads
+
+Most AI, HPC, or Big Data packages use some form of a thread pool.
+Instead of spawning additional threads within USearch, we focus on the thread safety of `add()` function, simplifying resource management.
+
+```cpp
+#pragma omp parallel for
+    for (std::size_t i = 0; i < n; ++i)
+        native.add(label, span_t{vector, dims}, omp_get_thread_num());
+```
+
+During initialization, we allocate enough temporary memory for all the cores on the machine.
+On the call, the user can supply the identifier of the current thread, making this library easy to integrate with OpenMP and similar tools.
+
 ### Python
 
+#### Installation
+
 ```sh
 pip install usearch
 ```
 
-Python bindings are implemented with [`pybind/pybind11`](https://github.com/pybind/pybind11).
-Assuming the presence of Global Interpreter Lock in Python, on large insertions we spawn threads in the C++ layer.
+#### Quickstart
 
 ```python
 import numpy as np
 from usearch.index import Index
 
 index = Index(
-    ndim=256, # Define the number of dimensions in input vectors
-    metric='cos', # Choose the "metric" or "distance", default = 'ip', optional
-    dtype='f32', # Quantize to 'f16' or 'f8' if needed, default = 'f32', optional
+    ndim=3, # Define the number of dimensions in input vectors
+    metric='cos', # Choose 'l2', 'haversine' or other metric, default = 'ip'
+    dtype='f32', # Quantize to 'f16' or 'f8' if needed, default = 'f32'
     connectivity=16, # How frequent should the connections in the graph be, optional
     expansion_add=128, # Control the recall of indexing, optional
     expansion_search=64, # Control the quality of search, optional
 )
 
-vector = np.random.uniform(0, 0.3, (index.ndim)).astype(np.float32)
+vector = np.array([0.2, 0.6, 0.4], dtype=np.float32)
 index.add(42, vector)
 matches, distances, count = index.search(vector, 10)
+
+assert len(index) == 1
+assert count == 1
+assert matches[0] == 42
+assert distances[0] <= 0.001
+```
+
+Python bindings are implemented with [`pybind/pybind11`](https://github.com/pybind/pybind11).
+Assuming the presence of Global Interpreter Lock in Python, we spawn threads in the C++ layer on large insertions.
+
+#### Serialization
+
+```py
+index.save('index.usearch')
+index.load('index.usearch') # Copy the whole index into memory
+index.view('index.usearch') # View from disk without loading in memory
 ```
 
 #### Batch Operations
 
-Same can be done with batches, rather than single entries.
-Under the hood, worker threads will be spawned, to parallelize the procedure.
+Adding or querying a batch of entries is identical to adding a single vector.
+The difference would be in the shape of the tensors.
 
 ```py
 n = 100
 labels = np.array(range(n), dtype=np.longlong)
 vectors = np.random.uniform(0, 0.3, (n, index.ndim)).astype(np.float32)
 
-index.add(labels, vectors)
-matches, distances, counts = index.search(vectors, 10)
+index.add(labels, vectors, threads=..., copy=...)
+matches, distances, counts = index.search(vectors, 10, threads=...)
+
+assert matches.shape[0] == vectors.shape[0]
+assert counts[0] <= 10
 ```
 
-#### Performance
+You can also override the default `threads` and `copy` arguments in bulk workloads.
+The first controls the number of threads spawned for the task.
+The second controls whether the vector itself will be persisted inside the index.
+If you can preserve the lifetime of the vector somewhere else, you can avoid the copy.
 
-To maximize performance, you can:
+#### User-Defined Metrics in Python
 
-- adjust the number of threads passed to `index.add(threads=)`.
-- downcast to half-precision with `Index(accuracy=)`.
-- JIT-compile your metrics for hardware and pass to `Index(matric_pointer=)`.
+Assuming the language boundary exists between Python user code and C++ implementation, there are more efficient solutions than passing a Python callable to the engine.
+Luckily, with the help of [Numba][numba], we can JIT compile a function with a matching signature and pass it down to the engine.
 
-For a dataset with 1 Million 256-dimensional embeddings at single precision, the performance would be:
+```py
+from numba import cfunc, types, carray
+
+signature = types.float32(
+    types.CPointer(types.float32),
+    types.CPointer(types.float32),
+    types.size_t, types.size_t)
+
+@cfunc(signature)
+def python_dot(a, b, n, m):
+    a_array = carray(a, n)
+    b_array = carray(b, n)
+    c = 0.0
+    for i in range(n):
+        c += a_array[i] * b_array[i]
+    return c
+
+index = Index(ndim=ndim, metric_pointer=python_dot.address)
+```
+
+[numba]: https://numba.readthedocs.io/en/stable/reference/jit-compilation.html#c-callbacks
+
+#### Tooling
 
-- FAISS: 77'563 vectors/s.
-- USearch precompiled for old hardware: 53'198 vectors/s (-32%).
-- USearch with Numba JIT for target hardware: 88'658 vectors/s (+14%).
+```py
+from usearch.index import Index
+from usearch.io import load_matrix, save_matrix
+
+vectors = load_matrix('deep1B.fbin')
+index = Index(ndim=vectors.shape[1])
+index.add(labels, vectors)
+```
 
 ### JavaScript
 
+#### Installation
+
 ```sh
 npm install usearch
 ```
 
+#### Quickstart
+
 ```js
-var index = new usearch.Index({ metric: 'cos', connectivity: 16, dimensions: 2 })
-assert.equal(index.connectivity(), 16)
-assert.equal(index.dimensions(), 2)
-assert.equal(index.size(), 0)
+var index = new usearch.Index({ metric: 'cos', connectivity: 16, dimensions: 3 })
+index.add(42, new Float32Array([0.2, 0.6, 0.4]))
+var results = index.search(new Float32Array([0.2, 0.6, 0.4]), 10)
+
+assert.equal(index.size(), 1)
+assert.deepEqual(results.labels, new Uint32Array([42]))
+assert.deepEqual(results.distances, new Float32Array([0]))
+```
 
-index.add(15, new Float32Array([10, 20]))
-assert.equal(index.size(), 2)
+#### Serialization
 
-var results = index.search(new Float32Array([13, 14]), 2)
-assert.deepEqual(results.labels, new Uint32Array([15, 16]))
-assert.deepEqual(results.distances, new Float32Array([45, 130]))
+```js
+index.save('index.usearch')
+index.load('index.usearch')
+index.view('index.usearch')
 ```
 
 ### Rust
 
+#### Installation
+
 ```sh
 cargo add usearch
 ```
 
-Being a systems-programming language, Rust has better control over memory management and concurrency, but lacks function overloading.
-Aside from the `add` and `search`, it also provides `add_in_thread` and `search_in_thread` which let users identify the calling thread to use underlying temporary memory more efficiently.
+#### Quickstart
 
 ```rust
 let quant: &str = "f16";
-let index = new_ip(5, &quant, 0, 0, 0).unwrap();
+let index = new_ip(3, &quant, 0, 0, 0).unwrap();
 
 assert!(index.reserve(10).is_ok());
 assert!(index.capacity() >= 10);
 assert!(index.connectivity() != 0);
-assert_eq!(index.dimensions(), 5);
+assert_eq!(index.dimensions(), 3);
 assert_eq!(index.size(), 0);
 
-let first: [f32; 5] = [0.2, 0.1, 0.2, 0.1, 0.3];
-let second: [f32; 5] = [0.2, 0.1, 0.2, 0.1, 0.3];
+let first: [f32; 3] = [0.2, 0.1, 0.2];
+let second: [f32; 3] = [0.2, 0.1, 0.2];
 
 assert!(index.add(42, &first).is_ok());
 assert!(index.add(43, &second).is_ok());
@@ -314,20 +381,31 @@ assert_eq!(index.size(), 2);
 // Read back the tags
 let results = index.search(&first, 10).unwrap();
 assert_eq!(results.count, 2);
+```
 
-// Validate serialization
+Being a systems-programming language, Rust has better control over memory management and concurrency but lacks function overloading.
+Aside from the `add` and `search`, USearch Rust binding also provides `add_in_thread` and `search_in_thread`, which let users identify the calling thread to use underlying temporary memory more efficiently.
+
+#### Serialization
+
+```rust
 assert!(index.save("index.usearch").is_ok());
 assert!(index.load("index.usearch").is_ok());
 assert!(index.view("index.usearch").is_ok());
+```
+
+#### Metrics
 
-// There are more "metrics" available
-assert!(new_l2(5, &quant, 0, 0, 0).is_ok());
-assert!(new_cos(5, &quant, 0, 0, 0).is_ok());
+```rust
+assert!(new_l2(3, &quant, 0, 0, 0).is_ok());
+assert!(new_cos(3, &quant, 0, 0, 0).is_ok());
 assert!(new_haversine(&quant, 0, 0, 0).is_ok());
 ```
 
 ### Java
 
+#### Installation
+
 ```xml
 <dependency>
   <groupId>cloud.unum.usearch</groupId>
@@ -338,6 +416,8 @@ assert!(new_haversine(&quant, 0, 0, 0).is_ok());
 
 Add that snippet to your `pom.xml` and hit `mvn install`.
 
+#### Quickstart
+
 ```java
 Index index = new Index.Config().metric("cos").dimensions(2).build();
 float vec[] = {10, 20};
@@ -347,10 +427,18 @@ int[] labels = index.search(vec, 5);
 
 ### Swift
 
+#### Installation
+
+```txt
+https://github.com/unum-cloud/usearch
+```
+
+#### Quickstart
+
 ```swift
-let index = Index.l2(dimensions: 4, connectivity: 8)
-let vectorA: [Float32] = [0.3, 0.5, 1.2, 1.4]
-let vectorB: [Float32] = [0.4, 0.2, 1.2, 1.1]
+let index = Index.l2(dimensions: 3, connectivity: 8)
+let vectorA: [Float32] = [0.3, 0.5, 1.2]
+let vectorB: [Float32] = [0.4, 0.2, 1.2]
 index.add(label: 42, vector: vectorA[...])
 index.add(label: 43, vector: vectorB[...])
 
@@ -362,81 +450,11 @@ assert(results.0[0] == 42)
 
 ### Wolfram
 
-## Benchmarking
-
-All major HNSW implementation share an identical list of hyper-parameters:
-
-- connectivity (often called `M`),
-- expansion on additions (often called `efConstruction`),
-- expansion on search (often called `ef`).
-
-The default values vary drastically.
-
-|  Library  | Connectivity | EF @ A | EF @ S |
-| :-------: | :----------: | :----: | :----: |
-| `hnswlib` |      16      |  200   |   10   |
-|  `FAISS`  |      32      |   40   |   16   |
-| `USearch` |      16      |  128   |   64   |
-
-
-To achieve best results, please compile locally and check out various configuration options.
-
-```sh
-cmake -B ./build_release \
-    -DCMAKE_BUILD_TYPE=Release \
-    -DUSEARCH_USE_OPENMP=1 \
-    -DUSEARCH_USE_JEMALLOC=1 && \
-    make -C ./build_release -j
-
-./build_release/bench --help
-```
-
-Which would print the following instructions:
-
-```txt
-SYNOPSIS
-        ./build_release/bench [--vectors <path>] [--queries <path>] [--neighbors <path>] [-b] [-j
-                              <integer>] [-c <integer>] [--expansion-add <integer>]
-                              [--expansion-search <integer>] [--native|--f16quant|--i8quant]
-                              [--ip|--l2|--cos|--haversine] [-h]
-
-OPTIONS
-        --vectors <path>
-                    .fbin file path to construct the index
-
-        --queries <path>
-                    .fbin file path to query the index
-
-        --neighbors <path>
-                    .ibin file path with ground truth
-
-        -b, --big   Will switch to uint40_t for neighbors lists with over 4B entries
-        -j, --threads <integer>
-                    Uses all available cores by default
-
-        -c, --connectivity <integer>
-                    Index granularity
-
-        --expansion-add <integer>
-                    Affects indexing depth
-
-        --expansion-search <integer>
-                    Affects search depth
-
-        --native    Use raw templates instead of type-punned classes
-        --f16quant  Enable `f16_t` quantization
-        --i8quant   Enable `int8_t` quantization
-        --ip        Choose Inner Product metric
-        --l2        Choose L2 Euclidean metric
-        --cos       Choose Angular metric
-        --haversine Choose Haversine metric
-        -h, --help  Print this help information on this tool and exit
-```
-
 ## TODO
 
 - JavaScript: Allow calling from "worker threads".
 - Rust: Allow passing a custom thread ID.
+- C# .NET bindings.
 
 ## AI + Vector Search = Semantic Search
 

package/VERSION

@@ -1 +1 @@
-0.2.3
+0.2.4

package/conanfile.py

@@ -4,7 +4,7 @@ from conans import ConanFile
 class USearchConan(ConanFile):
 
     name = 'USearch'
-    version = '0.2.3'
+    version = '0.2.4'
     license = 'Apache 2.0'
     url = 'https://github.com/unum-cloud/usearch'
     description = 'Smaller & Faster Single-File Vector Search Engine from Unum'