ThePrimeagen n'avait pas besoin de SIMD.

Il le dit lui-même. Sur le jeu qu'il développe, son profilage montre que la partie concernée par ce genre d'optimisation représente très peu du temps d'exécution. Il avait déjà croisé le concept, utilisé des fonctions optimisées par d'autres, mais jamais écrit lui-même un morceau de code SIMD pour résoudre un vrai petit problème.

Puis Mitchell Hashimoto publie « Everyone Should Know SIMD ». Les commentaires se crispent surtout sur « everyone » et « should ».

Alors Prime fait une chose assez raisonnable face à un débat Internet : au lieu de continuer à discuter du titre, il essaie le truc.

Savoir reconnaître une forme avant d'en avoir besoin

SIMD signifie Single Instruction, Multiple Data.

L'idée de base est moins mystique que son acronyme. Au lieu d'appliquer une même opération à une valeur, puis à la suivante, puis à la suivante, certaines instructions du processeur peuvent travailler sur plusieurs valeurs en parallèle.

Hashimoto ne défend pas l'idée que chaque développeur doit devenir spécialiste des jeux d'instructions AVX ou NEON. Son billet propose une ambition beaucoup plus petite : connaître suffisamment la forme du problème pour remarquer qu'un morceau de code pourrait bénéficier de SIMD.

Dans son exemple, la structure revient à préparer des valeurs vectorielles, parcourir les données par blocs de la largeur disponible, appliquer l'opération SIMD, récupérer le résultat puis traiter proprement ce qui reste à la fin.

Ce n'est pas quelque chose qu'on va coller sur tous les for parce qu'on a lu un article le matin. Et c'est justement là que le sujet devient intéressant.

Le savoir peut être utile bien avant son usage.

Prime construit un problème exprès

Plutôt que de chercher un endroit où forcer SIMD dans son jeu, Prime invente un petit exercice adapté : parcourir beaucoup d'octets pour retrouver certains caractères.

Il commence par une version naïve, puis écrit une version qui traite plusieurs octets ensemble. Son benchmark local donne un gros écart en faveur de SIMD.

Le chiffre précis importe assez peu. Ce test ne prouve rien sur votre application, votre processeur ou votre langage. Hashimoto lui-même montre des gains qui dépendent du matériel et surtout du chemin de code concerné.

Ce que Prime récupère est ailleurs.

À la fin, il explique qu'il ne compte probablement pas utiliser SIMD prochainement. Son jeu n'en a toujours pas besoin. Mais il reconnaît désormais la forme d'un futur problème où cette famille d'instructions pourrait devenir intéressante.

Avant l'exercice : « SIMD, truc de performance très bas niveau. »

Après : « si j'ai une grosse boucle qui applique la même opération à un paquet de données indépendantes, je sais qu'il existe peut-être une autre manière de la regarder. »

Ce petit déplacement mental vaut souvent plus qu'une API mémorisée.

L'IA rend ce type d'apprentissage plus bizarre, pas moins utile

On pourrait faire l'argument inverse : pourquoi apprendre la mécanique si un modèle peut écrire l'implémentation le jour où elle devient nécessaire ?

Le problème est que pour demander quelque chose, il faut au moins soupçonner que la chose existe.

Un agent peut proposer une optimisation. Il peut aussi ne pas la proposer, la proposer au mauvais endroit ou produire une version plus complexe qui n'améliore rien. Sans modèle mental minimal, on échange simplement une boîte noire contre une autre et on choisit celle qui répond avec le plus d'assurance.

Connaître SIMD ne signifie pas savoir réécrire une bibliothèque multimédia à la main. Ça peut seulement donner assez de vocabulaire pour demander : « est-ce que ce traitement répétitif est vectorisable ? », puis mesurer la réponse.

C'est une différence importante dans une pratique assistée par agents. Plus la machine sait produire du code spécialisé, plus savoir reconnaître les familles de solutions devient intéressant.

Pas forcément les écrire de mémoire. Les reconnaître.

Toute connaissance n'a pas besoin d'un ticket Jira

Prime dit avoir passé environ une heure à comprendre, programmer et débugger son exercice. Ce temps n'est évidemment pas une promesse pour tout le monde.

Mais j'aime bien l'idée de consacrer parfois une heure à quelque chose dont on n'a pas besoin immédiatement.

La logique productiviste du développement pousse facilement à apprendre uniquement ce que le ticket du jour exige. C'est efficace jusqu'au moment où tous les problèmes commencent à ressembler aux cinq outils qu'on connaît déjà.

Il y a une différence entre apprendre une technologie parce qu'on pense devoir l'utiliser et apprendre un concept pour agrandir la carte.

SIMD peut rester inutilisé pendant cinq ans. Le jour où une boucle devient réellement coûteuse, avoir déjà vu cette forme peut faire gagner beaucoup plus qu'une heure.

Ou ne servir absolument jamais.

Ce n'est pas forcément un échec. La curiosité technique n'a pas besoin de produire un ROI avant la fin du sprint pour avoir le droit d'exister.