usearch 0.2.2 → 0.2.4

package/README.md

@@ -17,136 +17,126 @@ Vector Search Engine<br/>
 <a href="https://github.com/unum-cloud/usearch"><img height="25" src="https://github.com/unum-cloud/.github/raw/main/assets/github.svg" alt="GitHub"></a>
 </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 [`maratyszcza/fp16`](https://github.com/maratyszcza/fp16).
+<p align="center">
+Euclidean • Angular • Jaccard • Hamming • Haversine • User-Defined Metrics
+<br/>
+<a href="#c++">C++11</a> •
+<a href="#python">Python</a> •
+<a href="#javascript">JavaScript</a> •
+<a href="#java">Java</a> •
+<a href="#rust">Rust</a> •
+<a href="#objective-c">Objective-C</a> •
+<a href="#swift">Swift</a> •
+<a href="#golang">GoLang</a> •
+<a href="#wolfram">Wolfram</a>
+<br/>
+Linux • MacOS • Windows
+</p>
+
+---
+
+- [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] [Any metric](#define-custom-metrics), includes: 
-  - [x] Euclidean, Dot-product, Cosine,
-  - [x] Jaccard, Hamming, Haversine.
-  - [x] Hardware-accelerated [`ashvardanian/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.
-- [x] [Python](#python) bindings: `pip install usearch`.
-- [x] [JavaScript](#javascript) bindings: `npm install usearch`.
-- [x] [Rust](#rust) bindings: `cargo add usearch`.
-- [x] [Java](#java) bindings: `cloud.unum:usearch` on GitHub.
-- [ ] GoLang bindings.
-- [x] Wolfram language bindings.
-- [x] For Linux: GCC, Clang.
-- [x] For MacOS: Apple Clang.
-- [ ] For Windows.
-- [ ] Multi-index lookups in Python.
 - [ ] Thread-safe `reserve`.
-- [ ] Distributed construction with MPI.
-- [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.
+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.
 
-### Bring your Threads
+[haversine]: https://ashvardanian.com/posts/abusing-vector-search#geo-spatial-indexing
+[obscure]: https://ashvardanian.com/posts/abusing-vector-search
 
-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.
+## Memory Efficiency, Downcasting, and Quantization
 
-```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 call, the user can simply supply the identifier of the current thread, making this library easy to integrate with OpenMP and similar tools.
-
-### 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:
 
@@ -155,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:
-
-- `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.
+#### Quickstart
 
-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;
@@ -180,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.
+
+#### Serialization
 
-index.save("index.usearch"); // Serializing to disk
-index.load("index.usearch"); // Reconstructing from disk
+```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>,            //
@@ -198,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 {
@@ -207,82 +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
 
-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.
+#### Installation
 
-```python
-$ pip install usearch
+```sh
+pip install usearch
+```
 
+#### 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
 ```
 
-Same can be done with batches, rather than single entries.
-Under the hood, worker threads will be spawned, to parallelize the procedure.
+#### Batch Operations
+
+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)
 
-# You can avoid copying the data
-# Handy when build 1B+ indexes of memory-mapped files
-index.add(labels, vectors, copy=True)
-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
+```
+
+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.
+
+#### User-Defined Metrics in Python
+
+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.
+
+```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
+
+```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
-// npm install usearch
+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)
 
-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)
+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
 
-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.
+#### Installation
 
-```rust
-// cargo add usearch
+```sh
+cargo add usearch
+```
+
+#### 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());
@@ -291,20 +381,43 @@ assert_eq!(index.size(), 2);
 // Read back the tags
 let results = index.search(&first, 10).unwrap();
 assert_eq!(results.count, 2);
+```
+
+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.
 
-// Validate serialization
+#### 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>
+  <artifactId>usearch</artifactId>
+  <version>0.2.3</version>
+</dependency>
+```
+
+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};
@@ -312,12 +425,20 @@ index.add(42, vec);
 int[] labels = index.search(vec, 5);
 ```
 
-### Objective-C and Swift
+### 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[...])
 
@@ -329,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.2
+0.2.4