On me disait souvent, lorsque j'étais à l'école primaire par exemple, que
j'avais toujours la tête dans les nuages. C'était une manière de parler,
très imagée et en rapport avec un comportement contemplatif qui m'a
toujours caractérisé.
Après de nombreuses recherches, l'enthousiasme s'est calmé devant la complexité
cachée par le modèle physique et ses limites inhérentes. Mais cette année de
maîtrise me permet de franchir deux caps :
Les programmes de simulation nous posent tous le même problème : "Qu'est-ce que
la réalité ?". Pour effectuer une simulation, il faut bien comprendre ce que l'on fait
et ce que l'on simule. Et pourtant, bien que ce soit des sujets quotidiens et banals,
je ne connais aucun logiciel qui puisse simuler explicitement de manière
satisfaisante les choses suivantes:
L'avénement des ordinateurs personnels, des serveurs et des réseaux accessibles à tous,
la diffusion libre et instantannée de l'information et le développement exponentiel de
l'électronique digitale, tout en nous affranchissant du "monde réel", nous permettent
de jeter un nouveau regard dessus.
aux nuages, gardiens de nos rêves
(Puisse-t-il y en avoir toujours à nos fenêtres) |
L'aventure de ce mémoire n'aurait pu se dérouler sans les personnes suivantes,
que je tiens à remercier vivement :
- Pierre Audibert pour son accompagnement et son intérêt pour l'aventure,
- Patrick Greussay pour sa curiosité sans limite et ses discussions toujours stimulantes,
- Les professeurs du département MIME pour leur aide et l'enseignement qui m'a permis de lever les difficultés posées par les nombreux domaines traités ici,
- Umberto D'ortona, Bruce Boghosian, Harlan W. Stockman, Frédéric Quémeneur, Stéphane Zaleski et bien d'autres encore pour m'avoir expliqué les subtilités théoriques du modèle FHP et de la mécanique des fluides en général,
- La Communauté des Internautes pour sa connaissance infinie d'encyclopédie vivante et à laquelle ce mémoire est confié en retour.
Enfin, je serais ingrat d'oublier tous ceux et toutes celles dont le soutien moral m'aura permis de surmonter les difficultés existencielles liées à mon statut d'étudiant informaticien isolé. Je ne nommerai que ma famille, Yannick Sustrac (si tu lis ça, c'est que j'ai réussi à le faire, ce programme), Zsuzsa, toutes les Toriphiles et le Bocal.
L'objet de ce mémoire est d'expliquer pas à pas la fabrication d'un programme
interactif de simulation d'écoulements de fluides.
Le but du travail exposé ici est d'améliorer autant que possible les performances de ce programme, tant en vitesse qu'en flexibilité et en utilisabilité des résultats des calculs.
La fonction de ce programme est de faciliter et rendre accessibles ces calculs à des personnes a priori non spécialistes en informatique ou qui ne peuvent pas passer de temps à optimiser ce type programmes.
Même s'il ne peut pas être exhaustif, ce mémoire aborde des sujets très variés autant théoriques que pratiques qui contribuent chacun à améliorer la performance du programme : physique, mécanique des fluides, structure des ordinateurs et des processeurs, fonctionnement des systèmes d'exploitation, assembleur, calculs booléens, synthèse logique, compilation, algorithmique, périphériques et interfaces...
L'audience visée par ce mémoire est les informaticiens, dans la perspective d'améliorer leurs programmes pour les processeurs de cinquième génération, et les physiciens, pour leur procurer un outil efficace d'exploration des gaz sur réseau. De nombreux domaines peuvent néanmoins bénéficier des points de vue discutés dans le mémoire
Ce mémoire est principalement une étude d'un cas simple et n'a pas la prétention d'apporter directement d'amélioration dans le domaine scientifique, mais le modèle étudié (FHP) sert de base, ou est très proche des modèles plus évolués (Bolzman par exemple) et plus performants qui sont apparus ensuite. Il est donc probable qu'une amélioration au niveau du modèle FHP puisse être réutilisée dans d'autres modèles.
Ce mémoire a été rédigé directement en HTML dans un simple éditeur de texte, afin de faciliter sa diffusion électronique et sa maintenance sans outil spécialisé.
Le texte a été formaté pour être transformé par HTMLDOC dans le format PDF avant impression, ce qui explique la curieuse présentation du fichier HTML dans un brouteur. HTMLDOC est un programme diffusé sous licence GPL. Il a été réalisé par Mike Sweet et peut être chargé à http://www.easysw.com/~mike/htmldoc/.
Ce mémoire sera mis en ligne sur le serveur du département MIME à l'adresse http://www.mime.univ-paris8.fr ainsi que sur mes pages personelles, qui contiennent des documents supplémentaires comme une bibliothèque de profils vectoriels d'ailes d'avions.
Introduction
De la performance
Tout est affaire de priorités
Un beoin criant de performance
Ressources bibliographiques et électroniques
Où l'on discute de la définition de la performance et de l'utilisation des ordinateurs dans le contexte de la simulation scientifique. L'importance de l'interactivité est soulignée et la philosophie du projet est précisée dans cette optique.
D'un point de vue tout à fait abstrait, nous pourrions convenir de la définition suivante :
le but de la simulation est de ramener à l'échelle humaine du temps et de l'espace,
des phénomènes physiques inobservables directement, tout en conservant autant que possible
les propriétés intrinsèques des objets étudiés, afin de mieux les comprendre.
Cependant, il faut reconnaitre que cette mise à l'échelle s'effectue grâce à un modèle qui peut être très incomplet et nous sommes constament confrontés à ses limitations, en plus des limitations imposées par les conditions initiales de la simulation. Nous essayons donc de reproduire une réalité dans des conditions précises.
La simulation scientifique peut aussi bien tenter d'éprouver un modèle (afin de le valider) que de l'utiliser afin de valider une autre théorie. Dans ces deux cas, et pour le sujet qui nous concerne, cela consiste à exécuter, faire fonctionner le modèle en lui donnant les conditions initiales désirées, et comparer les résultats avec ceux que la théorie prédit. L'expérimentateur (car il s'agit d'expériences sur un monde, même si ce n'est pas le monde réel) a le choix de modifier sa théorie, son modèle et ses conditions d'expérience afin d'affiner ses recherches.
En reproduisant un monde aux propriétés restreintes et contrôlées, la simulation permet d'accélérer l'établissement d'une théorie grâce à sa fonction de mise à l'échelle spatio-temporelle. Une simulation est donc une succession d'expériences dont les résultats pourraient avoir des conséquences dramatiques ou destructrices dans le monde réel (simulation de vol ou d'explosion atomique). Cette succession itérative, cette répétition d'expériences a un aspect particulièrement lourd pour les humains dans le cas de modèles très complexes car le temps d'exécution du modèle peut devenir inacceptablement long. L'avénement des ordinateurs a permis aux modèles de s'affiner considérablement, au prix d'une complexité inhumaine. C'est ici qu'intervient l'interface étrange entre le monde des scientifiques et le monde des informaticiens, deux castes culturelles entre lesquelles la communication est assez difficile, et la tension est forte car chacun a des besoins particuliers et un entendement différent de ce que "performance" ou "vitesse" signifie.
La caricature grossière qui suit a pour but de montrer la différence fondamentale qui existe entre les scientifiques et les informaticiens. Pour un scientifique, un ordinateur est une calculatrice très grosse, très chère et très rapide comparée à une rège à calcul ou une calculatrice de poche, ce qui permet de faire "tourner" automatiquement les modèles plus rapidement qu'à la main.
Mais une caractéristique fondamentale rend cette machine complexe plus précieuse qu'un simple outil à calculer : un ordinateur est flexible, dans le sens où Von Neumann l'a décrit et défini. Une fois chargées les informations nécessaires, l'Ordinateur devient autonome dans les conditions définies par l'utilisateur. L'ordinateur de Von Neumann est configurable par programmation, il exécute les opérations qu'on lui demande et il peut les exécuter à volonté.
Avec sa large diffusion et les rapides évolutions technologiques et industrielles, l'une accélérant l'autre et vice versa, l'ordinateur est devenu la bête de somme, le cheval de labour des scientifiques, ces derniers créant, les premiers calculant, l'ensemble constituant un monde "virtuel" que les scientifiques rapprochent jour après jour de la réalité.
La création des ordinateurs, bien que dûe principalement à des mathématiciens, a été accompagnée par l'apparition des informaticiens. Ces êtres vivent dans un monde différent, mais tout aussi virtuel que celui des scientifiques. Le monde des informaticiens est carré, simplifié, avec des pas de temps unitaires, indivisibles, synchrones, à l'opposé des physiciens et de leurs symboles, des coordonnées, des valeurs et des variables continues et des équations abstraites qui les relient. Ce qui est simple pour l'un est complexe pour l'autre. L'exemple le plus évident est le problèmes des nombres en virgule flottante qui est un casse-tête aussi bien pour les équations physiques que pour les ordinateurs. La résolution de ce type de problème passe obligatoirement par des compromis qui dépendent étroitement des circonstances, des besoins et des moyens.
La distinction principale que nous pouvons faire au niveau de ce mémoire entre les physiciens et les informaticiens est leur vue de ce qu'est un ordinateur. Pour les premiers, qui n'ont pas souvent de compréhension profonde du fonctionnement interne d'un ordinateur, ce n'est qu'une machine, un outil qu'ils essaient de faire fonctionner dans le sens de leurs besoins. Pour les informaticiens, l'ordinateur est l'objet de leur préoccupation, de même que la théorie, l'hypothèse, est l'objet d'attention du physicien. De nombreux parallèles existent pour comprendre ce type de rapports : le garagiste s'occupe de la voiture du client qui l'utilise pour aller au travail, le maréchal-ferrant ferre le cheval pour que le jockey puisse gagner une course...
Toutefois, cette spécialisation, ce cloisonnement, a intérêt à disparaître lorsque les éléments dépendent beaucoup les uns des autres, à tous les bouts de la chaîne d'efficacité. Une compréhension globale du problème à résoudre permet d'éliminer des étapes intermédiaires inutiles. Mais actuellement, je ne connais pas de physicien qui soit tout aussi brillant en physique qu'en science des ordinateurs, à part Harlan Stockman. Ainsi, de par leurs penchants respectifs, les uns et les autres vont utiliser l'ordinateur selon leur connaissance et en tirer plus ou moins d'avantages : les physisciens vont faire fonctionner leurs modèles efficaces avec des programmes qui ne sont moins efficaces que ce que l'ordinateur peut potentiellement opérer, alors que les informaticiens, par manque de compréhension de la Physique, feront fonctionner un modèle peu efficace, mais de la manière la plus adaptée à l'ordinateur.
Le fonctionnement rapide et efficace d'un modèle est toutefois inutile si les conditions de simulations ne correspondent à rien, ou si les résultats ne peuvent être extraits et analysés. Enfin, l'analyse doit se faire le plus rapidement possible afin de conclure sur le succès de l'expérimentation, et recommencer une nouvelle simulation au plus tôt. Ces trois points sont des axes importants de ce mémoire et justifient la grande complexité du projet : l'intérêt du programme réside aussi bien dans son interface que dans sa vitesse de calcul. Le calcul doit donc être intimement lié à la visualisation afin de fournir les résultats le plus rapidement possible à l'utilisateur.
Le critère subjectif de performance du projet est donc la vitesse d'analyse et de compréhension des phénomènes que le programme procure à l'utilisateur. Pour celà, l'intéractivité, la possibilité d'influencer une expérience en cours, est un atout important car la plupart des programmes de simulation de fluide (C.F.D., Computational Fluid Dynamics) fonctionnent comme des "boîtes noires" qui fournissent une masse gigantesque de données à la fin d'un long temps de calcul (qui se mesure souvent en heures ou en journées). Le projet permet donc de faire "fonctionner" le modèle, mais aussi d'interagir avec le monde qu'il simule.
L'obstacle majeur dans l'utilisation du calcul à haute performance est la complexité des ordinateurs et des algorithme, des structures de données et des techniques mises en jeu. Les physiciens sont normalement plus concernés par la démonstration d'une formule que par l'option correcte à donner à un compilateur. Or, en tant qu'élève en informatique et électronique, je dispose des connaissances et des outils nécessaires pour lever les barrières de la complexité. En contrepartie, la validité physique des simulations est laissée à la discrétion de l'utilisateur : je ne fais que l'outil, et je ne suis pas responsable de sa mauvaise utilisation. La priorité du travail est donc la technique, afin de laisser à l'utilisateur tout le loisir de l'expérimentation.
Evidemment, on ne peut pas se contenter de faire une belle interface à un programme lent pour qu'il devienne efficace. La discussion précédente tentait de montrer que la vitesse n'est pas utile si on ne pouvait pas contrôler son utilisation, à la manière d'une voiture très rapide mais sans volant.
Une fois la question du contrôle consciencieusement considérée, on se souvient que la raison principale de la course à la technologie est la vitesse. Cela revient simplement à effectuer le maximum d'opérations (ne pas confondre avec les instructions) en un minimum de temps. Evidemment, la réalité est un peu plus complexe...
Nous considérerons maintenant que les cas suivants ne posent aucun problème quant à la qualité de la programmation. Dans tous les cas, cependant, de nombreuses limitations subsistent, comme nous allons le voir : la qualité du code est une condition nécessaire mais non suffisante pour faire fonctionner un programme rapidement.
Si l'on prend par exemple la simulation bidimensionnelle d'un flûte à bec avec
le modèle utilisé dans ce mémoire, on se rend vite compte que les technologies
actuelles sont incapables de l'effectuer en temps réel.
Considérons que la flûte fait 300 points de long, que la vitesse du son est de sqrt(3/7)
cellules par pas de temps,
et que la note jouée est un LA (440Hz), alors il faudra effectuer (440*300*2)/0,65=4.10^5
pas de temps sur une surface de minimum 400*300=1,2.10^5 sites, ce qui nécessite 5.10^10
calculs de sites par seconde, dans des conditions idéales et théoriques. Or même avec la
technologie de phosphure d'indium,
il n'existe pas encore d'ordinateur qui fonctionne à 50GHz et les rares et coûteux
ordinateurs "téraflops" sont peu adaptés à ce travail. Tous les paramètres deviennent
alors cruciaux et le parallélisme joue un rôle déterminant.
Ce petit exemple montre que la simulation directe de phénomènes physiques, même modestes, est hors de notre portée technologique. Cela veut dire que dans notre réalité d'epérimentateurs, il faudra faire fonctionner des ordinateurs très longtemps pour simuler un gros phénomène, ou alors réduire considérablement le domaine de simulation pour que le calcul puisse s'effectuer en temps réel.
La contrepartie de la performance à la technologie est le temps de calcul. Nous pouvons considérer que la technologie est "fixe" dans le temps de l'étude, car l'outil de calcul a une durée de vie plus longue que l'étude. Il est assez peu fréquent dans la pratique qu'un nouvel ordinateur soit acheté spécialement à l'occasion d'un projet. Il faut donc "payer" le manque de ressources par du temps de calcul.
Même avec des ordinateurs gigantesques, il n'est pas étonnant que des calucls de simulation durent des jours, des semaines voire parfois des mois. Dans ces conditions, il devient évident que la moindre amélioration, même de 1% seulement, permet de gagner un temps précieux, c'est toujours une minute ou une heure de moins à attendre.
Ainsi, comme il ne s'agit pas d'un programme commercial mais d'une application critique, la philosophie de développement est de gagner autant de temps à l'exécution que raisonnablement
L'objectif est très clair : obtenir la performance à tout prix, pour un problème très bien cerné et une plateforme particulière et connue. Il s'agit ici de calcul scientifique projeté dans le monde pratique, avec ses contraintes de temps, d'argent et de facilité.
Après quelques essais, il s'avère que les implémentation de gaz sur réseau peuvent être énormément accélérées sur les ordinateurs "classiques", par la prise en compte des particularités de leur architecture et la mise au point de meilleures structures de données et d'algorithmes associés.
Cela nécessite de se renseigner le plus possible sur tous les domaines concernés. Ce travail adopte donc une approche latérale, en considérant un maximum de paramètres à la fois. On utilise donc une vision top-bottom (du modèle vers le programme) et une vision bottom-top (du processeur vers l'algorithme) en aillant soin de garder à l'esprit la fonction à réaliser.
Afin de mieux isoler les contraintes, chaque partie du programme sera étudiée indépendament puis le programme sera construit progressivement en intégrant les éléments au fur et à mesure tout en en mesurant leur impact sur les performances.
Le mémoire est invisiblement scindé en deux parties :
- La partie théorique synthétise les travaux déjà réalisés et constitue la
recherche bibliographique qui fournit les fondements du mémoire, à partir
desquels la deuxième partie peut être échaffaudée.
- La partie pratique est le travail effectif de cette année, explorant
les facettes des ordinateurs PC et les processeurs de cinquième génération,
devant aboutir à un programme permettant la simulation intéractive de
phénomènes de mécanique des fluides.
Le mémoire fait principalement appel à des notions de deux domaines très différents : la mécanique des fluides, domaine de la physique à la fois abstrait et réel, étudié intensément depuis un siècle, et l'informatique à un niveau très proche des microprocesseurs, qui se développe au fur et à mesure que les générations de processeurs se succèdent, tous les trois ou quatre ans environ. Ce mémoire doit faire un lien pratique entre ces disciplines afin de rendre le meilleur des deux mondes.
Le travail réalisé ici n'est possible que parce que j'ai passé deux ans à préparer
les outils, les algorithmes et leurs intéractions. C'est en effet un domaine
assez complexe comme le montre la première partie, la préparation est donc importante.
Le but du travail étant d'implémenter le "moteur" de LGA, peu de simulations
de phénomènes réels ne seront effectuées, à part quelques-unes à la fin,
puisque le problème est la performance, et les propriétés et la validité des
LGA ont été prouvés par de nombreuses personnes auparavant. En conservant
les propriétés de base dans l'optimisation, la simulation des phénomènes
ne devrait pas être perturbée, sauf en vitesse.
Les programmes qui seront exécutés n'auront pour fonction que de valider les
algorithmes, les pièces individuelles du programme ou les théories.
Ce moteur sera utilisé par d'autres personnes qui en auront besoin dans leur
travail, et seront responsables des conditions d'utilisation, puisqu'elles
devraient savoir mieux que moi comment s'en servir : je ne suis qu'un informaticien,
pas un physicien !
Finalement, après les premières recherches documentaires, la modification d'anciens programmes a mis au jour des défauts de conception que j'ai corrigé, ce qui a permis de définir quelques règles de codage et de formaliser une théorie sur les lois de collisions. En plus d'être un recueil d'exemples pratiques d'optimisation, ce mémoire s'aventure donc aussi dans le domaine théorique, sans pour autant aligner une seule équation, afin de rester fidèle à la philosophie de "physique facile".
Que sont les "LGA" ? C'est l'anglais du terme "Gaz sur Réseau" (je n'ai jamais su s'il fallait mettre un 'x' à 'réseau' car j'ai rencontré les deux. Mais que fait l'Académie Française ?). Plusieurs termes équivalents seront utilisés sans distinction pour désigner la même chose.
La présente introduction ne vise pas l'exhaustivité ni l'exactitude scientifique, son but étant de faire comprendre à des informaticiens les principes, les bases, les utilisations et les limites de ce modèle. Pour un historique plus précis, Il est préférable de se référer à l'article de Bruce Boghossian [] par exemple. Nous verrons ici les gaz sur réseau, ou LGA (Lattice Gas Automata, ou Automates Cellulaires de Gaz sur Réseau) comme une manière "fainéante" de calculer les écoulements de fluides, puisqu'ils permettent de se passer (a priori) de calculs complexes en virgule flottante et de formules interminables. Les LGA ont l'avantage de nécessiter peu d'efforts pour comprendre leur principe et ont une représentation immédiate des résultats, ils sont donc très séduisants.
J'ai déjà mis au point plusieurs types d'algorithmes de plus en plus compliqués pour calculer les gaz sur réseau, mais au bout de trois ans je n'en suis pas encore arrivé au bout. J'espère que cette année de maîtrise me permettra de concrétiser un algorithme encore plus complexe et plus efficace que les précédents, afin de clore ce sujet et implémenter des modèles physiques plus prometteurs en nombre de Re.
En 1996, après avoir mis au point les algorithmes de LGA en 32 bits, je fus étonné de voir que le fameux Jeu de la Vie de John Horton Conway pouvait être accéléré 300 fois par rapport à un programme "trivial" grâce à un remaniement des structures de données et de l'algorithme et surtout grâce à une conception méticuleuse. Le livre de Michael Abrash "Le ZEN de l'optimisation du code" m'a donné de nouvelles pistes pour reconsidérer le modèle physique dans son intégralité et trouver des méthodes plus efficaces pour effectuer finalement les mêmes opérations.
Michael Abrash m'a appris dans ce livre qu'un programme et son écriture ne peuvent être faits que si l'on comprend bien la nature des données, ce que doit faire "in fine" le programme, comment, pourquoi, et quelles sont les causes de ralentissements dans les algorithmes antérieurs. En considérant plus de paramètres, on rend l'algorithme de plus en plus complexe et on passera plus de temps à sa mise en oeuvre, alors qu'on diminuera le temps d'exécution et de calcul. J'ai finalement passé énormément plus de temps à réfléchir sur les programmes qu'à les faire exécuter sur un ordinateur, ce qui représente environ quelques dizaines d'heures en 3 ans.
Cependant les enjeux sont importants car malgré l'augmentation constante de la puissance des ordinateurs, les problèmes physiques à résoudre sont immenses et une réflexion approfondie sur le sujet permet de gagner un temps précieux. Par exemple une augmentation de la performance d'un programme de 20% permet de réduire d'une journée environ le temps de calcul d'une simulation qui durerait une semaine, sans augmenter les coûts. Je pars donc du principe que TOUTE optimisation, quelle que soit l'importance du gain de performance, doit être utilisée. Les expériences à réaliser s'étandant sur toute la mémoire de l'ordinateur et la vitesse effective des événements augmentant avec la taille du tunnel, chaque gain est précieux et il serait inutile de s'en passer ! Il faut donc optimiser à tous prix, à tous les niveaux et autant que possible.
Les objectifs supplémentaires du programme, en plus de la meilleure
vitesse possible, sont d'améliorer la flexibilité, l'intéractivité et
l'utilisabilité des résultats.
- La flexibilité est améliorée en permettant de fixer arbitrairement
la rugosité des parois des objets, l'endroit de l'introduction des particules
ou même la place des objets.
- L'intéractivité est améliorée en permettant de modifier la plutpart des
paramètres en cours du calcul, au clavier ou à la souris.
- L'utilisabilité des résultats est améliorée en intégrant les calculs
de densités à l'intérieur de la boucle principale, et ils sont
optimisés au même titre que le reste, puisqu'il représente une partie
non négligeable de la charge de calcul. Des procédures annexes et
des entrées-sorties par fichiers sont aussi prévues
Du fait de sa capacité de simulation réduite ce programme
a essentiellement trois débouchés : recherche, éducation et jeux.
- Les gaz sur réseaux comblent l'espace entre l'hydrodynamique
classique calculée avec des équations comme celles de Navier-Stockes,
et la dynamique moléculaire régie par des équations de mécanique classiques.
Ils sont utilisés avec succès dans l'étude de la diffusion des liquides
dans les milieux poreux, ou pour mieux comprendre l'intéraction entre
les phases de différents liquides. Cela peut aussi intéresser des
industries de la peinture, des ciments ou de la climatisation
par exemple.
- La simulation de fluides peut être facilement utilisée pour enseigner
les propriétés des gaz et des liquides intéractivement. Des expériences
permettent de mettre facilement en évidence les vases communiquants
ou la poussée d'Archimède, pour l'hydrostatique en primaire par exemple.
- Les jeux vidéo cherchent toujours à donner l'impression d'un plus grand
réalisme. Les gaz sur réseau peuvent simuler, même si ce n'est pas très
scientifique, des nuages, de la fumée, des rivières, des écoulements
d'eau, et les personnages peuvent facilement intéragir avec ces éléments "naturels",
rendant ce monde plus complexe et réaliste. Même si ce n'est pas encore
entré dans les moeurs des programmeurs de jeux, ils utilisent depuis longtemps
des techniques similaires. Dans ce cas, les techniques d'optimisation développées ici
peuvent leur être très utiles (quand elles ne sont pas déjà mises en oeuvre).
Bien que le domaine d'application soit assez restreint, il permet d'envisager son utilisation dans des algorithmes génétiques dans des buts d'optimisation de formes (ou de vies artificielles), ou pour simuler des instruments de musique virtuels. A ces fins, l'algorithme a été conçu pour permettre de développer des gaz sur réseau complexes avec différentes composantes, des particules traceuses, des automates cellulaires hétérogènes et des intéractions non locales. Des parois mobiles et de nature arbitraire sont possibles facilement.
Dans les chapitres suivants, nous allons passer de la théorie à la pratique, et de la pratique à l'optimisation.
Dans le chapitre 2, nous allons (re)voir des bases de mécanique des fluides nécessaires pour comprendre la suite du mémoire.
Dans le chapitre 3, nous allons expliquer l'histoire, la théorie, les applications, les limites et les classes de gaz sur réseau.
Dans le chapitre 4, nous allons examiner l'implémentations "de base" du modèle FHP que j'ai publié dans le magazine Pascalissime, et discuter de ses défauts.
dans le chapitre 5, nous examinons d'autres programmes écrits par d'autres personnes afin de les comparer, et nous verrons des machines spécialisées construites spécialement pour traiter les automates cellulaires et les gaz sur réseau.
Dans le chapitre 6, nous présenterons l'architecture du processeur retenu pour faire tourner le code: le processeur Intel (R) Pentium (R), ses unités clés et son environnement, qui jouent un rôle dans les performances: pipeline, unités de calcul superscalaires, prédiction de branchements, queue de préextraction, accès à la mémoire, mémoire cache et algorithmes LRU, compteurs d'événements, mémoire externe, mémoire cache L2, mémoire vidéo, interruptions, mode protégé, assembleur... Et puisque les conditions le permettent, une introduction au Pentium 2 (R) est ajoutée.
Dans le chapitre 7, nous présentons les alternatives aux algorithmes et aux structures de données précédemment examinées : strip-mining, surveillance des performances, utilisation du VHDL...
Dans le chapitre 8, nous coderons pas à pas les différents modules logiciels du programme final.
Cette partie théorique permet de comprendre quelques fondements de la mécanique des fluides pour les informaticiens, donc sans équation inutile, toujours dans l'esprit "seul le principe compte".
La mécanique des fluides est une branche de la physique qui s'attache à décrire, modéliser et prédire le comportement d'un ou plusieurs fluides (liquides ou gazeux) selon les paramètres qui le(s) caractérisent :
- longueur
Par longueur d'un phénomène, on désigne soit la taille de l'"éprouvette" (l'objet autour duquel le fluide est simulé) ou la taille du tunnel d'expérimentation. Elle est mesurée en mètres (S.I., pour les objets réels) ou en sites, ou cellules, ou noeuds pour les modèles "discrets".
Plus généralement, on étudie en fait plusieurs échelles d'échelles, car les simulations d'écoulement de fluides - vitesse
C'est, selon le contexte, la vitesse d'une particule individuelle ou la vitesse de déplacement d'une masse de fluide. Ces deux notions sont très différentes et ne doivent pas être confondues car elles sont souvent très différentes.
- densité (rho ?)
nombre de particules de fluide par unité de volume (ou surface)
- vitesse du son
cette vitesse est inférieure à la vitesse d'une particule du fluide.
- pression
- viscosité
affecte la vitesse du son, en plus de la densité.
moins un fluide est visqueux, plus il fait de tourbillons.
Au contraire, plus le fluide est visqueux, plus il a l'air monobloc.
Ainsi, l'huile de moteur est plus visqueuse que l'eau, qui est plus visqueuse
que l'air.
La meilleure définition que je connaisse pour appréhender le principe de la viscosité est : c'est la résistance à la diffusion de l'énergie. La viscosité du métal solide est quasi infinie car ses particules n'ont aucune tendance à comuniquer leur mouvement à leurs voisines en dehors de leur vecteur vitesse propre. Au contraire, un fluide agité transmet de l'énergie (cinétique) à ses particules voisines sur un vecteur vitesse perpendiculaire à son vecteur propre. Ainsi naissent les tourbillons...
- nombre de Mach
- nombre de Reynolds
Caracatérise le facteur d'échelle du phénomène physique observé.
Il quantifie "la taille des écoulements" : il permet de comparer deux phénomènes à condition que la géométrie et que le nombre de Reynolds soient identiques. La géométrie des turbulences sera alors identique. On peut donc comparer un écoulement d'huile de moteur avec un écoulement d'azote, à condition de remettre à l'échelle la taille de l'"éprouvette".
Dans la pratique, cela a l'avantage de rendre les expériences plus abordables si l'écoulement considéré n'est pas accessible ou mesurable : il suffit de mettr les paramètres caractéristiques à l'échelle en fonction du nombre de Reynolds.
Par exemple, dans les souffleries pour les avions à réaction, il faut refroidir l'air pour que la maquette de petite taille se comporte de la même manière que l'avion en grandeur réelle. La température influant sur la viscosité de l'air, le nombre de Reynolds en conservé lors de la diminution de la taille de l'éprouvette. C'est le principe des souffleries cryogéniques.
Afin de calculer le comportement des fluides, de nombreuses études ont été effectuées depuis Archimèdes, en hydrostatique (fluides au repos) ou en hydrodynamique ou aérodynamique (fluides en mouvements). Cette dernière branche fait apparaître des phénomènes très complexes allant des écoulements de Couette ou de Poiseuille aux "allées de Von Karman" ou les forces autour d'un avion en vrille.
Le nombre de Reynolds :
Pour quantifier "la taille des écoulements", les physiciens utilisent un nombre unique qui représente en fait un paramètre d'échelle : c'est le nombre de Reynolds, qui est le rapport entre le produit de la taille et de la vitesse, sur la viscosité du fluide :
Re=(v*l)/viscosité
Ce rapport d'échelle permet de comparer deux écoulements à condition que la géométrie et que le nombre de Reynolds soient identiques. La géométrie des turbulences sera alors identique. On peut donc comparer un écoulement d'huile de moteur avec un écoulement d'azote, à condition de remettre à l'échelle la taille de l'"éprouvette". Dans la pratique, cela a l'avantage de rendre les expériences plus abordables si l'écoulement considéré n'est pas accessible ou mesurable : il suffit de mettre les paramètres caractéristiques à l'échelle en fonction du nombre de Reynolds.
Par exemple, dans les souffleries pour les avions à réaction, il faut refroidir l'air pour que la maquette de petite taille se comporte de la même manière que l'avion en grandeur réelle. La température influant sur la viscosité de l'air, le nombre de Reynolds en conservé lors de la diminution de la taille de l'éprouvette. C'est le principe des souffleries cryogéniques.
Le nombre de Mach :
Le nombre de Mach est le rapport entre la vitesse des particules du fluide et la vitesse du son.
Mach = v/Cs
Par nature, les LGA ne peuvent pas raisonnablement atteindre des Mach de 0,2, car des distorsions liées à la nature discrète et géométrique du modèle empêchent le gaz d'obéir aux équations de Navier-Stockes, le gaz n'étant plus incompressible.
En effet, lors des premières expériences, la simulation ressemblait plus à une voiture plongeant dans une piscine de boules qu'à une aile d'avion fendant l'air. Il faut respecter une certaine densité moyenne de particules et certaines limites de vitesses pour que l'écoulement du fluide corresponde à la réalité. C'est là toute la difficulté d'utiliser les LGA. Dans la plupart des expériences, on choisit Mach=0,1 qui est à la limite du modèle tout en permettant des mesures statistiques décentes.
Par contre, les LGA se distinguent dans les simulations de géométries complexes, le meilleur exemple restant celui de la diffusion de liquides dans les milieux poreux : il a été ainsi calculé le comportement du gaz naturel dans le sable du désert américain, en vue de son stockage à moindre coût [URL Sandia, CAM8].
La vitesse du son, la pression, la densité et la viscosité
Leur mesure est importante pour déterminer les caractéristiques du fluide. Des formules existent mais dans la pratique on choisit une densité moyenne de 2 particules par noeud, soit 1/3.
Les équations "classiques" de la mécanique des fluides
Navier-Stockes, Euler et j'en passe... je suis pas spécialiste.
A) Les LGA et la Mécanique des fluides
LGA veut dire "Lattice Gas Automata". C'est le terme générique pour "Automate cellulaire de gaz sur réseau", ou "gaz sur réseau" tout simplement. C'est un modèle physique récent qui a été présenté en 1973 et en constante amélioration, qui permet de simuler des fluides à l'échelle macroscopique.
La classe des LGA est à part dans la grande famille des automates cellulaires : ils
ont été conçus à partir d'un modèle physique, au lieu d'être une règle découverte
lors d'une exploration exhaustive des possibilités offertes par un réseau particulier.
Ils sont donc des "cousins" partageant certaines propriétés géométriques et temporelles.
Leur apparition est dûe aux ordinateurs, sur lesquels les premiers automates cellulaires
ont été imaginés par Von Neuman pour simuler des cellules pouvant se reproduire.
Les équations classiques font appel à des calculs complexes réalisés à la main,
alors que les gaz sur réseau et les automates cellulaires nécessitent un très grand nombre
de calculs simples, difficilement faisable à la main. Les premiers modèles ont fait
une analogie sommaire entre les automates cellulaires et le comportement des
particules d'un gaz. Ils
En mécanique des fluides, les gaz sur réseau ont leur domaine d'application entre ceux
de la dynamique moléculaire (qui trace chaque particules, en tenant compte de leur masse,
de leur vitesse, de leur coordonnées...) et la mécanique classique (qui calcule les
volumes de fluides avec les équations de Navier-Stockes par exemple).
Les deux dernières méthodes nécessitent de très puissants ordinateurs qui utilisent
des nombres en virgule flottante pour représenter les grandeurs. Au contraire, l'idée
de base des gaz sur réseau est de représenter chaque particule par un seul bit sur un
réseau régulier, ce qui augmente considérablement l'efficacité des calculs par rapport
à la dynamique moléculaire, et évite les erreurs d'approximation qui surviennent dans
les calculs de Navier-Stockes (les erreurs qualitatives peuvent atteindre 20% dans des
simulations par rapport aux mesures physiques). Les gaz sur réseau au contraire
permettent des estimations très fines, et avec le modèle utilisé, aucune perte
n'est dûe à des approximations successives, ou pire, une mauvaise convergence
des équations mises en oeuvre dans les cas classiques et qui entrainent .
Validité du modèle :
Il a été démontré [d'Ortona] que le modèle de LGA que nous allons utiliser (FHP3) obéit aux équations de Navier-Stockes et des gaz incompressibles. Il est donc, dans la limite des contraintes énoncées ci-après, utilisable pour simuler des fluides réels.
Les LGA comparés aux autres modèles :
Principalement, les méthodes qui ne représentent pas les particules (Navier-Stockes, Euler, etc) sont adaptées aux grands systèmes, avions, voitures, bateaux, tout ce qui est à notre échelle et plus. La dynamique moléculaire par contre peine à simuler un million de particules, c'est à dire des milliards de millards de fois moins qu'une seule mole (6*10^23) de molécules : le domaine d'application est donc réduit à l'échelle microscopique.
Les LGA sont un modèle intermédiaire : un bit du réseau ne représente pas directement une particule, mais, statistiquement, un grand nombre. Pour simuler un certain écoulement, il faut beaucoup moins de bits de LGA que de particules en dynamique moléculaire. Mais, comme ce nombre dépend linéairement de la taille de l'écoulement, les méthodes de mécanique classique sont mieux adaptées pour les grandes simulations.
Le nombre de Reynolds :
Ici, le nombre de Reynolds permet de comparer l'efficacité de la simulation, le but étant souvent de l'augmenter pour simuler des grandes turbulences. Les LGA ne peuvent pas atteindre de grands Re, si on les compare avec les méthodes classiques. Voici quelques chiffres pour donner les proportions :
aile de Boeing 747 : Re = 50 000 000
aile de planeur en modèle réduit : Re > 100 000
FHP2 avec 1 million de points : 300
Il est donc évident que notre programme ne pourra pas simuler d'avions ni de gros objets. Par contre il peut simuler des liquides très visqueux comme la peinture, la graisse ou l'huile, ce qui laisse des débouchés industriels encore inexploités.
Le nombre de Mach :
Le nombre de Mach est le rapport entre la vitesse des particules du fluide et la vitesse du son.
Par nature, les LGA ne peuvent pas raisonnablement atteindre des Mach de 0,2, car des distorsions liées à la nature discrète et géométrique du modèle empêchent le gaz d'obéir aux équations de Navier-Stockes, le gaz n'étant plus incompressible.
En effet, lors des premières expériences, la simulation ressemblait plus à une voiture plongeant dans une piscine de boules qu'à une aile d'avion fendant l'air. Il faut respecter une certaine densité moyenne de particules et certaines limites de vitesses pour que l'écoulement du fluide corresponde à la réalité. C'est là toute la difficulté d'utiliser les LGA. Dans la plupart des expériences, on choisit Mach=0,1 qui est à la limite du modèle tout en permettant des mesures statistiques décentes.
Par contre, les LGA se distinguent dans les simulations de géométries complexes, le meilleur exemple restant celui de la diffusion de liquides dans les milieux poreux : il a été ainsi calculé le comportement du gaz naturel dans le sable du désert américain, en vue de son stockage à moindre coût [URL Sandia, CAM8].
La vitesse du son, la pression, la densité et la viscosité
Leur mesure est importante pour déterminer les caractéristiques du fluide. Des formules existent mais dans la pratique on choisit une densité moyenne de 2 particules par noeud, soit 1/3. Pour FHP3 (saturé) cela correspond à la densité permettant un nombre de Reynolds optimal.
Les LGA dans la pratique : description et évolution historique
HPP
Les LGA ont été imaginés au début des années 80. Le premier modèle fut proposé en 1984 par Hardy, de Pazzis et Pomeau, d'où le nom de HPP. Ils posèrent les bases des LGA, les futures évolutions ne seront que des améliorations théoriques.
L'optique était de simplifier au maximum la simulation de fluides sur les ordinateurs de l'époque : représenter une particule par un bit est le plus simple que l'on puisse alors faire. Un bit ne peut coder que la présence ou l'absence d'un bit, il faut donc ordonner spatialement cette masse de bits : il fut tout naturellement choisi un tableau, ou maillage, carré. Chaque case du tableau, ou intersection de la grille, contient donc un bit pour chacune des quatre directions. Le fluide "évolue" en échangeant des bit avec ses quatre voisins à chaque pas de calcul: c'est un modèle très proche des automates cellulaires.
En faisant ce parallèle, il est très facile de décrire le LGA de type HPP en utilisant les termes utilisés pour les automates cellulaires: -la géométrie est carrée, avec un voisinage de Von Neuman (4 voisins) -le temps est discret: l'état est défini à tout instant t entier -la grille est homogène, toutes les cases sont identiques -les lois sont réversibles dans le temps, donc causales -chaque cellule (case) a 16 états possibles (2^4bits) -chaque voisin ne communique qu'un seul bit à la fois La loi d'évolution de chaque particule fait par contre intervenir des notions de mécanique des solides. A l'échelle d'un "noeud" du maillage, il faut s'imaginer des balles, des boules de billard, ou des billes, qui rebondissent entre elles, et appliquer les lois qu'on apprend au lycée sur la conservation de l'énergie cinétique. Le nombre des particules aussi doit être conservé. Les lois de base en sont découlées.
Si on ne considère qu'une seule particule, elle se déplace d'un noeud à un autre sans perturbation. Elle effectue donc un trajet rectiligne, jusqu'à ce qu'elle disparaisse ou soit réfléchie par une paroi suivant le programme.
Si on considère deux particules, elles sont soit de direction perpendiculaire, soit de sens contraire. Dans le premier cas, si on se réfère à des boules de billard, chaque particule est déviée de 90 degrés, ce qui revient à ce qu'elles n'intéragissent pas (si on considère le phénomène dans son ensemble) . Par contre, si leur direction est identique mais leur sens est contraire, elles intéragissent plus fortement ; dans la réalité il est très peu probable que des boules soient #parfaitement# alignées (surtout dans un gaz) ce qui veut dire qu'elles ont très peu de chances de repartir d'où elles venaient. Ce désalignement fait qu'elles sont déviées de 90 degrés.
C'est ce léger désalignement dans la réalité, l'introduction d'un facteur d'imperfection, qui fait que le flot de bits ressemble à un fluide réel.
Pour représenter les intéractions des particules à chaque noeud, il est d'usage d'utiliser un modèle vectoriel où seul est représenté le vecteur mouvement.
Par exemple, dans le cas d'une particule qui arrive à un noeud à l'instant t et ressort sans modification de direction à l'instant t+1, on écrit:
| | | ----*---> | | | ^ | V | | | ----*---> | | |Bien sûr on déduit le cas vertical par rotation de 90 degrés, et le cas inverse par miroir (180 degrés).
Pour le cas de deux particules de directions perpendiculaires, on écrit:
^ | | | ----*---> | | | ^ | V ^ | | | ----*---> | | |car si on ne distingue pas une particule individuellement, les deux cas sont "dégénérés" à partir de la suituation
^ | | | A----*---> | | | Bon obtient
^ | | | A----*---> | | | Bou
^ | | | B----*---> | | | Ace qui revient au même.
Par contre, pour deux particules de même orientation,
A ^ | | | ----*--- | | | V Bon obtient dans la réalité
^ | | | A----*---> | | | BFHP
c'est le réseau introduit par Frish, Hasslacher et Pomeau dans leur fameux article [Phys. Rev. Let. 1986], qu'ils appellent HLG pour "Hexagonal Lattice Gas", mais ce sont leurs initiales qui sont restées.
En analysant les équations décrivant le modèle HPP, les auteurs montrent que l'utilisation d'un réseau hexagonal résout ses principaux problèmes. On utilise la collision frontale, comme pour HPP, sauf que celle-ci peut engendrer deux configurations différentes par rotation (de sens aléatoire) de 60 degrés:
[GIF]
Ils montrent aussi que l'ajout d'une loi de collision "triangulaire" est nécessaire pour pouvoir simuler l'hydrodynamique, car elle empêche chaque ligne (direction) de conserver son nombre de particules (ce qui a été mis en évidence par des simulations).
[GIF]
Ils évoquent FHP2
FHP3
FHP4
FCHC : Face Centered HyperCube
Il a été montré [FHP1986] qu'aucun réseau en 3 dimensions ne permet de simuler de fluides. xxx [] ont trouvé que la projection d'un hypercube de dimension 4 vers la troisième dimension satisfait les contraintes des gaz sur réseau. On utilise alors un hypercube à faces centrées qui possède douze liens : 12 en 3D et 12 en 4D. La lois de collisions comprend alors 16 millions de cas (2^24). LB
Exemples: EXA CAM8 RAP-1 implémentation sur CRAY
Mais en plus des limites théoriques, il existe des limites pratiques, souvent dûes à l'incompréhension ou à l'ignorance de facteurs propres aux simulations et à leurs conditions. Nous prendrons comme exemple une veine de soufflerie et les effets de bord liés aux conditions aux limites.
Le premier problème est celui des parois supérieures et inférieures de la veine.
La première solution est d'avoir une veine complétement ouverte : les particules arrivent par la gauche mais disparaissent aux bords de l'écran. Dans la réalité, cela revient à faire le vide dans la veine, ou bien d'envoyer des particules dans le vide sidéral et de placer l'éprouvette dans le flux. Comme il n'y a pas de "retour" de pression, c'est à dire que la force n'est exercée que sur une face de l'éprouvette, il n'y a pas de particule en sens inverse pour "équilibrer" la pression et on observe une "onde de choc" caractéristique des LGA. C'est un phénomène parasite qui n'est pas lié au modèle mais à sa mauvaise utilisation : en régime subsonique il n'est pas normal d'avoir une onde de choc. Il faut "équilibrer" les pressions dans toutes les directions pour fabriquer un fluide "normal".
La deuxième solution, un peu plus évoluée, consiste à programmer des conditions périodiques : une particule sortant par le bas est déplacée vers la paroi supérieure pour continuer sa descente. Le premier effet de cette stratégie est d'"équilibrer" le champ de pression verticale. Cela permet aussi de satisfaire partiellement à la condition de grille infinie, puisque les particules peuvent "boucler" indéfiniment. Malheureusement, un effet pervers de cette solution est qu'une perturbation locale proche de la paroi inférieure peut influencer une perturbation proche de la paroi supérieure, alors qu'elles devraient être complétement indépendentantes. C'est une approche simpliste qui ne correspond à aucune réalité physique.
Troisième solution : parois rugueuses en haut, en bas et à gauche. Comme le domaine n'est plus périodique, il n'y a plus d'influence parasite entre le haut et le bas de la veine. On peut donc plus facilement observer des phénomènes de portance d'ailes d'avions.
Cependant deux effets influencent substanciellement l'écoulement:
- Les particules disparaissent à droite, comme si la veine débouchait dans le vide sidéral, un monde meilleur plein de rien. La pression n'est donc pas complétement équilibrée dans toutes les directions.
- Les parois rugueuses, faciles à programmer, créent des "écoulements paraboliques de Poiseuille", phénomène bien connu dans les tuyaux par exemple, qui influencent sensiblement l'écoulement propre autour de l'éprouvette. L'image de couverture est un exemple de cette intéraction parasite avec la paroi : la dépression supérieure dûe à la portance de l'aile se confond presque avec la parabole de Poiseuille. On ne peut donc pas considérer que l'écoulement est "propore".
La solution adoptée pour ce cas est d'ajouter une "grille" (bloquer une cellule sur quatre) afin d'éviter que toutes les particules disparaissent et rétablir une légère pression venant de l'arière. Cela a pour effet de "casser" légèrement la parabole.
La deuxième solution qui s'y ajoute permet d'éviter l'"effet de sol" des parois : il ne faut pas qu'elles soient rugueuses, afin que la pression ne baisse pas près des parois. Les parois "réfléchissantes" sont l'objet de nombreux travaux durant ce projet, mais principalement d'ordre algorithmique et non physique.
Un troisième moyen de diminuer les inconvénients d'un fluide "monolithique" est d'introduire les particules dans des directions aléatoires, près de la paroi de gauche.
Ces conditions sont suffisantes pour effectuer des simulations d'écoulement autour d'ailes d'avions (si on exclut le nombre de Reynolds nécessaire) ou pour simuler les allées de Von Karman, en régime stationnaire.
Les conditions aux limites temporelles
Une fois le fluide en régime stationnaire, on effectue la mesure et on
passe à l'expérience suivante. En d'autres termes : la plupart du temps de
calcul est passée à éliminer les phénomènes transitoires. Une formule empirique,
D'abord, la plupart des implémentations classiques, la veine est vide de fluide en temps 0. Il faut donc
Le but est de remplir la veine, mais de la manière la plus proche possible de l'état stationnaire désiré. Une première solution simple serait d'utiliser directement les équations classiques d'Euler par exemple pour initialiser les particules. Le problème n'est pas la charge de calcul que cela représente mais la complexité qui augmente avec celle des géométries des parois. Cette solution hybride n'est donc pas adaptée.
La solution que ce projet propose est de commencer le calcul avec une définition très faible, le temps que les transitoires disparaissent, puis d'agrandir la grille et de recommencer, jusqu'à obtenir la résolution désirée. En initialisant le fluide avec un vecteur moyen de vitesse adéquat, les phénomènes transitoires sont réduits avec encore moins de calculs. Mais la réduction de la taille de la grille s'apparente à une réduction du nombre de Reynolds. On pourrait donc utiliser un modèle plus simple que FHP3, comme FHP1 ou FHP2 moins gourmand en calculs et donc beaucoup plus rapide à calculer, mais FHP3 a un meilleur rendement et même si le calcul est plus lourd, il faut effectuer moins de calculs.
L'utilisation d'une grille de taille croissante permet de gagner un ordre de grandeur dans le temps de calcul. Prenons par exemple le cas où le calcul utilise deux tailles intermédiaires (1/4 et 1/2),
Implémentation de départ : cf Pascalissime
A partir du modèle décrit dans la revue du Palais de la Découverte, j'ai essayé de faire le tour du modèle et de comprendre son principe, ce qui n'était pas évident puisque je n'avais aucune connaissance en mécanique des fluides. J'ai finalement réussi à fabriquer la lookup table à la main en examinant toutes les configurations de particules. Je me suis posé de nombreuses questions, comme par exemple: est-ce qu'on représente les liens ou les noeuds ? Comment faire pour éviter que deux particules ne se croisent sur un lien ? Comment faire pour utiliser des nombres entiers au lieu de bits ? J'étais alors en classe de Terminale et mon professeur de physique s'en souvient encore probablement...
Une fois la table écrite, l'implémentation
A l'époque je disposais d'un PC 286 à 12MHz que je programmais en Pascal agrémenté d'assembleur.
Il faut faire une distinction importante entre la philosophie
collision/translation et celle que j'utilise, car la première
implique deux phases distinctes, alors que par nature (algorithmique)
il n'en est effectuee qu'une seule. La collision n'est qu'un événement.
En effet le simple fait de charger la donnée d'un site dans le processeur
implique un DEPLACEMENT de la mémoire vers la CPU. Ensuite, libre
à elle de déposer cette donnée modifiée où elle le veut, en déplacant
32 ou 64 bits (particules) à la fois.
La plupart des programme examinés sont architecturés en deux passes :
ainsi que Pierre Lallemand le suggère fortement, le
personnes considèrent les deux phases comme distinctes
et bougent explicitement les tableaux après calcul, soit par mouvement de
blocs, soit par modification de pointeurs. Cela est pourtant effectué plus
efficacement à l'intérieur de la boucle principale
(c'est un principe de base d'optimisation), et l'organisation
en "structure" des sites permet de simplifier leur adressage.
La viscosité est diminuée en augmentant au maximum l'efficacité des collisions. Il faut donc que la table des collisions utilise toutes les occasions de modifier les vecteurs mouvements sans modifier l'impulsion. Le cas des particules qui se croisent sur un noeud est problématique et inévitable, et pourtant peu de solutions valables existent. Je souhaite tester une intéraction non locale pour remédier à cela. Je n'arrive toutefois pas à comprendre comment est réglé "dans la pratique" le problème de l'invariance galiléenne avec plusieurs particules à l'arrêt.
La méthodologie de développement fait appel au chronomètre interne du CPU pour juger les solutions proposées. Et l'algorithme final sera construit à partir de l'algorithme de strip-mining de base. Les compteurs d'événements seront aussi utilisés si j'arrive à m'en servir...
constatation: ça tournait plus vite dans une fenêtre Windows qu'en mode DOS !
explication: Windows tourne en mode V86 et émule l'écran avec de la mémoire conventionnelle, puis raffraîchit l'écran plusieurs fois par seconde. La mémoire vidéoo n'est pas cachable ! -> buffer en mémoire centrale !
2) comme on est sur un processeur 32 bits, on peut manipuler 4 sites à la fois. -> amélioration du parallélisme.
Mais dans le fond, ce n'était que des améliorations de bas niveau.
Aperçu des autres solutions -CAM8 -EXA -Codes Fortran et C
From: eugene@sally.nas.nasa.gov (Eugene N. Miya) Newsgroups: comp.parallel, comp.sys.super Subject: [l/m 1/7/99] What *IS* a super? comp.par/comp.sys.super (18/28) FAQ Date: 18 Jan 1999 13:03:06 GMT Organization: NASA Ames Research Center, Moffett Field, CA Archive-Name: superpar-faq Last-modified: 7 Jan 1999 What's constitutes a supercomputer? ----------------------------------- 2) "A supercomputer is a device for converting a CPU-bound problem into an I/O bound problem." [Ken Batcher] We can observe (here) that it is the application that decides if you're using a Supercomputer, and finally to put extra stress on the idea that "the concept of "fastest" is one you should control." consider what you would hold important if all the arithmetic in your problem took zero time. How fast would your problem run, and now what would you do to make it go faster.
"
Un superordinateur est un appareil pour convertir un problème limité
par le temps de calcul en un problème limité par la vitesse des
entrées/sorties.
"
Les termes "CPU-bound" et "Memory-bound" seront utilisés dans la suite de ce mémoire pour indiquer que le calcul ou l'accès à la mémoire est le facteur limitant la vitesse du programme ou de l'algorithme considéré.
En mettant l'accent sur la vitesse de calcul, les premiers "superordinateurs" ont fait apparaître l'importance de la mémoire centrale (tant en taille qu'en vitesse d'accès et de bande passante soutenue) ainsi que de l'unité scalaire (pour calculer les adresses, la taille des vecteurs, les compteurs de boucles...) car les unités de calcul étaient parfois partagées (d'où la supériorité dans la pratique du CRAY 1 sur le CDC Star, malgré une puissance en crête théorique supérieure du second [P&H, "a quantitative approach"]).
Les DSP actuels ont retenu la leçon car ils disposent de ressources équilibrées, tant en registres qu'en accès à la mémoire. Deux mots peuvent être chargés de la mémoire en un seul cycle de manière soutenue, grâce à des fonctions dédiées à la génération automatique des adresses, à des compteurs de boucles rapides (indépendant et sans temps de latence), et des canaux de DMA qui "ventilent" les blocs de données hors de la puce en même temps que le calcul s'effectue.
Les ordinateurs "classiques" ou les processeurs RISC ne disposent pas de ces mécanismes utiles pour la plupart des cas. C'est la cause de la plupart des soucis de programmation pratique dans ce mémoire.
"
Nous pouvons observer ici que c'est l'application qui décide si on
utilise un Superordinateur, et pour insister finalement sur l'idée que
"le concept du "plus rapide" est celui qui doit être contrôlé",
considérons ce qui peut devenir important si toute l'arithmétique du
problème à résoudre était éliminée. A quelle vitesse serait résolu le
problème, et maintenant, que faire pour le résoudre encore plus vite.
"
Pour résumer, la technique d'optimisation est de "supprimer" (puisqu'il ne prend plus de temps) le calcul et de voir ce qui reste, ce qui est souvent le travail de "ventilation" des données entre le processeur et les mémoires.
(Note : le temps de calcul est le cas le plus évident. Celà pourrait aussi bien être autre chose, comme la vitesse d'accès à un disque...)
Dans le cas des programmes de FHP utilisant l'algorithme "orienté octet", il est clair (si on y prête attention) que le problème est effectivement le "brassage des données". L'algorithme de deuxième génération utilisant des mots de 32 bits est un essai pour diminuer l'impact de ces mouvements de bits individuels, mais le problème n'est pas résolu. Si on regarde les programmes sources, on voit que le nombre d'instructions qui effectuent la "collision" (la consultation de la table) est réduit (celà peut être réduit à une instruction par site) alors qu'il faut environ une cinquantaine d'instructions pour effectuer tous les mouvements des bits. Si on éliminait la consultation de la table, on ne gagnerait que 512 octets de mémoire cache, et 1% de vitesse (à vue de nez).
exemple ici.
Organisation alternative spécialisée :
L'algorithme orienté octet a donc un vrai problème de déplacement des données, dans le cadre d'un ordinateur "classique" (Von Neumann). Il faudrait une architecture spécialisée (comme celle du RAP-1, d'une Connexion Machine ou d'une CAM-8), parallèle à granularité très fine et avec de nombreux canaux de communication pour bénéficier de la facilité et de la vitesse de ce modèle.
Un exemple idéal serait une immense grille de PAL (16L8 ?) où chaque circuit s'occuperait d'une cellule.
PAL --- PAL --- PAL --- PAL --- PAL --- PAL --- / \ / \ / \ / \ / \ / \ PAL --- PAL --- PAL --- PAL --- PAL --- PAL --- PAL \ / \ / \ / \ / \ / \ / PAL --- PAL --- PAL --- PAL --- PAL --- PAL --- / \ / \ / \ / \ / \ / \ PAL --- PAL --- PAL --- PAL --- PAL --- PAL --- PAL \ / \ / \ / \ / \ / \ / PAL --- PAL --- PAL --- PAL --- PAL --- PAL --- / \ / \ / \ / \ / \ / \ PAL --- PAL --- PAL --- PAL --- PAL --- PAL --- PAL \ / \ / \ / \ / \ / \ / PAL --- PAL --- PAL --- PAL --- PAL --- PAL ---
Chaque lien correspond à deux connexions. Ce système pourrait fonctionner à 20MHz environ mais il faudrait un nombre considérable de circuits, sur une surface gigantesque, la visualisation serait difficile, et surtout : les essais avec les compilateurs VHDL ont montré que la complexité des équations ne permet pas de programmer une PAL normale avec les règles FHP-3 "saturées". En plus, l'arbre de l'horloge serait lourd à gérer (il faut faire un arbre binaire pour répartir le signal d'horloge de manière synchrone sur tout le circuit, comme expliqué dans la documentation de la CAM-8)
Une alternative serait d'utiliser des mémoires SRAM comme celles utilisées dans les caches L2 des PC. Je dispose d'une centaine de SRAM en boîtier DIL étroit 28 broches à 15 ns, ce qui a nourri ma réflexion longtemps. Comme la programmation peut être changée à tout moment, le système simulé peut être intéractif. Et comme une SRAM de 32 Koctets contient plus de données que nécessaire pour une seule table (512 octets), un boîtier peut contenir les informations de 64 lignes différentes pour lesquelles les informations ne seraient pas homogènes (comme pour des parois plus ou moins glissantes, de informations sur la géométrie...)
dessin
Le problème est de programmer les SRAM : il faudrait intercaler des transmetteurs qui sélectionnent la provenance des données dans le chemin critique, ce qui diminuerait la vitesse, augmenterait le coût et la consommation électrique. De toutes façons, la sortie de ces puces mémoires n'est pas "latchée" (la sortie ne peut être maintenue alors que l'entrée change). Un système synchrone n'est donc pas possible. La question reste en suspens, mais il est évidemment plus facile de programmer un ordinateur "classique" que de mettre au point un système de ce style, même avec des FPGA extrêmement modernes.
La méthode vectorielle :
Une solution pour les ordinateurs vectoriels utilisés par les grands centres de recherche (qui disposent de CRAY gargantuesques) est de séparer les directions. Le traitement vectoriel est donc trivial, puisqu'il faut calculer de manière booléenne les interactions entre 7 flux de bits. C'est ce qu'Harlan Stockman appele le modèle "multi-spin" (terme utilisé d'abord pour calculer les automates cellulaires de Ising) :
Date: Mon, 18 Aug 1997 12:06:07 -0600 From: "H.W. Stockman"To: whygee_corp@hol.fr Subject: Re: data to check... Yann Guidon wrote: > > If you are doing just one-component flow, presumably your > > LGA are using a "multi-spin" technique, with all the vectors > > of a certain direction stored in adjacent bit positions? > Right, but not in different "planes" or layers. To make sure we are on the same wavelength here, the references contrasting "multi-site" vs. "multi-spin" are: Kohring, G.A. (1991) Parallelization of short- and long-range cellular automata on scalar, vector, SIMD and MIMD machines, Inter. Jour. Modern Phys. 2, 755-772. Brosa, U. and Stauffer, D. (1989) Vectorized multisite coding for hydrodynamic cellular automata, Jour. Stat. Phys. 57, 399-403. > And this should work also for multi-component. The true "multi-spin" method does not work for multi-component, unless there has been a vast advance in recent years; nor does it work for 3D. Perhaps you are already past this point, but let's make sure we are talking about the same thing: in the multi-spin method, the translate function is very simple, since all the bits for (e.g.) the "up and to right" vector are all packed into a word, say 32-bits-long, and all these words are in one array. However, the collision function is more complicated, because one has to come up with a set of logical operations (ANDs, ORs, XORs) that combine all the bits in a 32-bit word simultaneously and yet assure the collision will always be correct for every site. For the simple FHP with just 2-particle and symmetric 3-particle, this was a pretty easy task, and Los Alamos won an award back in 1988 for coming up with a 14-line algorithm. When one adds more collisions, the sequences of logical operations get more complicated, so a "saturated" collision set (all possible momentum- conserving collisions) takes something like 40 lines for 2D FHP (and saturated is desirable, since it has a much lower viscosity). Are we on the same wavelength here?
La méthode multi-spin est intéressante pour les ordinateurs vectoriels
car elle bénéficie de la bande passante vers la mémoire centrale
et du pipeline profond et rapide de l'unité de calcul.
La méthode multi-spin n'est pas adaptée aux ordinateurs
classiques. De plus, ils ont moins de registres et ne peuvent pas contenir 7
couples de pointeurs (7 directions avec chacune une valeur original et une
valeur résultat)
Remise en cause de l'algorithme: partie théorique et portable
- algo orienté octets ou orienté mots
-> compromis : structure de données qui permet des modifications et des
parois plus facilement modifiables.
EN PLUS, sur le Pentium et PIRE: sur le P6, il y a des pénalités à écrire
puis lire des registres partiellement (ce qui arrive avec la consultation
d'un tableau !) jusqu'à 7 cycles, plus tous les masques+ORs à faire et les
déplacements -> fabrication de l'équation booléenne
- introduction théorique du strip mining, avantage de portabilité et
d'adaptabilité, problèmes d'orientation
- affichage DANS la boucle de calcul, à la fin d'une ligne de strip mining
- les chaines de modifications de bits
La structure des donnée a été refondue avec l'algorithme.
-L'algorithme central est caractérisé par un "strip mining adaptatif"
afin de bénéficier de la puissance maximale du processeur, quelle que soit
la taille des mémoires caches et l'architecture de l'ordinateur, en fonction
de la géométrie particulière de chaque simulation. Le code est chronométré
en faisant varier le nombre de lignes traitées simultanément entre 1 et 32,
pour se caler sur la taille de la mémoire cache la plus rapide.
-Les particules sont stockées sous une forme intermédiaire entre la forme
"couches multiples" et celle "orientée octets" utilisée par les précedents
algorithmes, afin de conserver la localité des données et la simplicité
d'adressage "avec un offset relatif connu à l'avance" puisque les structures
ont une taille fixe.
-Les calculs sont effectués avec des instructions logiques, ce qui évite
d'utiliser une lookup table qui prend de la place en mémoire cache.
Le programme bénéficie aussi de la largeur croissante des mots des
processeurs actuels, 64 bits sont disponibles actuellement. Le MMX est
donc bienvenu quand on ne peut pas utiliser d'ALPHA.
-Le balayage principal à l'intérieur de la boucle de strip-mining est
effectué #vertivalement# et non horizontalement pour diminuer la taille
des buffers temporaires qui peuvent être alors contenus dans quelques
variables globales. On économise des instructions et de la place dans la
cache de données pour leur gestion.
-L'affichage et les calculs de densité font partie de la boucle principale
pour diminuer les "cache miss" et ne pas saturer inutilement le bus externe
du processeur.
-La gestion des calculs, de l'affichage, des objets, des capteurs et
l'introduction de particules sont gérées par une liste dont l'adresse se
trouve en début de chaque ligne. Les coordonnées des points de
la liste sont relatives à la ligne, ce qui permet d'utiliser la même liste
pour des lignes différentes et économiser de la mémoire.
-La liste des calculs élimine les endroits qui n'ont pas besoin d'être
calculés, comme par exemple à l'intérieur des objets. Cela accélère les
calculs si le(s) fluide(s) n'occupe(nt) qu'une partie de l'écran.
-La liste des affichages permet d'introduire des objets visuels comme le
curseur de la souris, les menus ou les capteurs virtuels.
-La liste des objets contient les "coordonnées" de chaque point qui doit
dévier une particule de sa trajectoire, par exemple pour les parois de
la chambre ou pour la collision avec les objets, ce qui permet d'ajuster
plus finement la rugosité qu'avec un simple bit qui renvoie les particules
d'où elles viennent.
Les inconvénients : L'algorithme fait appel au strip-mining, qui est très
sensible à l'utilisation de la mémoire cache. Il suffit d'un changement de
contexte ou d'une interruption pour que les performance s'effondrent
dramatiquement. Il faut donc que l'algorithme soit le seul programme que
l'ordinateur exécute, ce qui exclut tout système d'exploitation multitâche ou
préhensif. Plus radicalement, le programme doit avoir le contrôle total de
l'ordinateur afin que celui-ci n'exécute QUE les instructions du programme.
Cela limite forcément le nombre de plateformes susceptibles d'implémenter cet
algorithme et oblige à écrire de nombreuses fonctions de contrôle de bas
niveau du matériel, principalement le clavier, l'écran et la souris. Mais
la gestion des fichiers et d'autres organes doivent aussi être pris en
compte. Pour l'instant, seul un PC permet de faire tourner cet algorithme,
pour lequel j'ai déjà écrit un loader 32 bits en mode protégé.
Pour économiser du temps à l'exécution, il est fait beaucoup appel aux
programmes automodifiants et à la recompilation des données, ce qui
nécessite des efforts non seulement sur l'algorithme principal mais aussi
sur toutes les procédures qui lui fournissent les données à calculer.
Par exemple, puisque les objets ne sont plus limités à des bitmaps, on
peut utiliser des objets vectoriels, mais il est très compliqué de les
transformer en listes chainées compréhensibles par le moteur.
La lookup table a été transformée en une suite d'opérations logiques, mais
cette transformation est très complexe et est probablement la plus grande
difficulté, puisqu'elle touche au code et non aux données. Il faut
transformer la table en équation, puis simplifier l'équation au maximum, puis
optimiser (compiler) cette complexe équation en tenant compte du nombre
toujours trop limité des registres, des dépendances des données, des
restrictions de l'architecture du processeur, et ainsi de suite.
Le programme tournera en mode protégé et on ne pourra pas beaucoup
faire appel au BIOS ou à MSDOS.
Que fait le programme ?
Fondamentalement, le programme bouge des bits.
Cette constatation a permis de reconcevoir le programme depuis le début.
En effet, le meilleur moyen de "bouger des bits" sur un réseau hexagonal
est de stocker les bits sur des plans séparés mais entrelacés. Les opérations
de mouvement sont alors assez simple mais leur intéraction est difficile à
mettre en oeuvre pour les raisons évoquées plus haut.
Le programme affiche aussi les résultats en temps réel
ce qui nécessite une certaine occupation du bus de mémoire vidéo.
Les programmes précédents affichaient le résultat hors de la boucle
de calcul, ce qui générait de "chache miss" et occupait le bus général inutilement.
Maintenant, le résultat d'un groupe de cellules est affiché avant que ce
groupe soit "chassé" du pool de strip-mining, et l'ordre des transferts doit
être bien synchronisé avec le fonctionnement en "burst pipeliné" du bus
(ordre des mots, alignement,...).
Le programme attend des ordres de l'utilisateur.
Problème de l'optimisation:
Les hostilités commencent:
le PC : la plateforme idéale malgré elle
- présentation
- comparaison avec les autres plateformes,
portabilité du programme, facilité d'accès, performance,
monoprocesseur, le poids de l'OS, accessibilité des ressources,
utilisation effective, multitâche, contraintes
- MAC
- SUN
- ALPHA
- SGI
Le Pentium : processeur de cinquième génération, crossover CISC/RISC
- présentation générale (sans paging ni fioritures)
- l'architecture pipeline
- les règles de codage efficace
- la cache
- la BTB (principe de prédiction et exécution spéculative)
- les compteurs de performance
- MMX et ses apports (btb, pipeline, cache)
- le simulateur d'architecture
L'architecture mémoire et les périphériques, les niveaux de cache et leur
communication
- L1
- L2 (transactionnelle, etc)
- mémoire centrale et chipset
- mémoire vidéo et buffers
Le Pentium 2
La programmation parallèle d'un PC biprocesseur
- l'architecture générale: partage des bus, cohérence des caches, APIC
- l'APIC
- le protocole de réveil
NASM
- de l'intérêt d'utiliser le langage machine (exemples)
- pourquoi NASM ? comparaison avec les autres assembleurs,
avantages de simplicité, non-second-guessing, portabilité et GNU
- syntaxe explicite et simple
- alignement non automatique
- SMC et les méthodes de simplification du code:
gain de temps et de place, à plusieurs degrés
- simplicité d'utilisabilité des labels (non typés)
-> programme d'exemple
MS-DOS
- EXE vs COM : paramètes au démarrage -> header sous NASM
- E/S, fichiers, BIOS, allocation mémoire (résolu avec le header)
- EMM386
- HIMEM.SYS: présentation, limitation à 64MO !
-> programme d'exemple
Mode protégé (non exhaustif: manque le trap gates, ring 3, IO map)
- pourquoi faire compliqué ? nécesité d'accéder à toute la puissance du processeur,
gros tableaux, mode 32 bits (sans préfixes d'instruction) -> empêche de tourner
sous Windows et LINUX
- comparer avec les autres programmes (Audibert).
- description,
- l'architecture mémoire
- les niveaux de privilèges
- description des descripteurs
- protocole de passage et sortie du mode protégé
-> DOS extender
Mémoire étendue : XMS
- présentation, MS-DOS
- A20 gate
- le standard, les fonctions disponibles
- la programmation pratique
-> programme d'utilisation de la mémoire
le clavier
- hardware
- software
-> programme d'exemple
l'affichage en haute résolution
(y'en a un peu marre du mode 13h en basse résolution)
- les principes du VGA
- le standard VESA VBE en tant que surcouche
- organisation de la mémoire et utilisation
- nécessité du mode protégé: adresses hautes et gros buffer (2MO)
-> affichage de fontes en mode haute résolution
la souris
- hardware
- software
- le curseur
-> programme d'exemple, affichage de curseur
- raffraichissement du curseur
Le chronomètre et les compteurs d'événements
-> implémentation simple, affichage des résultats
L'Extension MultiMédia: MMX
Optimisation: respect de très nombreuses règles de codage et
considération des ressources disponibles sur le Pentium MMX:
P2: transformation en µops: 3 unités de transformation, dans l'ordre: 4-1-1
Pas de pairage si les instructions font plus de 7 octets !
Premières expérimentations de balayage de la mémoire:
- importance du strip mining, de l'alignement et de l'ordre
des accès aux mots et de leur largeur
- monitoring en temps réel ("tuning", adaptitivité)
Bouger les bits, implémentation de la structure de données de base
La liste des modification des bits
L'affichage des densités
La LUT devenue équation
-VHDL
-Kmaps
Les "vecteurs" de suivi d'écoulement
Les programmes auxiliaires :
- la fabrication des listes de modification des bits
à partir de données vectorielles
- l'"enregistrement" des données
- l'analyse des enregistrements
Application réelle
- Von Karman
Le cas particulier du modèle FHP est isolé dans le monde de la mécanique des
fluides. Son manque d'invariance galliléenne ainsi que d'autres caractéristiques
"insolites" font de lui un jouet pour informaticien. Mais ses propriétés
de base ont attisé et inspirent encore les électroniciens, informaticiens
et autres amateurs d'automates cellulaires ou d'architectures parallèles à granularité
fine.
Ce mémoire est une des nombreuses illustrations du principe
selon lequel la performance a un prix. Le prix financier de ce projet
est assez faible, surtout pour le lecteur de ce mémoire, comparé
à un projet industriel où des investissements sont nécessaires.
Cependant, le prix direct et brut est considérable : des centaines de nuits blanches,
des années de recherches et de programmation, des centaines de versions
des programmes, des centaines de bugs et de plantages d'ordinateurs, une demi-douzaine
de "cobayes" plus ou moins consentents, un article dans un magazine trimestriel
obscur, des kilos de papier griffoné ou imprimé, des milliers d'heures de musique
écoutées et un moniteur daltonien. C'est le genre de superproduction dont on parle
à ses petits enfants l'hiver au coin du feu ("Vous savez, en ce temps-là,
les ordinateurs n'avaient que 64 mégaoctets de mémoire...").
Le plus important est de savoir si le prix à payer est à la hauteur des enseignements
et des résultats. Dans notre cas, la réponse est furieusement positive.
Malgré la baisse du prix des composants des ordinateurs, leur architecture est de plus
en plus complexe afin de rester compétitif dans la course à la performance
au moindre prix financier. Ceci contrebalance leur efficacité
brute et oblige à faire de trop nombreux compromis.
Même les superordinateurs ont des architectures de moins en moins hétérogènes car le
stockage et le calcul de masse vont à l'encontre de la vitesse, telle que le conçoit
un électronicien. La "solution" est de payer le prix fort, ce qui n'est pas à la
portée de n'importe qui, et de toutes façons on ne peut pas aller plus vite que
la lumière !
Je ne prétends pas que ce programme soit "le plus rapide", car j'ai
omis de nombreux détails et j'ai sciemment réduit le problème aux processeurs Intel
à ma disposition. J'aurais été très heureux de programmer ce projet sur une station ALPHA,
à la fois très rapide et d'architecure simple.
Les documentations sur l'architecture du PII sont encore rares et peu de travail "libre"
a été effectué à propos de l'optimisation de son code, ce qui m'a obligé à faire
ma propre "cuisine". Une relecture du code source par un spécialiste décélera de
nombreuses améliorations, mais je peux dire que j'ai fait de mon mieux pour que
le code fonctionne le plus vite possible pour les cas qu'il est destiné à traiter.
En tous cas, il est tout de même meilleur qu'un code "bateau" en langage
évolué, même compilé par sur supercompilateur.
Le programme peut encore être grandement amélioré, principalement au niveau
de l'interface utilisateur et en rajoutant d'autres fonctionalités, mais ce
ne sont que des ajouts au programme. Une amélioration supplémentaire nécessiterait
encore plus de travail et l'accès à des informations de propriété industrielle.
J'ai réussi à implémenter ce programme parce que j'ai gardé en tête son
architecture globale, et pourtant je n'ai jamais perdu de vue le côté
"physique amusante" du problème qu'il doit résoudre.
Le plus étonnant est que cet algorithme optimisé permet de concevoir un
nouveau type d'ordinateur spécialisé extensible, en anneau, qui serait plus
efficace et moins cher (que les ordinateurs cellulaires classiques), à base
de gros FPGA qui calculeraient chacun une ligne et "pipe-lineraient" les données.
Malheureusement le modèle FHP n'est pas très adapté à la majorité des cas réels
et il n'est pas intéressant de poursuivre plus loin les recherches sur FHP :
les gaz sur réseaux de type BGK ou "Lattice Boltzman" sont beaucoup plus
efficaces en terme de Re/site même s'ils utilisent des nombres flottants.
Je souhaite donc m'orienter vers l'étude des "fermes" de clusters de DSP
en virgule flottante (le SHARC(TM) par exemple) qui constituent une alternative
intéressante face aux serveurs de calcul vectoriels (très chers) et qui peuvent
résoudre d'autres problèmes que ceux de mécanique des fluides, comme
le traitement du son dans le domaine fréquenciel ou tout autre problème de type
"gigaflop" adapté au parallélisme massif à granularité moyenne.
Vous pouvez maintenant fermer ce mémoire et reprendre une (in)activité mentale normale.
Mes livres:
Bernard Ourghanlian "Les microprocesseurs Alpha" InterEditions, 1995,
ISBN 2 7296 0565 7
Henri Lilen - René-Véran Honorat "Microprocesseurs PowerPC" ed. Dunod,
1995, ISBN 2 10 002464 7
David A Patterson - John L Hennessy "Computer Organisation & Design:
the hardware/software interface", Morgan Kaufmann, 1994, ISBN 1 55860 282 8
Gilles Deghilage "Architectures et programmation parallèles", Addison-Wesley,
1992, ISBN 2087908 023 1
Hans-Peter Messmer "Pentium et compagnie", Addison-Wesley, 1994, ISBN 2 87908 074 6
Alfred Aho - Ravi Sethi - Jeffrey Ullman et al. "Compilateurs : principes, techniques
et outils", InterEditions, 1989, ISBN 2 7296 0295 X
Michael Abrash "Le Zen de l'optimisation du code", Sybex
-Intel: optimisation, programer's referance manual, etc...
-revue du Palais de la découverte
-CAM8 specs
-article Pascalissime
-thèses de Jussieu
-thèse de Pierre Audibert
-articles de Zaleski
-articles dans Pour la Science
Technique:
-x86.org
-sandpile.org
-sites de Tierje Matiessen
-intel.com
-PCguide.com
-Simtel.com -> Nasm
-comp.lang.asm.x86
-comp.theory.cell-automata
-RBIL
Personnes :
-Hasslacher
-Pomeau
-Umberto d'Ortona
-Zaleski
-Dominique d'Humiere
-Bruce Boghosian
-Dan Rothman
-Harlan W. Stockman
-Quian et.al. : Lattice BGK Models for Navier-Stokes Equation,
Europhys.Lett., 17 (6), pp. 479-484 (1992)
-Norman Margolus "Integer Lattice Gases",
Phys. Rev. E 55 (April, 1997) 4137-4147.
-Jeff Yepez (yepez@plh.af.mil) at the Air Force Research Lab,
he has been working on a general purpose LGA simulation
package that runs under Win95.
-"Harris L. Gilliam"
-Joerg Bernsdorf (Erlangen)
-CA list
-bilbiothèque de Jussieu
-ENS rue d'ULM
-EXA, CAM8 et CM5
-Francois Le Runigo ?
-pmode-l pour les astuces de programmation
-Pat Kling, Terje Mathisen, Paul Hsieh, Christian Ludloff, Agner Fog
et Michael Abrash pour l'optimisation
Schéma de principe du CRAY 1 (merci à Gordon Bell)
pointeurs :-------------------
| |
V ________ V
A------>| |----->A'
B------>| |----->B'
C------>| |----->C'
(original) D------>| Calcul |----->D' (résultat)
E------>| |----->E'
F------>| |----->F'
G------>|________|----->G'
D'après la LUT, 90% des particules ne sont pas déviées de leur trajectoire
à chaque cycle. Et ce sont les 10% restants qui nécessitent 90% des
opérations.
Mais cette attente, qui est une "non chose" ne doit pas consommer
d'instructions pour ne pas pénaliser le calcul. Les interruptions sont
donc directement gérées et les routines d'interruptions modifient le code
du programme interrompu pour qu'il se finisse proprement. Ces codes
automodifiants sont peu courants et peu apréciés mais sont finalement la
meilleure solution car ils ne nécessitenr pas de variable globale à tester,
et n'occupent pas d'entrée dans la table de prédiction de branchements du
processeur.
- distinguer le niveau efficatité de l'algorithme (éliminer les variables inutiles, etc)
de la synchronisation avec le processeur
- "partial register stall": les registres de 8 bits ou 16 bits sont
accédés comme des registres 32 bits à l'intérieur du processeur.
Cela handicape la technique de consultation de tables !
- les pipeslines U et V sont utilisés par les instructions entières et MMX
- 2 ALU
très important pour assurer les calculs.
- une seule unité de multiplication pipelinée MMX
On n'en a pas besoin
- vérifier si CR0.TS et CR0.EM sont OK
Cela influence les performances globales.
- écriture des registes MMX 2 cycles après leur modification
Cela diminimue le nombre de registres effectivement utilisables
et le trafic vers la mémoire.
- aligner les entrées de boucles sur 16 octets (ligne cache/2)
pour accélérer le décodage des instructions longues.
(complexité max de génération)
Pourtant, en cumulant les années de recherches, le programme a tourné peut-être
moins de dix heures en tout, probablement parce que le programme ne m'est pas
utile directement. C'est cette dernière perspective qui m'étonne finalement le plus.
C'est sans doute le programme le plus compliqué que j'ai jamais fabriqué, car il
a nécessité des années de mise au point, de documentation et de remises en
question. Il aborde en plus un grand nombre de sujets qui vont des modèles physiques
aux processeurs en passant par la programmation des périphériques et l'algorithmique,
ce qui m'a permis de "côtoyer" sur Internet des programmeurs de jeux vidéos et
de systèmes d'exploitation, aussi bien que des physiciens du MIT, de Los Alamos
de l'ENS ou de Jussieu, en apprenant au passage les bases de la mécanique des fluides
et de la programmation en mode protégé. J'ai abordé le côté pratique de la synthèse
logique et de la génération automatique de code. J'ai même retrouvé des personnes de
l'époque "Pascalissime" (Umberto d'Ortona et Francois Le Runigo), et j'ai
rencontré certains initiateurs du modèle FHP ! Ce projet fut donc très enrichissant
sur le plan culturel (au sens large et informatique du terme).
Le programme source est très touffu et déroutant, et je suis sûr qu'il me sera
très difficile de le relire dans plusieurs années. J'ai donc fait attention
d'en noter chaque aspect et chaque détail dans ce mémoire qui est aussi un
"plan" du programme et un exemple pratique d'optimisation. En le relisant,
je serai donc en mesure de "reconstruire" le programme, probablement en y rajoutant
d'autres optimisations. J'ai aussi programmé de nombreux modules (loader, souris,
écran...) qui pourront être utilisés dans d'autes programmes du même type.
Enfin j'ai présenté des techniques et des idées d'optimisation qui peuvent être
reprises pour d'autres programmes (comme des jeux ou des codes scientifiques)
et sur d'autres types d'ordinateurs.
Excellente introduction à ce processeur revolutionnaire, écrite en français par
le directeur de développement de Digital. Ce n'est pas une documentation technique
pure, car elle explique aussi le pourquoi du comment de chaque aspect et
de chaque décision de la conception du modèle de programmation. Bon livre
sur l'architecture RISC du futur.
Ecrit en francais, ce livre présente le modèle de programmation de la famille PowerPC
et s'attarde sur les membres commercialisés avant la sortie du livre. Plusieurs
techniques architecturales sont expliquées comme l'exécution dans le désordre, mais
la suite est plutôt une traduction des documents anglais. On comprend donc le PPC
sans vraiment en savoir plus...
C'est LE "Patterson & Hennessy", qui explique clairement les fondements de l'architecture
des presque tous les ordinateurs. Il raconte leurs aléas et leurs avancées et
permet de mieux comprendre l'importance de la relation entre le logiciel et le
matériel qui le fait tourner, en fonction de leur rapport performance/prix.
Il ne faut pas confondre ce livre avec leur précédent ouvrage "A quantitative
approach"
"Approche pratique en environnement scientifique sur multiprocesseurs Silicon Graphics",
ou comment tirer le meilleur de architectures MIMD, des compilateurs, des algorithmes...
Les aspects théoriques et pratiques sont abordés et les résultats sont comparés
aux autres plateformes existantes. Il introduit dans leur contexte les techniques
de parallélisation de code comme le strip mining.
Bien qu'entaché de quelques erreurs et bourré de détails dont on se serait passé,
l'intérêt de ce gros livre est de présenter sous toutes ses coutures le monstre
CISC de 3 millions de transistors, ainsi que ses relations avec ses voisins directs:
contrôleur de cache, de mémoire, de bus PCI... Cette synthèse met le doigt sur énormément
d'aspects, électroniques, architecturaux ou de programmation, qui sont nécessaires
pour développer efficacement, mais il vaut mieux se référer aux constructeurs et aux
sites x86.org et PCguide.com pour avoir une information plus fiable.
Le "dragon book", c'est la raison pour laquelle je n'utilise pas de compilateur. C'est aussi
la raison pour laquelle j'en utilise un. Seulement, je sais maintenant quand je peux m'y fier.
Accessoirement, permettrait de faire un compilateur optimiseur pour le PII en MMX...
Devrait être lu par toute personne considérant coder correctement, bien que l'aspect
"assembleur" puisse repousser les habitués du "tout C". Quand on va à la chasse à la
performance, "on ne fait pas d'omelette sans casser d'oeufs", et l'auteur nous apprend
à faire enfin fonctionner le merveilleux compilateur qui est entre nos deux oreilles.
En plus, ce livre est facile à lire.