Calcul Haute Performance | Valentin Caries

Web-LBM : une soufflerie CFD temps réel dans le navigateur

Fri, 12 Jun 2026 00:00:00 +0000

En une minute

Web-LBM est une soufflerie numérique bidimensionnelle interactive qui s’exécute entièrement dans votre navigateur. Derrière le canvas se trouve un véritable solveur de mécanique des fluides numérique (CFD) : un moteur Boltzmann sur réseau (D2Q9) écrit en C, compilé en WebAssembly et rendu sur le GPU via WebGL2. On peut y déposer un cylindre ou un profil NACA, changer l’angle d’attaque, mettre un obstacle en rotation pour ressentir l’effet Magnus, ou peindre sa propre géométrie à la souris et observer la réponse du sillage. Les coefficients de portance et de traînée s’actualisent en direct, et des microphones virtuels permettent même de voir le son du lâcher tourbillonnaire.

La CFD vit d’ordinaire sur des clusters et des calculs de nuit. L’amener dans un onglet de navigateur, sans installation, sans serveur, sans framework, et hébergée en simples fichiers statiques sur GitHub Pages, est à la fois un parti pris pédagogique et un exercice d’ingénierie. Chaque contrainte de la plateforme a dû être résolue sans sacrifier ni la fidélité physique ni l’interactivité : pas de mémoire partagée par défaut, pas de système de fichiers, et un seul thread sauf à le mériter.

👉 Essayer la simulation · Code source sur GitHub

Points clés

Un vrai solveur. Boltzmann sur réseau D2Q9 avec collision BGK (ou MRT à la compilation), un modèle de turbulence LES de Smagorinsky, une collision régularisée de Hermite pour la stabilité, une entrée en vitesse de Zou–He, des couches éponges absorbantes et une évaluation des efforts par échange de quantité de mouvement qui produit des $C_l$ et $C_d$ en direct.
Des performances temps réel. Une boucle chaude sans branchement et vectorisée SIMD, associée à des threads WebAssembly (pthreads sur SharedArrayBuffer) et à un partitionnement par lignes déterministe et sans verrou.
Un rendu sans copie. Les champs voyagent du tas wasm jusqu’à l’écran sans la moindre copie intermédiaire : des vues typées alimentent une texture WebGL2 R32F, et une table de couleurs est appliquée dans le fragment shader.
L’aéroacoustique en prime. La LBM étant faiblement compressible, le moteur résout les ondes acoustiques. Il propose des vues schlieren ($|\nabla\rho|$) et dilatation ($\nabla\cdot\mathbf{u}$), plus des microphones virtuels avec FFT en direct qui captent le sifflement éolien du sillage.
Un déploiement 100 % statique. Deux variantes du moteur (mono- et multi-thread) sont sélectionnées à l’exécution, et un service worker fournit les en-têtes d’isolation cross-origin que GitHub Pages ne peut pas envoyer.

Pourquoi la CFD dans le navigateur ?

Trois raisons, par ordre de difficulté croissante.

La pédagogie. La mécanique des fluides s’enseigne avec des équations et se valide avec des simulations coûteuses, mais l’intuition naît du lien immédiat entre cause et effet : inclinez un profil et observez le décrochage, faites tourner un cylindre et regardez la portance apparaître. Une simulation interactive dont la boucle de rétroaction se mesure en millisecondes est un outil d’apprentissage fondamentalement différent d’une figure statique.

L’accessibilité. Une page web sans installation ni backend touche tout le monde (étudiants, collègues, recruteurs) sur n’importe quelle machine, indéfiniment, pour un coût d’hébergement nul. Cela impose que tout le solveur tourne côté client, exactement ce que WebAssembly rend possible.

Le défi d’ingénierie. La CFD temps réel met toute la pile à l’épreuve d’un seul coup : une méthode numérique assez stable pour survivre à tout ce que l’utilisateur lui impose, une organisation mémoire que le compilateur sait vectoriser, un modèle de threading compatible avec les contraintes de sécurité du navigateur et un chemin de rendu assez rapide pour ne jamais devenir le goulot d’étranglement. Résoudre les quatre à la fois est le cœur de ce projet.

La physique : Boltzmann sur réseau en bref

Un autre chemin vers la dynamique des fluides

La CFD classique discrétise directement les équations de Navier–Stokes : vitesse et pression vivent sur un maillage, et chaque pas de temps exige la résolution de systèmes couplés globaux, typiquement une équation de Poisson pour la pression, dont la solution relie chaque cellule du domaine à toutes les autres.

