Vous connaissez l'équation de Naviers Stock ?
Je pense qu'elle s'applique à l'informatique. Quand je code, la visualisation des flux et leurs turbulences m'aident à diagnostiquer efficacement.
Prenez une CPU en train de kicker ses instructions sans effet de bord vectorisable sur un bloc de mémoire contigu, je m'imagine en flux laminaire max.
Imagine que mes données sont à accéder depuis de la mémoire non contigüe : hop, page exceptions, avec comme pour les turbulences un aspect certes aléatoires, mais en moyenne de décroissance de la bande passante max d'instructions par seconde. Comme un flux. Ca marche avec les "context switch", les appels au HPET, les barrières mémoires, les flux de périphériques ... mélangeant non pas un flux (les instructions CPU), mais tous les flux coordonnés et influencé par le code exécuté en CPU.
Le code devient une carte symbolique d'architecture de canaux
Le code exécuté devient alors le monde réel de flux se déversant dans des canalisations opaques qui n'ont pas forcément les propriétés qu'on avait imaginé soit en terme de laminarité : je te regarde toi la prédiction de branche. Soit en terme d'isolation (couplage) : je te regarde toi toute la classe des trous de sécus par attaque de canaux latéraux. Donc, on doit comme Platon dans sa caverne deviner depuis les entrées et sorties de nos canaux réels (htop, iotop, ntop, powertop, debogueur ...) ce qui se passe vraiment dans le vaste échangeur à haute vitesse que constitue la CPU. On tente de deviner quand il y a un problème de performance où est la différence entre la carte et le territoire. Où l'on voyait les choses comme des flux laminaires, mais qu'on a une turbulence qui génère de la congestion.
Le code fuit dans le monde réel. Tu kickes ta GPU ton ordi va chauffer, tu kick un périf un peu trop vénère ? Tu peux le voir apparaître sur un port IO voisin. Jusqu'à pouvoir manipuler la mémoire des autres. Tu chauffes un cache, tu vois les latences diminuer avec une exponentielle décroissante comme un fluide qui percole.
Alors, les flux en informatiques ils sont genre multi-dimensionnels (IO, RAM, CPU, GPU) mais il reste dans un lit qui les contraints et unis : celui des ressources de l'ordi et du système d'exploitation qui est comme un aiguilleur borné et opinioné.
Genre un code laminaire (genre de traitement de données) fait face à un afflux de données à traiter qui dépasse sa capacité de traitement. Si rien n'est fait, ça va agir comme une vague qui va comme dans la vraie vie quand les tuyaux sont trop petits générer sans aménagement des turbulences qui vont perturber l'écoulement laminaire...
Une solution est de distribuer les flux. Obligeant à concevoir comme des canaux d'irrigation multiples (haproxys) qui peuvent prendre une charge plus grande, mais pas infinie, les nouveaux coudes, générant des minis tourbillons, du délai.
Souvent, je soupir en voyant les variables "boxée" en python qui sont éparpillées partout en mémoire, kickant des turbulences en pagaille liées aux accès mémoire non contiguë, et je vois les facteurs 100 voir 1000 perdus en turbulence, frictions. Je pense efficience, flux efficace (vs flux total d'instructions générées pour exécuter le code utile incluant la surcouche de l'OS et de la sécurité)
Et justement quand je pense à l'utilisateur, je pense parfois à cette histoire de flux.
Je me dis j'ai soif (aka un besoin) maintenant, qu'est ce que j'attends d'une fontaine (une appli) ? Et bien souvent, je veux que ça arrive vite pour le minimum d'effort en quantité suffisante. Donne moi trop d'eau (information) et tu vas me noyer (genre une vidéo de 1h là où je préférerais un texte de 2Kb). Fais moi faire trop d'effort pour avoir de l'eau tu vas m'épuiser (formulaire à la con). Fais moi attendre 48h pour un bulletin météo à 24h et je vais pas t'aimer. Parfois je veux de l'eau potable (allégorie des sites où l'info originale est trop mélangée avec des communiqué de presse sans critique). Je regarde une vidéo ou téléphone, je déteste les à coup ...
Et je me demande et si, et si au lieu de tenter d'élargir les canaux
comme des porcs, on tentait d'étudier l'écoulement laminaire du code comme si
on rendait l'expression rendre une application fluide une réalité ?
Et quand je regarde le code de quake III (john carmack) c'est exactement ce que je vois : un code fait pour être le plus laminaire possible.
No comments:
Post a Comment