Micro-optimisation
Ce que le mot veut dire ici
Un code qui tourne en cycles pleins et qui vide ses registres et ses tampons à la fin de chaque opération ne laisse pas de secret traîner en mémoire : c'est de la sécurité. Un code qui n'alloue rien sur le tas en régime établi ne peut ni fuir, ni fragmenter, ni s'effondrer sous la pression mémoire : c'est de la résilience. Un code qui fait moins d'appels système offre moins de surface au noyau et à ce qui l'observe. La vitesse est le sous-produit visible ; la propriété première est la maîtrise de ce que la machine fait, octet par octet.
go-secretstream, réimplémenté
Chiffrement authentifié de flux xchacha20poly1305, compatible bit à bit avec libsodium, en Go pur sans CGO. Les noyaux SIMD AVX2 ne sont pas écrits à la main : ils sont transpilés mécaniquement depuis le C par notre compilateur, et chaque artefact prouve sa parité bit-exacte contre le même code compilé par gcc -O2 avant d'exister. Défenses contre la troncature, authentification à domaines séparés, effacement explicite des sous-clés et des tampons à la fermeture de chaque flux, comparaison d'étiquette à temps constant. Zéro allocation par opération.
| Taille | Transpilation C→Go de référence | secretstream SIMD | Assembleur Plan 9 |
|---|---|---|---|
| 64 o | 20 Mo/s | 280 Mo/s | 375 Mo/s |
| 1 Ko | 59 Mo/s | 1 265 Mo/s | 2 078 Mo/s |
| 64 Ko | 61 Mo/s | 2 224 Mo/s | 3 145 Mo/s |
| 1 Mo | 61 Mo/s | 2 235 Mo/s | 3 158 Mo/s |
Jusqu'à 36 fois plus rapide que la transpilation de référence, à 70 % de la vitesse de l'assembleur écrit à la main, sans une ligne d'assembleur. Code public : go-secretstream, x-crypto.
ChaCha et Poly1305, refondus
Une famille de noyaux ChaCha20 à une, deux, quatre et huit voies, Poly1305 en une, deux et huit voies, et des noyaux fusionnés qui chiffrent et authentifient en une seule passe. Zéro allocation sur chaque ligne.
| Banc | Notre noyau | Référence |
|---|---|---|
| ChaCha20, huit blocs | 1 486 Mo/s | 559 Mo/s (x/crypto) |
| AEAD 1 350 octets, fusionné | 1 296 Mo/s | 647 Mo/s (séquentiel) |
| AEAD 64 Ko, fusionné | 2 159 Mo/s | 1 482 Mo/s (séquentiel) |
Paquets transpilés publics : c2pkg.
c2db
c2db écrit le JSON d'un modèle de langage directement sur le NVMe. Pas de moteur relationnel entre les deux, pas de sérialisation intermédiaire : un journal append-only, des versions concurrentes, un téraoctet par shard, en Go pur. SQLite ne sert qu'à une chose : vérifier, requête par requête, que c2db rend le même résultat, bit à bit, avec moins d'appels système.
| Opération | c2db | SQLite | Appels write c2db | Appels write SQLite |
|---|---|---|---|---|
| insert | 206 µs | 675 µs | 4 | 528 |
| get | 18 µs | 198 µs | 0 | 0 |
Le compilateur derrière tout cela
Un compilateur C vers Go 1.27 avec instructions vectorielles. La règle est simple et sans exception : aucun fichier Go écrit à la main ne peut se dire transpilé, et aucun artefact transpilé n'existe sans sa preuve de parité bit-exacte contre l'oracle C. C'est l'outil, pas le produit ; mais c'est lui qui rend le reste possible.