La méthode de Boltzmann sur réseau (LBM) travaille un niveau en dessous de la description macroscopique. Elle fait évoluer des fonctions de distribution de particules $f_i(\mathbf{x}, t)$, la quantité de fluide au nœud $\mathbf{x}$ se déplaçant le long d’un petit ensemble de vitesses discrètes $\mathbf{c}_i$. Les champs macroscopiques sont simplement les moments de ces distributions :

$$\rho = \sum_i f_i, \qquad \rho\,\mathbf{u} = \sum_i f_i\,\mathbf{c}_i$$

Un développement de Chapman–Enskog montre que ce système cinétique reproduit les équations de Navier–Stokes incompressibles dans la limite des faibles nombres de Mach. La viscosité du fluide est pilotée par un unique temps de relaxation $\tau$ :

$$\nu = c_s^2\left(\tau - \tfrac{1}{2}\right)$$

Ce qui rend la LBM exceptionnelle pour ce projet, c’est sa localité : chaque nœud ne se met à jour qu’à partir de ses voisins immédiats. Pas de résolution globale, pas d’algèbre linéaire, pas de boucle de convergence. Le coût par pas de temps est donc fixe et prévisible, l’algorithme se parallélise presque trivialement, et la simulation est naturellement instationnaire. Le lâcher tourbillonnaire n’est pas une option que l’on active ; c’est ce que la méthode calcule par défaut. En bonus, la LBM est faiblement compressible : les ondes de pression se propagent physiquement, et la simulation fait de l’acoustique gratuitement.

Collision et propagation

Chaque pas de temps se ramène à deux opérations conceptuellement simples. La collision relaxe les distributions vers un équilibre local (approximation BGK) :

$$f_i(\mathbf{x}, t^{+}) = f_i(\mathbf{x}, t) - \frac{1}{\tau}\left[f_i(\mathbf{x}, t) - f_i^{\mathrm{eq}}(\rho, \mathbf{u})\right]$$

où l’équilibre est un développement au second ordre de la distribution de Maxwell–Boltzmann :

$$f_i^{\mathrm{eq}} = w_i\,\rho\left[1 + \frac{\mathbf{c}_i\cdot\mathbf{u}}{c_s^2} + \frac{(\mathbf{c}_i\cdot\mathbf{u})^2}{2c_s^4} - \frac{\mathbf{u}\cdot\mathbf{u}}{2c_s^2}\right]$$

La propagation (streaming) décale ensuite chaque distribution post-collision vers le nœud voisin dans sa direction de déplacement :

$$f_i(\mathbf{x} + \mathbf{c}_i\,\Delta t,\; t + \Delta t) = f_i(\mathbf{x}, t^{+})$$

La collision est de l’arithmétique purement locale ; la propagation, un pur déplacement mémoire. Du calcul intensif sans communication, suivi de la communication sans calcul, est exactement la structure qu’adorent les unités SIMD et les processeurs multicœurs, et l’implémentation décrite plus bas l’exploite délibérément.

Pourquoi D2Q9

Le moteur utilise le réseau D2Q9 : deux dimensions et neuf vitesses (repos, quatre axiales, quatre diagonales) avec les poids $w_0 = 4/9$, $w_{1\text{–}4} = 1/9$ et $w_{5\text{–}8} = 1/36$. C’est le plus petit réseau 2D dont les moments de vitesse sont suffisamment isotropes pour retrouver correctement Navier–Stokes. Moins de directions biaiseraient la physique le long des axes de la grille, et davantage coûteraient mémoire et bande passante sans gain à ce niveau de description. Neuf champs float par nœud fixent aussi le budget mémoire : une grille 600 × 300 tient confortablement dans quelques dizaines de mégaoctets de tas wasm.

Conditions aux limites

Les frontières sont l’endroit où une implémentation LBM fait ses preuves, car après la propagation les distributions entrant dans le domaine depuis l’extérieur sont inconnues et doivent être reconstruites.

Entrée. Une condition en vitesse de Zou–He impose le profil d’entrée (uniforme, couche cisaillée ou jet) en reconstruisant les distributions inconnues à partir des contraintes de masse et de quantité de mouvement. Un démarrage progressif sur 400 pas accompagne chaque (ré)initialisation, pour que le démarrage impulsif ne lance pas une onde de choc dans la veine.
Sortie. Une extrapolation à gradient nul, adossée à une couche éponge absorbante qui augmente progressivement la dissipation près de la frontière, pour que tourbillons et ondes acoustiques quittent le domaine au lieu de s’y réfléchir.
Obstacles. Le rebond (bounce-back) renvoie d’où elles viennent les distributions qui frappent un nœud solide, produisant une paroi adhérente sans aucun maillage. Sa variante à paroi mobile ajoute la quantité de mouvement de la paroi aux populations réfléchies, ce qui constitue toute l’implémentation du cylindre tournant, l’effet Magnus découlant alors de la physique. La somme des quantités de mouvement échangées dans ces réflexions donne l’effort aérodynamique sur chaque corps (les $C_l$ et $C_d$ affichés en direct) pour un coût quasi nul.
Parois de la veine. Au choix : glissement libre (réflexion spéculaire) ou adhérence (rebond).

