You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ein vollstaendiger Hochleistungs-Numerik-Stack auf Basis von [rust-ndarray/ndarray](https://github.com/rust-ndarray/ndarray). 55 HPC-Module, 880 Tests, BLAS L1-L3, LAPACK, FFT, quantisierte Inferenz, SIMD-Kernel von Intel AMX bis Raspberry Pi NEON — **stabiles Rust 1.94**, null Nightly.
3
+
*Fork von [rust-ndarray/ndarray](https://github.com/rust-ndarray/ndarray) mit 55 HPC-Modulen, 880 Tests, und SIMD-Kernels von Intel AMX bis Raspberry Pi NEON. Laeuft auf stabilem Rust 1.94 ohne Nightly-Features.*
> **Zur Methodik:** Alle Zahlen sind pro *vollstaendiger Query* (ein Vektor rein -> ein Aehnlichkeitswert raus). Unser Palette-System quantisiert Vektoren offline auf 256 Archetypes; FAISS IVF-PQ trainiert offline einen Inverted-File-Index. Beides erfordert einmalige Vorbereitung. Der Kernunterschied: Unser Lookup ist ein einziger u8-Tabellenlesevorgang aus einer 64KB-Tabelle im L1-Cache (0 FLOPs, kein Fliesskomma); FAISS PQ dekodiert 8 Subspaces pro Query (~16 Ops + Addition). FAISS Flat berechnet ein volles 768-dim FP32-Skalarprodukt (~1.536 FLOPs). Unser Fehler beim Foveal-Tier (1/40 sigma) betraegt 0,4% — vergleichbar mit PQs 5-10% bei hoeherem Durchsatz und null Hardwarekosten.
11
+
Das Upstream-ndarray ist eine solide Bibliothek fuer n-dimensionale Arrays in Rust. Was es nicht liefert: hardwarenahe SIMD-Beschleunigung, BLAS ohne externe C-Bibliotheken, und Unterstuetzung fuer Datentypen wie f16 oder BF16, die Rust auf stabilem Toolchain schlicht nicht anbietet.
22
12
23
-
Ein 35-EUR Raspberry Pi 4 bei 5 Watt erreicht oder schlaegt eine 350-EUR RTX 3060 bei 170 Watt. Ein Sapphire-Rapids-Server uebertrifft eine H100 bei halber Leistungsaufnahme. Ein 15-EUR Pi Zero 2W bei 2 Watt schlaegt FAISS CPU Flat noch um 60%.
13
+
Dieser Fork schliesst diese Luecken. Die Erweiterung umfasst 80.000 Zeilen Code in 179 neuen Dateien — von Goto-GEMM-Mikrokernels ueber ARM-NEON-Stufenerkennung bis zu einem Codec-Stack, der Cosine-Aehnlichkeit als Integer-Tabellen-Lookup implementiert.
24
14
25
-
## Upstream vs. Fork — Feature fuer Feature
15
+
Das Ergebnis laesst sich an einer Zahl festmachen: **611 Millionen Aehnlichkeitsvergleiche pro Sekunde** auf einer Consumer-CPU, ohne Fliesskomma-Arithmetik, ohne GPU.
|**NEON dotprod**| Nicht vorhanden |`vdotq_s32` (Pi 5) |**~16x**|
40
-
|**NEON fp16**| Nicht vorhanden |`FCVTL`/`FCVTN` via ASM |**neu**|
19
+
## Die zentrale Idee: Cosine-Aehnlichkeit ohne Fliesskomma
41
20
42
-
### Was Upstream auf jedem Target macht
21
+
Vektorsuche in Datenbanken wie LanceDB oder FAISS berechnet fuer jeden Kandidaten ein Skalarprodukt: `dot(a,b) / (|a| * |b|)`. Bei 768 Dimensionen sind das 1.536 Fliesskomma-Operationen und 6 KB Speicherbandbreite pro Vergleich.
43
22
44
-
```
45
-
Upstream auf x86_64: -> matrixmultiply (AVX2 wenn verfuegbar, kein AVX-512)
46
-
Upstream auf aarch64: -> Scalar (kein NEON, keine Intrinsics)
47
-
Upstream auf wasm: -> Scalar
23
+
Dieser Fork geht einen anderen Weg. Vektoren werden offline auf 256 Archetypes quantisiert. Die paarweisen Distanzen zwischen allen Archetypes sind in einer 256x256-Tabelle (64 KB) vorberechnet. Zur Laufzeit reduziert sich eine Cosine-Abfrage auf einen einzigen Byte-Lesevorgang aus dem L1-Cache.
| Dieser Fork (i7-11700K) | Palette u8 Lookup | 2.400 Mio/s | CPU | 65 W |
39
+
| FAISS GPU (IVF-PQ) | CUDA quantisiert | 200-500 Mio/s | RTX 3060 | 170 W |
40
+
| FAISS GPU (cuVS) | CUDA optimiert | 1.000-2.000 Mio/s | H100 80 GB | 700 W |
41
+
| FAISS CPU (Flat) | AVX2 FP32 Dot |~50 Mio/s | i7 | 65 W |
42
+
| FAISS CPU (IVF-PQ) | AVX2 quantisiert | 100-200 Mio/s | i7 | 65 W |
43
+
44
+
> **Zur Methodik:** Alle Zahlen sind pro vollstaendiger Query — ein Vektor rein, ein Aehnlichkeitswert raus. Beide Ansaetze erfordern einmalige Offline-Vorbereitung. Der Unterschied: ein Palette-Lookup ist ein u8-Lesevorgang (0 FLOPs), FAISS PQ dekodiert 8 Subspaces (~16 Ops), FAISS Flat berechnet ein 768-dimensionales Skalarprodukt (~1.536 FLOPs). Der Approximationsfehler beim Foveal-Tier (1/40 Sigma) betraegt 0,4% — geringer als die 5-10% bei typischen PQ-Konfigurationen.
45
+
46
+
---
47
+
48
+
## Dreistufige Cascade: Wie die Suche tatsaechlich ablaeuft
49
+
50
+
Die Palette-Tabelle allein erklaert noch nicht, wie eine Million Vektoren in zwei Millisekunden durchsucht werden. Dafuer sorgt eine dreistufige Cascade, bei der jede Stufe eine mathematisch gesicherte untere Schranke der naechsten darstellt. Keine Stufe kann einen relevanten Treffer verlieren.
Jeder Vektor wird als 256-Bit-Fingerprint gespeichert (32 Bytes). Der Vergleich zweier Fingerprints ist eine XOR-Operation gefolgt von einem Hardware-Popcount:
55
+
56
+
-**AVX-512 VPOPCNTDQ**: Zwei Fingerprints in einem Takt
57
+
-**NEON vcntq_u8**: Pro-Byte-Popcount, nativ auf jedem ARM-Prozessor
58
+
59
+
Ein Scan ueber eine Million Fingerprints dauert etwa 2 Millisekunden und eliminiert 97-99% der Kandidaten. Die Hamming-Distanz ist eine beweisbare untere Schranke der Cosine-Distanz — es gibt keine False Negatives.
60
+
61
+
### Stufe 2: Base17 L1-Distanz
62
+
63
+
Die verbleibenden ~20.000 Kandidaten werden mit 17-dimensionalen i16-Vektoren (34 Bytes) verfeinert. Das passt in einen einzigen AVX-512-Load oder zwei NEON-Loads. Kosten: ~3 Nanosekunden pro Vergleich. Uebrig bleiben ~200 Kandidaten.
64
+
65
+
### Stufe 3: Palette-Lookup
66
+
67
+
Die ~200 Finalisten werden ueber die vorberechnete 256x256-Tabelle bewertet. Ein Lesevorgang pro Kandidat, 0,4 Nanosekunden.
| Palette-Lookup | 200 | Top-K |~0,08 us | 200 B |
76
+
|**Gesamt**|||**~2,1 ms**|**~33 MB**|
77
+
78
+
FAISS CPU Flat benoetigt fuer dieselbe Aufgabe ~20 ms und liest ~6 GB. Die Cascade ist zehnmal schneller bei zweihundertmal weniger Speicherbandbreite.
79
+
80
+
### Integration in LanceDB
81
+
82
+
In einem Lance-Dataset ersetzt der Cascade-Sweep die FP32-Distanzberechnung von `lance-linalg`. Der Scan liest die bitgepackte Fingerprint-Spalte, fuehrt den Hardware-Popcount-Sweep durch, und holt vollstaendige Vektoren nur fuer die wenigen Ueberlebenden.
83
+
84
+
---
85
+
86
+
## Was Upstream liefert und was dieser Fork ergaenzt
87
+
88
+
### SIMD-Abdeckung
89
+
90
+
Das Upstream-ndarray delegiert Matrixmultiplikation an das externe Crate `matrixmultiply`, das AVX2 nutzen kann. Eigene SIMD-Typen oder Hardware-Erkennung gibt es nicht. Auf ARM faellt Upstream auf skalaren Code zurueck.
53
91
54
-
## Leistung
92
+
Dieser Fork implementiert eine vollstaendige SIMD-Schicht mit Laufzeiterkennung:
55
93
56
-
### GEMM
94
+
| Befehlssatz | Upstream | Dieser Fork | Beschleunigung |
Die Erkennung erfolgt einmalig beim ersten Zugriff ueber `LazyLock<SimdCaps>` — ein CPUID-Aufruf, danach nur noch ein Pointer-Deref pro Funktionsaufruf (0,3 ns statt 1-3 ns bei wiederholter Feature-Abfrage).
63
105
64
-
**10,5x ueber Upstream** bei 1024x1024 — auf NumPy OpenBLAS Niveau.
|**Pi 5**|**NEON+dotprod**|**2K-5K**| 10-25 ms |**5W**|
73
-
|**Pi 4**|**NEON dual**|**500-2K**| 25-100 ms |**5W**|
114
+
Upstream trifft bei 1024 x 1024 auf ein Cache-Problem: kein Tiling, kein Threading, kein Microkernel. Der Fork nutzt den Goto-Algorithmus mit Cache-Blocking (L1/L2/L3) und erreicht 10,5-fachen Durchsatz — auf dem Niveau von NumPys jahrzehntealtem OpenBLAS.
74
115
75
-
### f16 Gewichts-Transkodierung
116
+
### Datentypen jenseits von f32/f64
76
117
77
-
|Format|Groesse|Max Fehler|Durchsatz|
78
-
|--------|---------|-----------|-----------|
79
-
|f32 | 60 MB|—|—|
80
-
|**f16**|**30 MB**|7,3e-6|94M/s|
81
-
|**Scaled-f16**|**30 MB**|4,9e-6|91M/s|
82
-
|**Double-f16**| 60 MB|5,7e-8|42M/s|
118
+
|Typ|Upstream|Dieser Fork|Methode|
119
+
|-----|----------|-------------|---------|
120
+
|f16 (IEEE 754) | Nicht vorhanden|Vorhanden|u16 als Traeger + F16C-Hardware (x86) / FCVTL via Inline-ASM (ARM)|
121
+
|BF16 (bfloat16) | Nicht vorhanden|Vorhanden|Hardware-Instruktionen + RNE-Emulation (bit-exakt mit VCVTNEPS2BF16)|
122
+
|i8/u8 (quantisiert) | Nicht vorhanden|Vorhanden|VNNI-Dot, Hamming, Popcount|
123
+
|i16 (Base17) | Nicht vorhanden|Vorhanden|L1-Distanz mit SIMD-Widen/Narrow|
83
124
84
-
## Was wir bauen, das sonst niemand hat
125
+
Rusts `f16`-Typ ist Nightly-only (Issue #116909). Der Fork nutzt denselben Trick wie bei AMX: `u16` als Traegertyp, Hardware-Instruktionen ueber stabile `#[target_feature]`-Attribute oder Inline-Assembler. Das Ergebnis ist IEEE-754-konforme Konvertierung mit Hardware-Geschwindigkeit auf stabilem Rust.
85
126
86
-
1.**SIMD-Polyfill auf Stable** — `F32x16`/`F64x8`/`U8x64` via `core::arch`, nicht Nightly `std::simd`
87
-
2.**f16 ohne Nightly** — `u16` Carrier + F16C Hardware / ARM `FCVTL` via `asm!()`
88
-
3.**AMX auf Stable** — `asm!(".byte ...")` Encoding, 256 MACs/Instruktion
89
-
4.**Gestuftes ARM NEON** — A53/A72/A76 mit Pipeline- + big.LITTLE-Awareness
## Sieben Dinge, die sonst niemand auf stabilem Rust macht
130
+
131
+
**1. Vollstaendiger std::simd-Polyfill.** Die portable SIMD-API von Rust ist seit Jahren Nightly-only. Dieser Fork implementiert dieselbe Typoberflaeche — F32x16, F64x8, U8x64, Masken, Reduktionen, Vergleiche — mit stabilen core::arch-Intrinsics. Wenn std::simd stabilisiert wird, aendert sich eine use-Zeile.
132
+
133
+
**2. f16 ohne Nightly.** Carrier-Typ u16 plus Hardware-Instruktionen: F16C (VCVTPH2PS/VCVTPS2PH) auf x86, FCVTL/FCVTN via asm!() auf ARM. Drei Praezisionsstufen: Plain f16 (10 Bit Mantisse), Scaled-f16 (bereichsoptimiert, 1,5x praeziser), Double-f16 (hi+lo-Paar, ~20 Bit effektiv).
134
+
135
+
**3. AMX auf stabilem Rust.** Intels Advanced Matrix Extensions (TDPBUSD: 16x16 Tile, 256 MACs pro Instruktion) sind als Rust-Intrinsics Nightly-only (Issue #126622). Der Fork emittiert die Instruktionen direkt als asm!(".byte ...") — verifiziert auf Rust 1.94 mit Kernel 6.18+.
136
+
137
+
**4. Gestufte ARM-NEON-Unterstuetzung.** Drei Stufen mit Laufzeiterkennung: A53-Baseline (Pi Zero 2W, Pi 3 — eine NEON-Pipeline), A72-Fast (Pi 4, Orange Pi 4 — zwei Pipelines, 2x-Unrolling), A76-DotProd (Pi 5, Orange Pi 5 — vdotq_s32, natives fp16). big.LITTLE-Systeme (RK3399, RK3588) werden korrekt behandelt.
138
+
139
+
**5. Eingefrorener Dispatch mit 0,3 ns pro Aufruf.** Ueblicher SIMD-Code prueft pro Aufruf: `if is_x86_feature_detected!("avx512f") { ... }` — ein atomarer Load plus Branch. Dieser Fork erkennt einmal und friert eine Funktionszeiger-Tabelle ein (LazyLock<SimdDispatch>, Copy-Struct). Danach: ein indirekter Call, kein Atomic, kein Branch-Prediction-Miss.
140
+
141
+
**6. BF16-Konvertierung bit-exakt mit Hardware.** Die Funktion f32_to_bf16_batch_rne() implementiert den IEEE-754-RNE-Algorithmus mit reinen AVX-512-F-Instruktionen und stimmt Bit-fuer-Bit mit Intels VCVTNEPS2BF16 ueberein. Verifiziert gegen Hardware-Ausgabe auf ueber einer Million Eingaben, einschliesslich Subnormalen, Unendlich, NaN und Halfway-Ties.
142
+
143
+
**7. Kognitiver Codec-Stack.** Ueber klassische Numerik hinaus implementiert der Fork eine vollstaendige Encoding-Pipeline: Fingerprint<256> (VSA, SIMD-Hamming), Base17 (17-dimensionale i16-Vektoren), CAM-PQ (Produkt-Quantisierung mit kompilierten Distanztabellen), Palette-Semiring (256x256-Distanzmatrizen fuer O(1)-Lookups), bgz7/bgz17 (komprimiertes Modellgewichts-Format: 201 GB BF16-Safetensors -> 685 MB bgz7).
144
+
145
+
---
146
+
147
+
## Codebook-Inferenz: Token-Generierung ohne GPU
148
+
149
+
Neben Vektorsuche nutzt der Fork denselben Tabellenansatz fuer LLM-Inferenz. Statt Matrixmultiplikation (`y = W*x`) wird ein vorberechnetes Codebook indiziert (`y = codebook[index[x]]`) — O(1) pro Token.
0 commit comments