Mise en œuvre

Architecture

Le projet se compose de deux parties proprement séparées, reliées par un unique tampon mémoire partagé :

Moteur C (lbm.c, C99) --emcc--> WebAssembly + tas wasm
 │ vues Float32Array sans copie
Frontend ES6 vanilla ── textures WebGL2 R32F ──> LUT de couleurs dans le shader

Le moteur est un unique fichier C99 réunissant le solveur D2Q9, la LES, les conditions aux limites, les rastériseurs analytiques de formes (cylindre, plaque plane, NACA 0012 / 4412), l’évaluation des efforts et le calcul des champs dérivés (vitesse, pression, vorticité, schlieren, dilatation). Il expose une petite API C plate (lbm_init, lbm_step, lbm_set_params, …) et ignore tout de JavaScript.
Le frontend est en modules ES6 vanilla, sans framework, sans bundler et sans aucune étape de build au-delà d’emcc lui-même. main.js pilote la boucle de simulation et l’interface, renderer.js possède WebGL2, et obstacles.js définit les formes analytiques.
Deux variantes du moteur sont produites à partir de la même source : une version mono-thread qui fonctionne partout, et une version -pthread utilisant les threads WebAssembly. L’application détecte crossOriginIsolated au démarrage, choisit la meilleure, et assure un repli transparent.

Le chemin de données sans copie

La règle cardinale du pipeline de rendu : les champs ne sont jamais copiés côté JavaScript. Le moteur C calcule par exemple la vorticité dans un tableau float du tas wasm. JavaScript enveloppe cette mémoire dans une vue Float32Array (aucune allocation, aucune copie) et la passe directement à texSubImage2D, qui la téléverse dans une texture flottante mono-canal (R32F). Le fragment shader fait ensuite correspondre les valeurs aux couleurs via une petite texture de table de correspondance, si bien que tout l’habillage visuel coûte une lecture de texture par pixel et vit sur le GPU.

Deux subtilités maintiennent cette promesse. Quand le tas wasm grandit (l’utilisateur choisit une grille plus fine), l’ArrayBuffer sous-jacent se détache et chaque vue doit être reconstruite, ce que l’application fait paresseusement, à la demande. Et dans la version multithread, le tas est un SharedArrayBuffer, que certains navigateurs refusent de téléverser directement ; un unique petit tampon de transit constitue la seule exception sanctionnée à la règle du zéro copie.

Du multithreading dans un navigateur

Le balayage intérieur est partitionné par lignes sur un pool de pthreads wasm, avec des barrières séparant les phases de chaque pas de temps. Le partitionnement garantit que chaque case du tableau de destination a exactement un producteur. Les threads ne sont jamais en concurrence, donc ni verrous ni atomiques dans le chemin chaud. Les contributions aux efforts sont réduites dans un ordre de threads fixe, ce qui rend les résultats déterministes au bit près à nombre de threads donné, une exigence empruntée aux bonnes pratiques du HPC, où « rapide mais légèrement différent à chaque exécution » est la cachette préférée des bugs.

Le threading en navigateur a un piège : SharedArrayBuffer exige que la page soit isolée cross-origin, ce qui requiert des en-têtes HTTP COOP/COEP qu’un hébergeur statique comme GitHub Pages ne peut pas envoyer. Web-LBM résout cela avec un service worker de portée racine qui injecte les en-têtes côté client (un rechargement automatique à la première visite). Si quoi que ce soit échoue dans cette chaîne (navigateur ancien, isolation partielle), l’application démarre silencieusement le moteur mono-thread. C’est l’amélioration progressive appliquée au HPC.

Interaction

Tout, dans la soufflerie, se manipule pendant que la simulation tourne. Les obstacles se placent au clic, pivotent, tournent sur eux-mêmes (cylindres en rotation) ou se peignent à main levée à la souris, directement dans le masque d’obstacles. Les cellules peintes sont rééchantillonnées quand la résolution de grille change, tandis que les formes prédéfinies sont re-rastérisées analytiquement depuis leur registre, si bien qu’un profil NACA reste un profil NACA net à n’importe quelle résolution. L’écoulement se visualise en vitesse, pression, vorticité, schlieren ou dilatation, avec des surcouches de lignes de courant et de particules. Des microphones virtuels se déposent n’importe où dans le champ pour tracer la FFT en direct du signal de pression local ; en placer un derrière un cylindre révèle le pic spectral net de la fréquence de lâcher, la même physique que le sifflement du vent dans les fils.

Défis d’ingénierie

La stabilité numérique sans arbitre

Une simulation interactive ne peut pas refuser les entrées de l’utilisateur : quels que soient le nombre de Reynolds, la forme d’obstacle ou la résolution choisis, le solveur ne doit pas diverger. Le BGK brut devient instable quand $\tau \to 1/2$ (hauts nombres de Reynolds) ; le moteur superpose donc plusieurs défenses, chacune visant un mode de défaillance distinct.

Un modèle LES de Smagorinsky ($C_s = 0{,}18$) calcule une viscosité turbulente locale à partir du taux de déformation (obtenu en LBM directement depuis les distributions hors équilibre, sans différences finies). Il modélise à la fois les échelles turbulentes non résolues et éloigne le $\tau$ effectif de la limite instable précisément là où l’écoulement est le plus cisaillé.
La régularisation de Hermite projette la partie hors équilibre des distributions sur sa composante physiquement signifiante (Hermite d’ordre deux) avant la collision, filtrant les modes parasites d’ordre supérieur qui, sinon, s’accumulent et déstabilisent les grilles grossières.
Un amortissement de viscosité de volume dissipe sélectivement la partie acoustique du tenseur des contraintes, calmant les oscillations de pression sans toucher à la physique du cisaillement qui crée les tourbillons.
Les couches éponges et le démarrage progressif de l’entrée éliminent les deux transitoires classiques : les ondes réfléchies en sortie et l’impulsion initiale.

Le résultat est une soufflerie qui survit aux mauvais traitements, ce qui fait la différence entre une démo et un produit.

Ce que vous pouvez explorer

Quelques expériences d’une minute chacune dans la soufflerie en ligne :

Le lâcher tourbillonnaire. Gardez le cylindre par défaut, passez en vue vorticité et regardez l’allée de von Kármán s’établir ; le HUD montre $C_l$ oscillant à la fréquence de lâcher.
Le décrochage. Placez un profil NACA 4412 et augmentez l’angle d’attaque : le coefficient de portance grimpe, puis l’écoulement décolle à l’extrados.
L’effet Magnus. Faites tourner un cylindre et observez le sillage dévier et une portance stationnaire apparaître, la physique des coups francs enroulés.
L’aéroacoustique. Passez en vue schlieren ou dilatation pour voir les ondes de pression rayonner depuis le sillage, puis déposez un microphone derrière le cylindre et retrouvez le ton de lâcher dans le spectre en direct.
Votre propre géométrie. Peignez un obstacle arbitraire à la souris et regardez l’écoulement composer avec.

Compétences démontrées

Mécanique des fluides numérique : la méthode de Boltzmann sur réseau de bout en bout, incluant le choix du réseau, les modèles de collision (BGK, MRT, régularisation), les conditions aux limites, la modélisation de la turbulence (LES de Smagorinsky), l’évaluation des efforts et l’aéroacoustique.
Méthodes numériques et calcul scientifique : l’analyse de stabilité en pratique, c’est-à-dire identifier les modes de défaillance et superposer des remèdes ciblés, dans un moteur physique en C99 portable avec tests de validation embarqués.
Ingénierie de la performance : des noyaux sans branchement adaptés au SIMD, une organisation mémoire en structure de tableaux, un multithreading déterministe sans verrou et une séparation des chemins chauds et froids guidée par le profilage.
Architecture logicielle : une frontière stricte moteur/frontend avec un contrat de données zéro copie à travers la frontière C/JavaScript, et une détection de capacités à l’exécution avec dégradation élégante.
Technologies web : WebAssembly (Emscripten, threads wasm, mémoire partagée), WebGL2 (textures flottantes, colorisation dans le shader), service workers et déploiement entièrement statique.
Visualisation scientifique interactive et conception d’interface : rendu de champs en temps réel, vues multiples physiquement signifiantes, et une interface qui invite à l’expérimentation sans mode d’emploi.
Communication scientifique : rendre tangible, et ludique, une mécanique des fluides de niveau master pour un public technique généraliste.

Dépôt

Tout le code est ouvert : le moteur C (abondamment commenté, jusqu’à chaque drapeau de compilation et sa justification), le moteur de rendu WebGL2, les scripts de build et les tests physiques de validation.

Le code vit sur github.com/vcaries/web_lbm, et la soufflerie elle-même tourne sur vcaries.github.io/web_lbm.

Conclusion

Web-LBM condense tout l’éventail de l’ingénierie de simulation dans une seule page que chacun peut ouvrir : une méthode numérique cinétique, la modélisation de la turbulence, l’optimisation SIMD et multithread, le rendu GPU et une interaction de qualité produit. La méthode de Boltzmann sur réseau est le choix qui rend tout possible, car elle est locale, parallèle, naturellement instationnaire et discrètement capable d’acoustique. Le navigateur est la contrainte qui structure tout, puisque chacune de ses limites a dû être contournée par l’ingénierie plutôt qu’éludée. Le résultat : une soufflerie dans un onglet, et la démonstration que le vrai calcul scientifique n’est pas condamné à vivre derrière une file d’attente sur un cluster.

BoidForge : ingénierie des comportements collectifs du Python au C natif

Fri, 05 Jun 2026 00:00:00 +0000

En une minute

BoidForge est un simulateur de nuées 2D bâti autour d’un principe unique : une nuée est calculée une fois puis rendue ensuite, jamais les deux en même temps. Un solveur fait avancer la physique et écrit chaque pas de temps dans un fichier binaire compact. Un moteur de visualisation distinct rejoue ensuite ce fichier sur le GPU. Les deux moitiés ne partagent aucune mémoire, seulement un format sur disque, de sorte que chacune peut être optimisée séparément.

Il en résulte un projet à parts égales calcul numérique et graphisme temps réel. Le même modèle de nuée est implémenté dans quatre backends interchangeables, depuis une référence Python naïve jusqu’à une extension C écrite à la main, et tous les quatre produisent des résultats strictement identiques jusqu’au dernier bit. Un moteur de rendu ModernGL transforme ensuite les trajectoires brutes en la séquence cinématographique ci-dessous.

Vidéo. La scène turbulence, rendue hors-ligne en 4K à 60 ips et colorée par la vitesse. Elle a été produite en rejouant une simulation enregistrée dans le moteur de visualisation GPU décrit plus bas.

👉 Code source sur GitHub

Points forts

Un modèle, quatre backends, une sortie identique. Python naïf (L1), NumPy vectorisé (L2), un hachage spatial sur grille uniforme (L3) et un noyau natif C/CPython (L4), tous identiques bit à bit sous un contrat de déterminisme strict.
Jusqu’à environ 330 fois plus rapide. Le backend C atteint environ 120 à 330 fois le débit de la référence naïve sur la plage testée, et est conçu pour passer à l’échelle de dizaines de milliers d’agents.
Visualisation GPU en ModernGL. Sprites instanciés, accumulation HDR additive, traînées de mouvement, bloom et tonemapping ACES, rendus sans affichage et transmis directement à FFmpeg pour l’export 4K.
Reproductible par construction. Chaque résultat est une fonction pure de la configuration et d’une graine, si bien que les mêmes entrées donnent les mêmes octets sur n’importe quelle machine.

Inspirations

Ce projet est né de deux références de la culture scientifique et technique en ligne. La première est Smarter Every Day, dont la vidéo sur les murmurations d’étourneaux montre comment des milliers d’oiseaux peuvent se comporter comme un seul corps fluide, et pose la question naturelle de la façon dont un tel ordre peut émerger sans chef et sans plan. La seconde est Sebastian Lague et sa série Coding Adventures, dont l’épisode consacré aux boids montre comment quelques règles locales se traduisent en code et combien de beauté visuelle une simulation simple peut contenir. BoidForge est ma manière de prendre cette curiosité au sérieux en ingénieur : reproduire le phénomène fidèlement, le pousser à une échelle où l’émergence devient évidente, et le rendre assez bien pour rendre justice aux véritables murmurations.

Le modèle de nuée

Le comportement de nuée est un phénomène émergent. Il n’y a ni chef ni plan global, et pourtant des milliers d’agents s’organisent en un mouvement cohérent, semblable à un fluide. La formulation classique est le modèle des boids de Craig Reynolds (1987), dans lequel chaque agent obéit à trois règles de pilotage locales, calculées uniquement à partir des voisins situés dans un rayon donné.

Soit un agent $i$ de position $\mathbf{p}_i$ et de vitesse $\mathbf{v}_i$. Notons $\mathcal{N}_i$ l’ensemble de ses voisins situés dans le rayon de la règle évaluée. Chaque règle produit une accélération de pilotage.

La séparation empêche la nuée de s’effondrer sur elle-même. Chaque agent est repoussé par ses voisins proches, et la poussée est d’autant plus forte qu’ils sont près :

$$\mathbf{a}_{\text{sep}} = w_{\text{sep}} \sum_{j \in \mathcal{N}_i} \frac{\mathbf{p}_i - \mathbf{p}_j}{\lVert \mathbf{p}_i - \mathbf{p}_j \rVert^{2}}$$

La pondération en inverse du carré est le détail important : un voisin deux fois plus proche repousse quatre fois plus fort, ce qui espace les agents et évite les collisions.

L’alignement fait voyager les voisins de concert, en orientant chaque agent vers la vitesse moyenne $\overline{\mathbf{v}}$ de son voisinage :

$$\mathbf{a}_{\text{ali}} = w_{\text{ali}} \left( \overline{\mathbf{v}} - \mathbf{v}_i \right)$$

La cohésion maintient le groupe rassemblé, en dirigeant chaque agent vers le centre de masse local $\overline{\mathbf{p}}$ de son voisinage :

$$\mathbf{a}_{\text{coh}} = w_{\text{coh}} \left( \overline{\mathbf{p}} - \mathbf{p}_i \right)$$

Les trois contributions sont sommées en une seule accélération $\mathbf{a}_i$, dont la norme est plafonnée à une force de pilotage maximale. La vitesse est alors avancée par un pas d’Euler explicite, puis bornée à une plage $[v_{\min}, v_{\max}]$ pour que les agents ne se figent jamais ni ne s’emballent :

$$\mathbf{v}_i \leftarrow \mathbf{v}_i + \mathbf{a}_i \Delta t$$

Enfin, la position est avancée avec cette nouvelle vitesse, et une règle de bord (rebouclage ou réflexion) maintient la nuée à l’intérieur du domaine :

$$\mathbf{p}_i \leftarrow \mathbf{p}_i + \mathbf{v}_i \Delta t$$

Chaque règle possède son propre rayon, et les trois poids $w_{\text{sep}}$, $w_{\text{ali}}$, $w_{\text{coh}}$ donnent à une simulation son caractère. Leur réglage est ce qui produit les scènes murmuration, banc de poissons, plasma et turbulence du dépôt. Le modèle est court à énoncer. Le travail d’ingénierie consiste à le rendre rapide et reproductible.

Le goulot d’étranglement de calcul

Le coût du modèle est dominé par une seule question. Pour chaque agent, quels sont les autres agents qui sont ses voisins ? Répondue naïvement, chaque agent est comparé à tous les autres, soit $O(N^2)$ calculs de distance par pas de temps. À quelques centaines d’agents, cela reste inoffensif. À des dizaines de milliers, c’est sans espoir, car la croissance quadratique signifie qu’une nuée dix fois plus grande coûte cent fois plus cher.

BoidForge s’attaque au problème selon deux axes indépendants, et donne à chacun son propre backend afin que la contribution de chaque idée puisse être mesurée plutôt que supposée :

Abaisser le facteur constant. Effectuer le même travail $O(N^2)$, mais l’exprimer en moins d’instructions, plus rapides. C’est le chemin de la boucle Python vers le NumPy vectorisé, puis vers le C natif.
Abaisser la complexité. Cesser totalement d’effectuer un travail $O(N^2)$, en n’inspectant que les agents susceptibles d’être voisins. C’est la grille spatiale, qui ramène la recherche à environ $O(N)$.

Les quatre backends sont soumis à un unique contrat de déterminisme : pour une même configuration et une même graine, ils doivent émettre une sortie identique octet par octet. Le backend naïf est la référence, et tout backend qui s’en écarte est faux par définition. Un test exécute chaque backend et compare leurs images. C’est une contrainte exigeante, car elle force même le noyau C à reproduire l’ordre de sommation float32 exact de NumPy, mais c’est elle qui rend les gains de vitesse dignes de confiance plutôt que simplement rapides.

Quatre backends, et ce que chacun apporte

L1, Python naïf (la référence)

Une implémentation directe, toutes paires, avec une boucle Python explicite sur chaque paire d’agents. Elle est volontairement simple, car son seul rôle est de définir la correction. Tous les autres backends sont validés contre elle. C’est aussi, sans surprise, le plus lent, puisque le surcoût par élément de l’interpréteur Python s’ajoute au travail $O(N^2)$.

L2, NumPy vectorisé

Le même algorithme toutes paires, réexprimé avec NumPy. Les termes de déplacement, de distance et de séparation par paire sont construits une fois sous forme de tableaux entiers, et les bornages ainsi que l’intégration s’exécutent en opérations groupées sur ces tableaux.

Pourquoi c’est plus rapide. L’arithmétique sort de l’interpréteur Python pour passer dans les boucles C compilées de NumPy, ce qui supprime le surcoût par élément. Sur les petites et moyennes nuées, le gain est d’environ un facteur deux. Il n’est pas gratuit pour autant. Les tableaux par paire coûtent une mémoire $O(N^2)$, et au sommet de la plage testée, le coût du transfert de ces grands tableaux en mémoire annule le gain, au point que L2 est légèrement plus lent que L1 à 2000 agents. Ce compromis est la leçon en soi : la vectorisation achète de la vitesse avec de la mémoire, et à grande échelle, la mémoire devient la ressource limitante.

L3, hachage spatial sur grille uniforme

Le premier changement algorithmique. Les agents sont rangés dans une grille dont le côté de cellule égale le rayon de voisinage. Chaque agent n’inspecte alors que sa propre cellule et les huit qui l’entourent, un bloc de trois sur trois, au lieu de toute la nuée. Comme le côté de cellule égale le rayon, tout voisin réel tombe forcément dans ce bloc, de sorte que la grille élague du travail sans jamais manquer un voisin.

Pourquoi c’est plus rapide. Cela fait passer la complexité de la recherche de voisins de $O(N^2)$ à environ $O(N)$. Le travail par agent cesse de croître avec la taille de la nuée et ne dépend plus que de la densité locale. C’est l’idée qui rend les grandes nuées traitables en principe. En Python pur, toutefois, la gestion de la construction de la grille et du rassemblement des candidats comporte assez de surcoût pour que, aux tailles modestes testées ici, son temps reste proche de celui de la boucle naïve. L’algorithme est correct, mais il attend un langage hôte plus rapide pour porter ses fruits.

L4, extension C native (la cible de production)

Cet hôte plus rapide est une extension C de CPython écrite à la main, développée avec l’API C brute et compilée avec CMake via scikit-build-core. Elle combine la grille $O(N)$ de L3 à un ensemble d’optimisations de bas niveau hors de portée de Python :

Des tampons en structure de tableaux, partagés sans copie. L’état réside en quatre tableaux float32 contigus (positions et vitesses) partagés avec NumPy via le protocole tampon. Il n’y a pas de copie, pas de surcoût d’objet par agent, et une disposition mémoire que le processeur peut parcourir efficacement en flux.
Un tri par comptage en cellules. La grille est construite par un tri par comptage dans une disposition compacte plutôt que par une table de hachage, de sorte que le rassemblement des voisins est une boucle serrée sur des indices contigus, et non des recherches dans un dictionnaire.
Le verrou de l’interpréteur est libéré autour de la boucle de calcul, si bien que le gros du travail numérique s’exécute en véritable code natif, affranchi du verrou global de Python.
Aucune allocation mémoire dans la boucle critique. Un unique espace de travail est dimensionné une fois par pas de temps, et la boucle interne par agent n’appelle jamais l’allocateur.

Pourquoi c’est plus rapide. Chacun de ces points supprime une couche de surcoût à laquelle les backends Python ne peuvent échapper, à savoir la répartition de l’interpréteur, l’indirection d’objets et la pression sur l’allocateur, tout en conservant la recherche de voisins $O(N)$. Ensemble, ils procurent environ 120 à 330 fois le débit de la référence naïve et mettent des dizaines de milliers d’agents à portée. Et tout cela en produisant une sortie identique à L1 jusqu’au bit, ce qui a exigé de reproduire exactement en C l’algorithme de sommation par paires de NumPy afin que l’arrondi float32 corresponde.

Bancs d’essai

Le banc de mesure chronomètre chaque backend sur un balayage de tailles de nuée, de 100 à 2000 agents, sur 200 pas chacun et après un préchauffage, en enregistrant le temps moyen par image et l’accélération relative à L1.

Figure 1. Temps par image en fonction de la taille de la nuée, en axes logarithmiques. Les backends naïf (L1), vectorisé (L2) et hachage spatial Python (L3) restent proches à ces tailles, tandis que le backend C natif (L4) s'exécute un à deux ordres de grandeur en dessous. L'écart qui se creuse vers la droite est la grille $O(N)$ qui se détache du coût toutes paires $O(N^2)$. (Cliquez pour agrandir.)

Figure 2. Accélération par rapport à la référence naïve. Le backend natif domine, culminant autour de 330 fois à 200 agents et se maintenant bien au-dessus de 100 fois sur toute la plage, tandis que les optimisations Python pur (L2 et L3) restent proches de 1 à ces tailles. Cela confirme que le gain décisif vient du passage de l'algorithme $O(N)$ en C, et non de la seule vectorisation.

À 2000 agents, la référence naïve dépense environ 202 ms par image, soit l’équivalent de 5 images par seconde, tandis que le backend C dépense environ 1,7 ms, soit l’équivalent de 590 images par seconde. C’est la même physique calculée environ 120 fois plus vite, avec une avance qui continue de croître à mesure que la nuée grandit.

Visualisation avec ModernGL

Le moteur de rendu ne simule jamais. Il lit les images précalculées dans le flux binaire et transforme chacune en image sur le GPU. Il est bâti directement sur ModernGL, une liaison fine et moderne vers OpenGL 3.3, avec des shaders GLSL écrits à la main, et c’est délibérément un petit pipeline de post-traitement plutôt qu’un moteur de jeu :

Téléversement et tracé. Chaque image est téléversée dans un tampon de sommets GPU et chaque agent est tracé comme un unique sprite ponctuel. Le fragment shader façonne chaque sprite en un cœur lumineux diffus entouré d’un large halo, et sa couleur est lue dans une petite texture de palette indexée par la vitesse, le cap, la densité locale ou une valeur fixe.
Accumulation HDR additive. Les sprites sont mélangés de manière additive dans un tampon en virgule flottante, si bien que les agents qui se chevauchent accumulent une véritable luminosité. C’est ce qui donne aux grappes denses leur aspect lumineux.
Traînées de mouvement. Au lieu d’effacer ce tampon entre deux images, on l’estompe légèrement vers le noir. Les agents laissent donc derrière eux des traînées décroissantes, source de la sensation de mouvement soyeuse et fluide.
Bloom. Une passe de seuil ne conserve que les pixels les plus lumineux, un flou gaussien séparable les étale, et la lueur est réinjectée, produisant le halo cinématographique autour des régions rapides et denses.
Composition. Un dernier shader plein écran applique un tonemapping filmique ACES pour ramener la scène à grande plage dynamique dans une plage affichable, avec exposition, vignette optionnelle, teinte de fond et correction gamma.

Comme le contexte GPU peut être créé hors écran, ce même moteur de rendu fonctionne sans affichage sur une machine sans écran. Pour la vidéo, les images rendues sont transmises directement à un sous-processus FFmpeg qui encode en H.264, sans jamais conserver tout le clip en mémoire. C’est ainsi qu’a été produite la séquence 4K en tête de page.

Architecture : deux sous-systèmes, un contrat

La règle de conception derrière tout ce qui précède est une séparation stricte entre calculer la nuée et la dessiner :

Solveur (calcul) ---> flux binaire .bfs ---> Moteur de visualisation ---> images / vidéo

Le solveur n’importe rien de la couche de visualisation, sans OpenGL ni aucun graphisme, et la couche de visualisation ne fait jamais avancer la physique. Leur seule connaissance partagée est un petit format binaire versionné (.bfs) : un en-tête de 32 octets suivi d’un enregistrement par image contenant le nombre d’agents et les quatre tableaux float32 bout à bout. Cette disposition est choisie pour que le solveur puisse écrire chaque tableau en une seule opération groupée et que le moteur de rendu puisse le mapper directement dans un tampon GPU sans réempaquetage de part et d’autre. Un test statique sur les frontières d’import garantit la séparation pour qu’elle ne s’érode pas avec le temps.

Ce découplage est ce qui permet d’optimiser le solveur pour le débit brut et le moteur de rendu pour la qualité d’image, chacun selon ses propres critères. C’est aussi pourquoi une longue simulation peut être calculée une fois puis rendue à nouveau plus tard avec d’autres couleurs, traînées ou résolutions, autant de fois que nécessaire.

Compétences démontrées

Calcul haute performance : réduction de complexité algorithmique de $O(N^2)$ à $O(N)$ par hachage spatial, vectorisation NumPy et ses compromis mémoire, et une extension C de CPython écrite à la main avec tampons sans copie, libération du verrou de l’interpréteur et boucle critique sans allocation.
Rigueur numérique : un contrat de déterminisme exact au bit près entre quatre implémentations indépendantes, dont la reproduction en C de la sommation par paires float32 de NumPy.
GPU et graphisme temps réel : un pipeline ModernGL et GLSL avec accumulation HDR, traînées de mouvement, bloom et tonemapping ACES, fonctionnant sans affichage et exportant via FFmpeg.
Architecture logicielle : deux sous-systèmes strictement découplés reliés seulement par un format binaire versionné, avec une frontière d’import imposée.
Discipline d’ingénierie : un code Python typé, documenté et testé (ruff, mypy --strict, pytest), une compilation native CMake et scikit-build-core, et la reproductibilité traitée comme une exigence de premier ordre.

Dépôt

L’intégralité du code source est ouverte, y compris les quatre backends de solveur, le noyau C, la couche d’entrée et sortie binaire, le banc de mesure et le moteur de visualisation ModernGL.

Le code se trouve sur github.com/vcaries/boid_forge, accompagné d’un document d’architecture qui décrit en détail le format binaire et le contrat de déterminisme.

Conclusion

Un modèle de nuée tient en trois lignes d’algèbre vectorielle. Le faire passer à l’échelle est un projet d’ingénierie. BoidForge mène le modèle d’une référence Python transparente à un noyau C natif deux ordres de grandeur plus rapide, prouve à chaque étape que la vitesse supplémentaire ne coûte rien en correction, puis rend le résultat sous une forme réellement digne d’être regardée, le tout dans une architecture nette où calcul et rendu ne se touchent jamais. Le plus difficile n’a jamais été les boids. C’était de les rendre rapides, reproductibles et beaux.