|

|
Par JF Maquiné le 22 Janvier 2004 |    | |
Il existe de nombreuses formules d'Euler, celle que nous allons voir aujourd'hui concerne une relation mathématique entre les polyèdres. En même temps il existe un grand nombre de polyèdres (les archimédiens, les platoniciens, les réguliers, les convexes,....). Puis pour terminer nous verrons comment associer les polyèdres à la théorie des graphes.
Sommet, arête et face : Quand on parle de polyèdre ou de théorie des graphes on fait en permanence référence à trois éléments fondamentaux qui les décrivent :
- Le sommet : point de jonction d'une ou plusieurs arêtes
- L'arête : droite reliant deux sommets
- La face : surface plane dont les bords sont déterminés par au moins 3 arêtes tel que le nombre d'arêtes et de sommets qui la compose soit égal. Exemple un triangle : 3 sommets, 3 arêtes. Un carré : 4 sommets, 4 arêtes, ...
Les polyèdres : Avant de voir la formule d'Euler, il nous faut voir la classification des polyèdres du moins les principaux car sinon la liste serait trop longue :).Mais d'abord qu'est-ce qu'un polyèdre ? C'est une surface délimitée par des polygones qui se rencontrent soit en un point (sommet), soit par un segment (arête). Ce sont des figures géométriques de l'espace à 3 dimensions. Les polygones étant quant à eux des figures en 2 dimensions.
- Les polyèdres réguliers : Ils sont composés de polygones réguliers identiques et de chaque sommet part un même nombre d'arêtes (un polygone régulier étant une figure 2D dont les arêtes ont même grandeur et les angles intérieurs qui forment le polygone sont égaux : le triangle, le carré, le parallélogramme, ...)
- Les polyèdres convexes : Convexe signifie que si on relie deux arêtes quelconques du polyèdre par un segment de droite alors ce segment se situe à l'intérieur du volume du polyèdre.
- Les polyèdres semi-réguliers : Polyèdres composés de deux ou trois types de polygones réguliers différents. Les prismes sont des polyèdres semi-réguliers.
- Les polyèdres croisé ou étoilés : Polyèdres réguliers non-convexes. Une étoile de mer est un polyèdre étoilé.
- Les polyèdres de Jonhson : Ce sont à la base des polyèdres réguliers à ceci près qu'à au moins 1 sommet le nombre d'arête qui en partent soit différent des autres sommets. La pyramide est un exemple.
- Corps platonicien : Il n'existe que 5 polyèdres réguliers ET convexes. On les nomme les polyèdres de Platon. Par contre les polygones réguliers et convexes sont en nombre infini. C'est un exemple de plus que ce qui est vrai en 2D ne l'est plus forcément en 3D.
- Les corps archimédiens : Polyèdres semi-réguliers ayant des arêtes de même longueur, ce qui exclu une partie des prismes par exemple. Le ballon de football est un corps archimédien.
La formule d'Euler : Cette formule trouvée en 1752 par Léonard Euler établit une relation pour les polyèdres entre le nombre de leurs sommets (S), arêtes (A) et faces (F). Soit :
S + F - A = 2 En fait cette formule très utilisée de nos jours par la théorie des graphes est à l'origine une formule appartenant au domaine mathématique nommé géométrie de l'espace. Cette formule est intéressante car elle permet d'associer des polyèdres entre eux, c'est-à-dire de former des groupes/ensembles de polyèdres répondant aux conditions de la formule d'Euler. On les nomme les polyèdres eulériens. La classification des objets étant une des grandes marottes des mathématiciens, ;). d'un point de vue plus pratique et concret, la formule d'Euler permet de démontrer qu'il n'existe pas plus de 5 corps platoniciens.
Il existe de nombreux polyèdres eulériens, mais aussi des exceptions. D'ailleurs en exercice je vous propose de trouver un polyèdre régulier convexe qui fait exception.
Théorie des graphes et polyèdres : Quelle relation entre la théorie des graphes et les polyèdres ? A priori aucune puisque la théorie des graphes ne s'occupe pas d'objet dans l'espace à 3 dimensions, enfin pas directement. Ainsi si l'on projette un polyèdre selon une certaine méthode on obtient une représentation 2D de ce dernier. En théorie des graphes, ce type de représentation est appelé un graphe planaire. Voici la définition issue du livre 'Théorie des graphes' que vous trouverez dans notre bibliothèque :
- Un graphe est planaire s'il admet une représentation dans le plan tel que si deux arêtes ont un point commun, celui-ci est une extrémité de chacune des deux arêtes. Une telle représentation est dite plane.
Les graphes planaires permettent de définir des relations entre sommets, arêtes et faces plus facilement que si on travaillait dans un espace de 3 dimensions. Ainsi définit-on le degré d'un sommet, le degré d'une face, ... Les graphes planaires permettent de résoudre des questions très difficiles comme le nombre de couleurs nécessaires pour remplir des régions d'une carte sans que deux régions ayant la même couleur ne se touchent.
Voici la représentation du tétraèdre (tétra = quatre, figure composée de 4 sommets) et du cube en graphe planaire.
Quelques liens utiles
|

|
Par JF Maquiné le 20 Janvier 2004 |    | |
Vous connaissez la différence entre l'espionnage et la surveillance ? L'une est une activité non déclarée tandis que l'autre oui. Ainsi les réseaux P2P qui permettent l'échange de fichiers entre utilisateurs sont sous surveillance avec la bénédiction des gouvernements. Prenons le cas de Emule ou de la mule pour les intimes. Ce logiciel permet l'échange de fichiers de manière assez performante, mais hélas beaucoup d'utilisateurs laissent traîner sur leur disque dur les copies des CD et DVD qu'ils font pour leur usage personnel. Evidemment cela conduit à un piratage qu'Onversity dénonce. Bon ceci étant dit. Savez-vous comment vous êtes surveillé ?
Prenons le cas de Emule, si vous êtes un utilisateur de club-internet et utilisateur d'Emule vous avez déjà du recevoir un joyeux message vous informant que des poursuites pourraient être engagées par une société tierce travaillant pour le compte de tel ou tel grand groupe de maisons d'édition ou de production de films. Une des sociétés en question est : BayTSP. La question est comment font-ils pour surveiller les utilisateurs d'Emule ? Mettre en place un serveur qui permet aux utilisateurs d'Emule de se mettre en contact en tout anonymat ? Techniquement possible, mais peu plausible car ça pourrait se savoir assez rapidement. Il ne faut pas oublier que le propre de la surveillance c'est d'être discret. Une autre solution consisterait à devenir un utilisateur qui mettrait à disposition tout un ensemble de fichiers illicites. Fichiers correspondant à des données de sociétés pour lesquelles le surveillant travaille (Sony, Paramout, ...).
Toutefois il y a un problème. Pour identifier les méchants pirates il faut pouvoir disposer de l'adresse IP qui les identifie de manière unique à un moment donné sur le réseau mondial qu'est internet. Or Emule ne permet pas la divulgation de ce genre d'information comme tout autre logiciel de P2P, c'est-à-dire qu'à partir d'Emule on ne peut pas avoir l'adresse IP d'une autre personne. Mais voilà Emule ne contrôle que Emule, et il est tout à fait possible de faire un petit logiciel qui va intercepter les connexions à l'ordinateur de notre surveillant et avant qu'elles n'arrivent à Emule. Une connexion implique des données et dans ces données il y a l'adresse IP.
Ainsi donc des utilisateurs d'Emule vont se trouver en train de télécharger un morceau de fichier sur un ordinateur qui est en fait celui d'une société de surveillance. Il capte votre adresse IP, identifie le provider à qui elle appartient, lui envoie un message qui est ensuite relayé à l'utilisateur final et voilà. Ils ne vous écrivent pas directement car seule une partie de l'adresse IP est fixe et correspond en fait à l'adresse de votre fournisseur de service, le reste correspond à un client que seul le fournisseur d'accès connait. Seule la justice peut forcer un fournisseur d'accès à dire qui est exactement la personne qui a eu cette IP complète à un moment donné.
Certains me diront, qu'il serait plus simple pour les surveillants de mettre en place un serveur Emule centralisant les échanges des utilisateurs. Oui, mais voilà se connecter à un serveur ne signifie pas que vous aller pirater. Il faut consommer le piratage pour en être accusé, c'est pour ça que quand vous téléchargez un morceau de fichier d'un DIVX de 'La Guerre des Etoiles' vous êtes un vrai méchant pirate.
Cet article n'est evidement pas une analyse complète des réseaux P2P et de leur surveillance. J'essaie simplement d'attirer votre attention sur le fait que la surveillance existe et je donne un exemple possible (il me semble) d'une telle surveillance.
Bon je vous laisse méditer tout cela ;). En attendant voici un petit rappel de ce que signifie P2P. c'est l'abréviation de Peer-to-Peer et 'to' dans les abréviations anglaises se remplace généralement par 2 puisque ça se prononce de la même manière (to = two = 2). Le P2P est la mise en relation de deux utilisateurs (ici des internautes) par le biais d'un réseau (ici internet). Un utilisateur peut avoir plusieurs connexions P2P simultanées, ce qui peut le mettre en contact avec des centaines de personnes simultanément.
Complément : Manifestement cet article soulève peu d'enthousiasme :D. Bon ok, je ne le placerais pas moi-même dans le top 10 des articles d'Onversity, mais il n'est pas inutile d'ou son existence. Son objectif était de parler de la surveillance des réseaux P2P. D'abord de dire qu'elle existe, car c'est un point trop rarement soulevé, ensuite par un exemple (supposé) de mode de surveillance de vous inviter à discuter des méthodes de surveillance. Il ne sert à rien de faire l'autruche, mieux vaut savoir comment on est espionné, c'est parfois utile ;). |

|
Par Sébastien Pauchet le 19 Janvier 2004 |    | |
PHP était au départ un langage de scripts permettant d'afficher sur ces premières versions des informations dynamiques assez minimalistes (typiquement date, heure). La grande différence avec un langage tel que C, C++, c'est que le PHP n'est pas compilé. (on dit qu'il est interprété). Installé sur le serveur web, il est 'lu' lors d'une requête d'un internaute et retourne le plus généralement du code HTML. Si au début PHP était un langage purement procédural (code et fonctions), il a intégré quelques notions d'objets à partir de sa version 4. Le but n'étant pas un gain de performances mais plutôt de permettre aux développeurs de gagner en flexibilité et de pouvoir réutiliser plus simplement des portions de codes d'une application sur l'autre (les classes).
L'implémentation des notions d'objets était d'ailleurs très succincte, on ne retrouve pas de notions de portée de variables (privée, publique, globale, etc...) : elles sont toutes publiques. Il en est de même pour les méthodes (fonctions d'entrées-sorties) des classes.
Les développeurs ayant accueillit favorablement ce changement (et n'écoutant que peu ce qui leur a été dit à l'époque : utiliser les objets de manière parcimonieuse), ils se sont mis à utiliser assez massivement les fonctionnalités d'Objets de PHP malgré leur coté embryonnaire et sur les dernières versions, PHP a du fortement accélérer ces fonctionnalités pour permettre de conserver des performances décentes sans pour autant brider les développeurs.
Aujourd'hui, avec la version 4.3.4, sans atteindre la rapidité de scripts purement procéduraux, il est tout à fait possible de concevoir des applications lourdes entièrement Orientés Objets. Nombre de CMS (Content Management System : gestionnaires de sites internet) OpenSource sur Internet on d'ailleurs franchis le pas et ont grandement augmenté la portée de leurs fonctionnalités (et leur complexité) grâce à cela sans pour autant demander un monstre de puissance pour recevoir un site complexe accueillant des milliers de visiteurs par jours.
Pour autant, il faut comprendre que PHP n'a rien d'un langage objet natif, et donc, pour être efficace, il faut connaître quelques petites subtilités, en particulier sur des applications lourdes comportant plusieurs centaines de classes.
Sans trop rentrer dans le détail qui fera l'objet d'un autre article, évitez pour commencer de créer des objets dans des objets, la gestion de la mémoire étant quasi-inexistante dans PHP4, vous ne pourrez pas contrôler la destruction de ces objets une fois inutiles et ils resteront en mémoire jusqu'a la fin du script. Il est préférable de créer les objets dans votre script maître, vous pourrez ainsi savoir quels objets sont chargés et minimiser les chargements d'objets inutiles.
|

|
Par Sébastien Pauchet le 19 Janvier 2004 |    | |
Il faut aussi savoir que par défaut, PHP4 copie les objets, et à moins de le spécifier clairement, il ne travaille jamais par référence.
Ex : si vous avez un tableau nommé $objectsArray, contenant une cinquantaine d'objets et que vous dépilez ces objets à l'aide d'un foreach pour travailler sur chacun d'eux.
Ici, chaque variable $anObject sera une copie de l'objet contenu dans $objectsArray, c'est à dire que l'on va copier chaque objet contenu dans le tableau $objectsArray avant de l'utiliser et donc doubler l'utilisation mémoire pour tous les interroger. Pour peux qu'il y ai un très grand nombre d'objets à traiter cela peux vite devenir très volumineux.
Une meilleure façon de faire serait la suivante :
Le script est identique, mais le fait de compter la position ou l'on se place dans le tableau à l'aide de la variable $objectNB force PHP à travailler par référence, limitant ainsi la taille utilisée en mémoire. Cette astuce n'est malheureusement pas documentée sur le site de PHP.
Le développement de PHP va d'ailleurs aller dans ce sens, la version 5 (dont une bêta est déjà disponible) améliorera grandement l'efficacité de la gestion des objets. Dans notre exemple ci-dessus, le premier code travaillera directement avec des références d'objets, et la syntaxe du second ... ne fonctionnera plus ...
Cette version ajoutera aussi une gestion de la portée des variables (publiques/privées dans un premier temps), des méthodes (publiques/privées/protégées) et permettra l'héritage multiple des classes (limité à une dans PHP4).
Il apparaît tout de même dès aujourd'hui que PHP5 ne sera pas encore la version de PHP qui amènera une vraie gestion de la mémoire. En effet, PHP est un langage de scripting et n'a pas été pensé pour tourner longuement. Il est sensé traiter des scripts assez courts en un temps d'exécution proche de la seconde ou de la dizaine de secondes mais guère plus. La mémoire se libère alors à la fin du script.
La programmation objet est pratique pour réaliser des choses complexes, et on peux vite trouver un intérêt à réaliser des scripts tournant en permanence en tache de fond sur le serveur, d'autant que depuis la version 4.2, PHP est fourni avec un exécutable nommé CLI (Command Line Interface) tout à fait approprié à ce genre de scripts.
Malheureusement, la libération de la mémoire ne suis pas, elle est très pauvre et semble assez aléatoire. Vous avez donc tout intérêt à très bien connaître l'utilisation des variables, leur portée et les méthodes d'optimisation (ne comptez pas sur les unset( ) qui ne libèrent pas la mémoire) si vous souhaitez faire un tel script ou à vous tourner vers d'autres langages tels que Java ou Perl plus appropriés. (il existe en plus des méthode permettant de transmettre des variables entre les différents langages si vous utilisez le serveur Web Apache grâce à la fonction apache_note( ) ).
Voila pour vous donnez un aperçu d'un langage de plus en plus utilisé sur le Web, et qui continue de progresser de jours en jours en écoutant l'énorme communauté de développeurs qui gravite autour.
Je ferai des articles consacré à l'optimisation de vos scripts ou sur d'autres thèmes, le sujet est vaste alors n'hésitez pas à en proposer dans les commentaires :).
|

|
Par JF Maquiné le 16 Janvier 2004 |    | |
Je ne sais pas si vous êtes comme moi mais depuis 1 an ou 2 j'ai l'impression que le rendu graphique des jeux 3D ne change pas beaucoup. Certes les personnages sont plus détaillés, les textures plus fines et abondantes, mais l'ambiance générale ne change pas beaucoup, graphiquement s'entend. D'ailleurs les éditeurs en ont conscience et si des sociétés comme ID-Software (auteur de la série Quake, Doom) ou Valve (série Half-life) ont investi énormément dans leur prochain moteur 3D, ce n'est pas pour vous coller plus de textures ou plus de géométrie. Non, l'objectif c'est la gestion de l'éclairage dynamique et en particulier de générer des effets de variation d'éclairage et d'ombrage à vous faire trembler dans votre fauteuil douillet. Pour cela l'une des techniques les plus importantes est le bump mapping, c'est-à-dire une technique qui a pour but de donner l'illusion de vrais reliefs, tout en gérant un éclairage dynamique, c'est-à-dire que les reliefs des textures vont produire des ombres et que celles-ci seront recalculées d'images en images.
Toutefois si le bump mapping est une bonne technique elle a aussi certains défauts visuels. Le premier c'est qu'elle limite l'aspect réaliste des textures. Parfois on a l'impression qu'un objet a un aspect jouet en plastique. Le second c'est que dès qu'on s'approche trop près de la texture l'effet de relief tend à disparaître. Pour régler ce dernier problème on dispose d'une technique nommée displacement mapping qui modifie réellement la géométrie des objets au lieu de la simuler comme le fait le bump mapping. Le problème c'est que le displacement mapping non seulement n'est pas exempt de défauts, mais coûte très cher en temps de calcul pour les processeurs graphiques.
Toutefois depuis peu est apparue sur les forums du site OpenGL.org une solution d'une grande simplicité de mise en oeuvre associant les fonctionnalités du bump mapping et du displacement mapping tout en consommant peu de ressources processeur et mémoire. Cette méthode se nomme offset bump mapping ou OBM est a été mise au point par Terry Welsh. C'est cette méthode que nous allons décortiquer en vous en expliquant le principe général de fonctionnement, la technologie des pixels shaders sur laquelle elle se base et ses avantages et inconvénients.
Remarque : L'explication détaillée de l'offset bump mapping reste technique quoi qu'on fasse. Vous trouverez en conséquence en fin de seconde partie de cet article un résumé de cette méthode qui devrait permettre à tous les lecteurs de comprendre les grandes lignes de la méthode.
Mise à jour du 17/01/2004 Terry Welsh vient de publier un white paper de sa méthode (texte en anglais) dont vous trouverez le lien dans la seconde partie de cet article. Par contre il a décidé de renommer sa méthode appelée au début offset bump mapping en Parallax mapping, mais il s'agit bien évidemment de la même méthode.
Petits rappels sur le bump et le displacement mapping Pour bien comprendre l’innovation de l’offset bump mapping, il faut d’abord faire un petit rappel du bump utilisé jusqu'à présent et du displacement mapping. Le bump mapping associe à chaque élément de la texture une direction (appelée normale) qui représente l’orientation de cet élément de texture par rapport à la surface à laquelle la texture est associée. Grâce à cette normale, il va être possible de calculer l’éclairage de chaque pixel individuellement bien que la surface reste plane.
 Le displacement mapping va au contraire déformer la surface. Ainsi non seulement la déformation va permettre un éclairage adapté mais lorsqu’on s’approche de la surface celle-ci apparaitra réellement en relief.
Si vous souhaitez en savoir plus sur le bump et le displacement, n’hésitez pas à consulter l’article
Le problème du displacement est qu’il consomme beaucoup de ressources GPU et donc qu’il ne peut pas être déployé à grande échelle dans un niveau de jeu vidéo par exemple. L’idéal serait de trouver une technique qui donne les même effets visuels que le displacement mais avec un coût GPU proche du bump. Car comme nous pouvons le constater aujourd’hui, le bump fait parti des techniques parfaitement intégrées dans les nouveaux moteurs 3D.C’est cet exploit que réalise l’Offset Bump Mapping.
Qu’est-ce que l’Offset Bump Mapping ? L’idée fondamentale est de calculer la projection du rendu du displacement sur une surface plane. Voici comment ça marche :
 Lorsque le displacement est appliqué, chaque point de la surface (en bleu) est déplacé selon une hauteur qui lui est propre. Ces hauteurs sont mémorisées dans ce qu’on appelle une HeightMap, c’est-à-dire un champ de hauteur. La surface devient dont la surface rouge après déformation et la caméra voit non pas le point bleu mais le rouge.Si on voulait obtenir le même résultat sans déformer la surface, il faudrait dessiner le point dont est issu le point rouge à la place du point bleu.
C’est ce qui se passe dans l’OBM : pour chaque point bleu à dessiner, on calcule l’offset à appliquer à ce point pour trouver le point rouge à dessiner à sa place. Si on ne faisait ce calcul que pour la couleur du point, nous aurions une surface qui semblerait avoir du relief mais qui ne serait pas éclairée. Pour avoir un éclairage cohérent, on utilise la technique de bump classique en déplaçant la normale d’un point rouge avec celui-ci.
 On obtient donc l’illusion du displacement pour l’équivalent du coût en calcul du bump. Il reste quand même un point à éclaircir : comment calculer l’offset. Un calcul exact serait trop long, mais un calcul approximatif est tout à fait possible à faire rapidement. Ce calcul doit dépendre de la hauteur de déformation qu’il aurait fallu appliquer et de l’angle de vue de la caméra. La solution retenue dans le est une projection en supposant une hauteur de déformation à peu près constante autour du point.
Bien sûr, comme nous le verrons plus loin, cette approximation induit quelques effets de bord (notamment si la variation de la hauteur de déformation est très forte, l’hypothèse de constance autour du point est malmenée et des incohérences peuvent apparaître localement dans le rendu).Ce calcul de l’offset est rendu possible grâce au pixel shader.
|

|
Par JF Maquiné le 16 Janvier 2004 |    | |
Calcul de l’offset par le pixel shader Sans rentrer dans les détails de programmation, le principe est le suivant : le pipeline de rendu reçoit les coordonnées du point de la texture à rendre par défaut (cad celle du point bleu précédent.) Si le pixel shader n’a pas de programme, ces coordonnées seront utilisées ainsi dans la suite du pipeline pour le rendu. En introduisant un programme dans le pixel shader, il est possible de modifier ces coordonnées en leur ajoutant, par exemple, un offset que nous aurons calculé au passage.
Exemple pour l’OBM dans un pseudo-langage
- Entrée : coordonnée texture par défaut (Coord), vecteur de vue de la caméra (V), heightmap (HM)
- Début du programme du pixel shader
- Hauteur reçoit la hauteur lue dans la HM aux coordonnées Coord
- Offset est calculé en fonction de V et de Height (plusieurs formules sont possibles)
- Coord = Coord + Offset
- Fin du programme
- Sortie : Coord modifié.
Ainsi grâce au pixel shader, l'OBM est presque aussi rapide que le bump classique. Vous pouvez trouver ci-dessous un exemple de shader permettant de réaliser de l'OBM :
Voici à quoi ressemble le shader principale de la démonstration de l'offset bump mapping faite par Terry Welsh lui-même : - TEX height, fragment.texcoord[0], texture[2], 2D;
- MAD height, height, 0.04, -0.02; # scale and bias
- MAD newtexcoord, height, eyevects, fragment.texcoord[0];
TEX et MAD sont des instructions de shader. TEX permet d'accéder à un élément d'une texture et MAD permet d'effetuer une multiplication et une addtion en une seule instruction (MAD = Multiplier + ADditionner).
Avantages de l'Offset Bump Mapping La première chose qui marque lorsqu'on regarde un screenshot ou une démo utilisant l'offset bump mapping c'est l'augmentation de réalisme. Dans la démo d'Humus (voir plus bas : liens utiles), vous avez l'impression que les murs bougent avec la lumière ce qui correspond effectivement à un effet subjectif de notre cerveau, les volumes varient lorsque l'intensité de la lumière varie. En fait ce surplus de réalisme que permet l'offset bump mapping est du essentiellement à un effet d'accentuation du relief. C'est assez amusant car cet effet n'est pas à l'origine un effet voulu, mais une conséquence de la méthode de calcul de l'offset bump mapping. L'offset bump mapping marque plus les variations de relief car le décalage (l'offset) servant à imiter le displacement mapping est proportionnel aux variations du relief de la texture. Plus le relief est accentué plus l'offset variera et amplifiera cette accentuation. Nous verrons que cet effet peut devenir indésirable parfois.
Le second avantage c'est qu'enfin lorsqu'on s'approche d'un mur on ne voit plus les détails des reliefs s'estomper, voire disparaître. Ce problème m'a d'ailleurs souvent ennuyé dans un jeu comme Serious Sam où de loin vous avez l'impression d'un super bump mapping avec des textures très définies et de près c'est plat comme une crêpe. Vous pouvez d'ailleurs le constater sur les deux screenshots comparant un zoom avec un bump mapping classique et un avec l'offset bum mapping.

Inconvénients de l'offset bump mapping Nous avons vu qu'un des avantages était d'accentuer le relief original donnant ainsi plus de réalisme. Toutefois s'il y a des variations de reliefs trop importantes dans la texture originale, l'offset risque de prendre des valeurs trop grandes et des parties de la texture vont se chevaucher. Ceci génèrera des incohérences graphiques. Pour pallier à ce problème il faut faire en sorte que la height map n'ait que des variations 'raisonnables'. Je dis raisonnable et pas faible car au regard des démos que l'on peut voir, une bonne partie des types de reliefs utilisés dans les jeux actuels sont compatibles avec cette technique. Toutefois cela nous indique quand même que l'utilisation de la seule technique d'offset bump mapping dans un jeu n'est pas concevable, il faudra dans certaines situations en rester au bump mapping traditionnel.
Résumé de l'Offset Bump Mapping L'offset bump mapping est difficile à comprendre car elle associe les techniques de deux méthodes pas faciles à comprendre en soit du premier coup, à savoir le bump mapping et le displacement mapping. Toutefois l'idée de base semble assez simple et part du constat suivant :
Si on suppose que la caméra ne peut voir qu'un seul point de la texture à la fois, alors le point de la texture vu par la caméra, si on fait du bump mapping, n'est pas le même que si on fait du displacement. Il suffit donc de déterminer ce qui génére cette différence de position (l'offset). d'inventer un algorithme qui permette de la générer, c'est l'offset bump mapping, puis d'utiliser les capacités de calcul des pixels shaders pour effectuer les calculs sur chaque point de la texture vu par la caméra. Dans un jeu la caméra étant l'oeil (le point de vue) du joueur.
L'offset bump mapping consiste donc dans la formule :
- Coordonnées des texels du bump mapping + offset = nouvelles coordonnées
L'offset (le déplacement) est calculé par les unités de calcul internes au proceseur graphique nommées pixels shaders. L'offset varie pour chaque point de la texture, et pour toutes les textures car il n'y a pas qu'une seule texture dans un jeu.
Quelques liens utiles
Conclusion L'offset bump mapping va-t-il s'imposer ? Bien qu'il soit encore trop tôt pour le dire cette technique a d'indéniables qualités dont la moindre n'est pas la qualité de ses effets visuels mais sa facilité de mise en oeuvre. Or ce genre d'arguments a souvent décidé la communauté des développeurs 3D à adopter ou non certaines techniques de rendus 3D.
On ne peut souhaiter qu'une chose au regard des démos qui commencent déjà à apparaître sur le net, c'est que des éditeurs l'adoptent rapidement. D'ailleurs certains rêvent déjà d'un DOOM3 exploitant cette technique.
Il est à noter d'une part que la méthode de Terry Welsh est applicable autant en openGL qu'en Direct-X, d'autre part l'offset bump mapping est révélateur des possibilités que peuvent offrir les shaders et en particulier les pixels shaders. L'auteur nous a informé qu'il est en train d'écrire un white paper (document descriptif) sur sa méthode. Dès qu'il sera disponible nous vous le ferons savoir.
J'espère que cet article vous a plu. On a essayé, Patrice et moi, de faire en sorte que vous soyez informés le plus tôt possible de ce qui nous semble être une technique d'avenir. N'hésitez pas à intervenir dans le forum pour poser vos questions :).
Cet article a été conjointement écrit par Patrice Arrighi et Jean-François Maquiné |

|
Par JF Maquiné le 15 Janvier 2004 |    | |
Connaissez-vous Stradivarius ? Le personnage non, mais ses violons certainement quoiqu'en avoir vu un ou mieux en avoir écouté un (pas sur un CD) est déjà assez difficile. Evidemment si vous en possédez un, alors là ... Antonio Stradivari (dit Stradivarius) était un luthier italien (1644 - 1735) qui fabriqua de nombreux violons d'une très grande richesse sonore, très 'typée' et inimitable. Ces plus fameux violons ont été fabriqués durant la période allant de 1700 à 1725. Beaucoup ont essayé d'expliquer les qualités des violons stradivarius. Le vernis utilisé a été la première hypothèse avancée, et même si le secret de la fabrication d'un violon passe par le vernis (secret qui se transmet encore de maître à élève), on sait aujourd'hui produire des vernis d'une grande qualité, mais pas des stradivarius. La colle d'assemblage a été ensuite l'hypothèse à la mode, mais là encore les progrès de la science ont montré qu'on pouvait disposer de colle équivalente voire supérieure sans pour autant pouvoir fabriquer des violons qui égalent les stradivarius. Reste l'hypothèse du bois.
En décembre 2003 des chercheurs de l'université de Tennessee experts dans la formation des anneaux du bois marquant son âge et des chercheurs climatologues de l'université de Columbia ont proposé une hypothèse qui semble avoir fédéré tout le monde. Le secret des stradivarius résiderait dans le bois utilisé par Stradivarius. Pas un traitement quelconque du bois, comme certains l'ont envisagés, mais du bois lui-même, c'est a dire de l'arbre d'ou le bois provient. Il faut comprendre que chaque arbre d'une même espèce dispose de propriétés qui lui sont propres (un peu comme les empreintes digitales) et que ces propriétés sont essentiellement liées aux anneaux de croissance. En fonction des variations climatiques d'une saison à une autre et d'une année à une autre les anneaux de croissance croîtront et varieront différemment.
Si cette hypothèse est exacte alors il a du se passer quelque chose durant une période située entre la fin du 17ème siècle et le début du 18ème siècle, période qui correspond aux violons stradivarius ayant la qualité sonore la plus grande. C'est ce qu'ont tenté de déterminer les chercheurs des universités du Tennessee et de Columbia. Or il y a eu durant la période 1645 - 1715 un refroidissement de la Terre du à une baisse d'activité du Soleil. Cette baisse d'activité du Soleil a été déterminée par Maunder, et cette période de 'mini-glaciation' a été nommée le minimum de Maunder. L'impact d'une telle climatologie sur les arbres a été que leurs anneaux de croissance étaient plus petits en taille et les fibres de ces anneaux plus denses, plus serrées. Le chevauchement de la période de refroidissement de la Terre et de celle de la fabrication des meilleurs violons de Stradivarius est une coïncidence si extraordinaire, qu'on peut raisonnablement penser qu'il n'en s'agit pas d'une et que le vrai secret des stradivarius se trouve là.
Comment un violon émet-il des sons ? Les cordes d'un violon sont sous tension par le biais d'un chevalet. Lorsqu'on fait vibrer les cordes, les vibrations se transmettent au chevalet qui les transmet à la caisse du violon. Les vibrations du bois de la caisse produisent des variations du volume d'air situé à l'intérieur de la caisse. Il y a un phénomène de 'respiration' où l'air est successivement aspiré et expulsé par les ouies se trouvant de chaque côté du haut de la caisse. La qualité d'un violon et ce qui marque sa sonorité (ce qui en fait son âme) c'est que les vibrations du bois de la caisse et de l'air doivent entrer en résonnance, c'est-à-dire vibrer à l'unisson. C'est cette résonnance qui produit le son d'un violon et en détermine sa qualité et sa sonorité particulière. Une variation dans la structure du bois produira une variation dans la résonnance. L'effet est infime, mais comme la résonnance est un effet amplificateur du phénomène de vibration, le moindre changement vibratoire sera amplifié par l'effet de résonnance et deviendra perceptible et donc audible.
 |

|
Par JF Maquiné le 13 Janvier 2004 |    | |
Vous avez peut-être déjà lu des phrases comme : 'IBM ne maîtrise pas les diélectriques Low-K', ou encore 'le processeur de la RADEON 9600 XT est produit avec un diélectrique Low-K'. D'accord ça fait chouette dans une news ou un article d'utiliser des expressions comme ça, mais qu'est-ce que signifie réellement Low-K ? Qu'est-ce qu'un diélectrique ? En quoi les diélectriques Low-K aident-ils à la fabrication de microprocesseurs ? Telles sont les questions auxquelles je vais répondre dans ce mini-article. Evidemment si je donne directement les définitions, beaucoup de lecteurs ne vont pas suivre. Je vais donc donner quelques éléments de physique pour que tous les lecteurs puissent comprendre de quoi il retourne.
Isolant et conducteur Quand on parle de courant on parle souvent aussi de conducteur et d'isolant. Les conducteurs sont des matériaux qui laissent se déplacer librement des charges électriques, ce qui permet la conduction du courant d'où leur nom de conducteur. Les conducteurs les plus classiques sont les métaux ou des alliages. L'or, le fer, l'aluminium, ou encore le cuivre sont des conducteurs. L'isolant est aussi un matériau conducteur, mais il conduit très mal le courant c'est-à-dire que sa capacité à laisser se déplacer les charges électriques en son sein est très faible.
Qu'est-ce qu'un condensateur On appelle condensateur un petit montage qui consiste en deux conducteurs reliés à une source d'électricité. Le plus simple des condensateurs consiste à prendre des plaques de fer, de cuivre, ... et de les relier chacune aux bornes d'une pile.
 Physiquement il se produit un phénomène où des charges électriques s'accumulent sur les parois intérieures des deux plaques. Ce phénomène physique a une grande utilité aujourd'hui car il correspond à une retenue d'énergie. Un condensateur est donc un dispositif permettant de stocker de l'énergie électrique. La mesure d'un condensateur à emmagasiner de l'énergie électrique se nomme la capacité (capacitance en anglais). Ca s'écrit :
 Cette formule décrit ce qu'on nomme un condensateur à vide, c'est-à-dire qu'on suppose qu'entre les deux plaques conductrices il n'y a rien, même pas d'air. Ce sont des condensateurs presque parfaits, mais ayant un coût élevé. Dans la pratique on utilise non pas des condensateurs à vide, mais à diélectrique.
Qu'est-ce qu'un diélectrique ? Diélectrique est le nom donné à un isolant placé entre les deux plaques conductrices d'un condensateur. Oui mais pour diélectrique ? Ca vient du grec : Dia qui signifie au travers. Au travers de quoi ? Bonne question ! Entre les plaques conductrices d'un condensateur circule un champ électrique. C'est ce champ (sa force) qui déplace les charges électriques vers les armatures intérieures des plaques conductrices et permet à un condensateur d'être un réservoir à énergie électrique. Pas de champ, pas d'accumulation de charge. Or seuls les isolants ont la capacité de laisser ce champ électrique passer et donc les traverser, d'où diélectrique. Si on remplace notre isolant par un conducteur, le champ électrique ne le traverse pas et donc pas d'accumulation de charge et le condensateur ne sert plus à rien.

Permittivité, constante diélectrique La valeur Epsilon0 de notre première formule définit la permittivité du vide. La permittivité est en somme la mesure de la capacité du champ électrique à s'exercer entre les plaques conductrices. Maintenant qu'on a mis un isolant dans notre condensateur, donc un diélectrique, la permittivité n'est plus la même, en fait elle augmente. Il faut ajouter à notre formule originale un nouveau terme appelé la permittivité relative du diélectrique, notée Elpsilonr et qui nous donne la formule suivante :
 La permittivité relative se nomme aussi constante diélectrique. C'est une valeur qui varie de 1 à l'infini. le Diamant a une valeur de 5,5 par exemple.
Que signifie Low-K ? La constante diélectrique est notée K en anglais. Low signifie faible ou petit. Low désigne donc une constante diélectrique faible, c'est-à-dire un diélectrique perturbant peu le champ électrique d'un condensateur, ce champ électrique étant produit par les plaques conductrices du condensateur. On considère dans le monde des microprocesseurs qu'un diélectrique a une faible constante diélectrique donc un faible Low-K si sa valeur est < 4, soit K < 4. Par exemple le dioxyde de silicium SiO2 a un K = 4,2 ce n'est donc pas un diéletrique low-K.
|

|
Par JF Maquiné le 13 Janvier 2004 |    | |
Pourquoi les diélectriques Low-K sont-ils importants pour les microprocesseurs ? Un microprocesseur est composé essentiellement de transistors. Ces transistors sont reliés entre eux par des interconnexions en cuivre ou en aluminium pour les plus anciens. Pour éviter des fuites de courant, on isole les interconnexions avec un isolant, le SiO2 principalement. Or ce faisant on a d'un côté des conducteurs traversés par du courant et entre des isolants, donc il se produit les mêmes effets que pour les condensateurs. L'isolant devient un diélectrique qui va accumuler des charges électriques.
Maintenant je vais vous expliquer un autre phénomène lié aux condensateurs et qui est la bête noire des microprocesseurs. Quand on place un diélectrique entre les plaques conductrices d'un condensateur, la tension aux bornes de ces plaques diminue proportionnellement à K soit la constante diélectrique du diélectrique. On a la formule :
 Cela signifie que pour les microprocesseurs l'effet condensateur qui est généré induit une diminution de la tension du courant traversant les interconnexions. Les diélectriques pompent du courant ! Il y a donc perte de tension au niveau des interconnexions. Il faut donc pour les compenser augmenter la tension générale du microprocesseur. Ce faisant on augmente la dissipation thermique et au final on limite la montée en fréquence.
Utiliser des diélectriques Low-K (ou le K le plus faible possible) pour la fabrication des microprocesseurs c'est diminuer le pompage du courant fait sur les interconnexions et donc diminuer l'augmentation de tension qu'on doit appliquer au microprocesseur. Au final le Low-K permet soit d'avoir un microprocesseur sur lequel on pourra appliquer une tension plus faible pour une même fréquence de fonctionnement, soit conserver la même tension, mais augmenter sa fréquence de fonctionnement.
Autre raison : les courants de décharge Nous avons vu qu'un condensateur est un réservoir à charges électriques. Lorsqu'on coupe la source de courant qui alimente un condensateur celui-ci renvoie dans le circuit le courant qu'il a emmagasiné. Au niveau du microprocesseur on a un effet similaire. Lorsque du courant passe dans les interconnexions cela a pour conséquence de charger les diélectriques donc les isolants. Lorsque qu'il n'y a plus de courant envoyé dans l'interconnexion (courant provenant des transistors), le diélectrique renvoie dans les interconnexions le courant qu'il a accumulé. Le résultat est que le signal envoyé par un transistor durant une durée T, va être prolongé dans l'interconnexion par le courant de décharge du diélectrique. Le temps de décharge vaut :
T = R*C T est le temps de décharge. Il est dépendant de R, la résistance du circuit électrique formé par le condensateur et l'interconnexion et C la capacité du condensateur. La résistance étant en quelque sorte la propension d'un circuit à laisser s'écouler les charges. Plus elle est grande moins les charges passent facilement et donc mettent plus de temps à s'écouler.
Le problème est que si le temps de décharge est trop important, il y aura encore du courant dans l'interconnexion quand le transistor va renvoyer du courant (un signal électrique). La conséquence est que l'interconnexion transmettra du courant quasi en permanence. Or le principe même de fonctionnement d'un microprocesseur c'est de transmettre des signaux électriques par intermittence et ce sont les séquences de ces signaux qui ont un sens. S'il y a du courant envoyé en permanence, il n'y a plus qu'un seul signal et cela n'a plus aucun sens pour le microprocesseur.
En conséquence il est important que le temps de décharge du diélectrique soit le plus court possible. En premier on a diminuer la résistance en optant pour des interconnexions en cuivre au lieu de l'aluminium. La seconde solution consiste à faire baisser le capacité, et c'est là qu'interviennent les matériaux Low-K. En diminuant la constante diélectrique ont diminue la capacité (C) et donc le temps de décharge.
Le temps de décharge est un facteur limitatif de la montée en fréquence car de la fréquence du microprocesseur dépend la durée qui s'écoule entre deux envois de signaux d'un transistor. La fréquence d'un microprocesseur doit prendre en compte le temps de décharge afin que le courant passant dans les interconneixons ne soit pas continu. Diminuer la valeur K (constante diélectrique) et donc C (capacité), c'est s'assurer d'une montée en fréquence plus importante.
Difficultés à remplacer le SiO2 On connait le problème du phénomène condensateur dans les microprocesseurs depuis longtemps. Jusqu'à présent on se débrouillait bien avec le Dioxyde de silicium SiO2 (K = 4,2). Mais voilà avec la nécessité d'avoir des transistors et des interconnexions de plus en plus petits, il faut trouver un nouvel isolant ayant une constante diélectrique plus faible. On connait aujourd'hui plein d'isolants qui ont une constante diélectrique plus faible que celle du Dioxyde de Silicum, mais la majorité ne se laissent pas manipuler comme lui et on n'arrive pas à les implanter au niveau atomique pour produire un microprocesseur. Toutefois les recherches dans ce domaine avancent et on commence à trouver des successeurs au dioxyde de silicium. Il semblent que les plus prometteurs sont à base de fluor, comme le SiH2F2. TSMC l'un des plus gros fabricants de Wafer utilisera pour sa technologie 0,09 micron un diélectrique avec un K = 2,9 (technologie dite Nexsys). Si quelqu'un connait la formule du diélectrique utilisé qu'il nous la donne, on gardera le secret après publication ;).
Voilà, j'espère que vous avez appris quelque chose d'utile pour vous dans ce mini-article. Une dernière chose, si vous entendez parler des diélectriques High-K d'Intel, il s'agit de diélectriques ayant une constante diélectrique importante (Grand-K). Mais attention il s'agit là de techniques liées essentiellement aux transistors, alors que le Low-K dont il est question en général concerne les interconnexions entre les transistors. Low-K et High-K sont deux solutions techniques pour deux problèmes différents. Vu la complexité à expliquer au grand public des thèmes aussi techniques n'hésitez pas à me contacter si vous voyez des points qui peuvent être améliorés :) . |

|
Par JF Maquiné le 12 Janvier 2004 |    | |
Curieux titre n'est-ce pas ? Et pourtant cela pourrait bien être une conséquence de son récent combat ouvert contre Linux. Je m'explique. Actuellement si on veut monter un serveur internet ou un serveur tout court (serveur d'impression de données, d'application, un cluster, ...) le choix de Linux comme système d'exploitation est un bon choix. Ce choix est d'autant meilleurs si vous le couplez à des microprocesseurs Opteron d'AMD à architecture performante, intégrant un contrôleur mémoire et disposant d'un fonctionnement en mode 64 bits. Or dans l'état actuel, Linux est la principale offre dans ce domaine du 64 bits. Associé à Apache, PHP, mySQL, ... vous disposez d'une puissance tant matériel que logiciel qui satisfont la quasi totalité des besoins des managers pour la mise en place de leur serveur.
Et Microsoft dans tout ça ? Microsoft a pris du retard sur le 64 bits, et sent qu'elle risque de perdre des parts de marché encore plus importantes si elle ne réagit pas rapidement. Cela explique en partie les récentes annonces d'une campagne mondiale de publicité contre Linux, de même la mise à disposition gratuite (dans l'urgence) d'une version beta de Windows Server 2003 64 bits. Mais ce n'est pas tout. Comme je le soulignais dans un de mes mini-articles (2003) AMD a bien joué en présentant très tôt sa technologie 64 bits à la communauté des développeurs et surtout au monde du libre. Cette communauté a acquis dès à présent une première expertise dans ce domaine qui pourrait inciter des managers encore indécis à passer le cap vers Linux et les machines 64 bits d'AMD. N'oublions pas que le plus difficile ce n'est pas de trouver des informaticiens, mais des informaticiens disposant d'une expertise dans des domaines qui peuvent faire évoluer l'entreprise. Microsoft n'ayant rien de concret à présenter dans ce domaine, voit une partie grandissante de ce potentiel d'expertise lui échapper, c'est-à-dire une expertise non Windows.
Un autre point est à prendre en considération. Les microprocesseurs Athlon-64 font preuve d'une grande vélocité dans les domaines ludiques. La majorité des tests de l'Athlon-64 dans le domaine des jeux le mettent en tête des résultats et souvent loin devant les Pentium 4. Or de part l'engouement croissant du grand public pour Linux et comme l'expertise 64 bits dans le monde Linux est forte, de plus en plus d'éditeurs de jeux sont tentés d'adapter leurs jeux à Linux. De plus comme le couple Linux et microprocesseur AMD 64 bits est un couple gagnant de même que jeux et microprocesseur AMD 64 bits. Microsoft se doit de réagir en proposant rapidement une solution Windows-XP 64 bits pour que les éditeurs puissent se rallier à son panache comme ils l'ont toujours fait.
En conclusion, Microsoft se voit dans la quasi obligation dès aujourd'hui de se lancer dans une course de vitesse pour pouvoir proposer d'une part un système d'exploitation 64 bits aux professionnels avec Windows Serveur 2003, d'autre part une alternative crédible au monde ludique 64 bits avec Windows XP 64 bits. La conséquence indirecte de l'investissement important que Microsoft va consentir sur ces deux projets soit pour reprendre des parts de marché soit pour éviter d'en perdre de nouvelle c'est un soutient indirect mais important à l'architecture 64 bits des microprocesseurs Opteron et Athlon-64 d'AMD.
En conséquence tout laisse à penser que l'architecture 64 bits d'Intel (nommé Yamhill) est une technologie mort-née (on parle des hypothétiques Pentium 4 64 bits, pas des Itanium, c'est une autre discussion). Même si Intel faisait un chèque colossal à Microsoft, il ne s'agit plus directement d'argent pour cette dernière mais de parts de marché. Or perdre des parts de marché peut représenter un coût énorme pour les regagner de même qu'une dépense en temps et en énergie qui aurait des répercutions sur ses autres activités.
Alors voilà comment je lis la devinette. Microsoft soutient indirectement les choix d'AMD et Intel va devoir s'y plier. Pour Intel cela ne représente pas en fait un problème majeur. Il lui suffit d'avoir un accord d'échange de licence avec AMD, chose qu'ils font depuis longtemps pour des tas de domaines, alors pourquoi pas un accord supplémentaire, et franchement ça ne serait pas un mauvais accord, car la manière dont AMD a amené le 64 bits est technologiquement remarquable. C'est simple ça coûte peu en termes de transistor (2 à 3 millions de plus), c'est performant, l'adaptation au niveau programmation n'est pas très complexe.
Bien sûr cela n'est qu'hypothèse et je serais curieux de connaître votre avis sur la question.
|

|
Par JF Maquiné le 12 Janvier 2004 |    | |
ITER, le projet d'une centrale expérimentale pour la mise au point de la fusion nucléaire domestiquée (voir articles du mois de décembre) doit aller à l'Europe. Après une première réunion entre les 6 membres qui s'est soldée par un échec pour déterminer le choix du lieu d'implantation (Cadarache en France ou Rokkasho au Japon), une seconde réunion doit avoir lieu en février. Toutefois des déclarations ouvertes de soutient des américains au projet japonais font fi des tentatives d'établir une analyse technique objective. Dans ces conditions on ne peut que penser que le problème du choix du lieu d'implantation est devenu politique.
La maîtrise de la fusion nucléaire est l'enjeu majeur pour les problèmes énergétiques de demain. Il est indispensable pour la fin de ce siècle que l'Europe et ses alliés soient totalement autonomes dans le domaine énergétique. L'Europe (25 pays et environ 400 millions d'habitants) soutenue par la Russie (150 millions d'habitants) et la Chine (1,3 milliard d'habitants) se doivent de ne pas céder. Non seulement ces trois pays représentent 1/3 de la population mondiale, mais ils sont tous trois des pays maîtrisant déjà l'énergie nucléaire, disposant de ressources scientifiques, techniques, humaines et financières qui leur permettraient de mener à bien seuls ce projet.
En conséquence je ne peux qu'affirmer que si les japonais associés aux américains continuent de bloquer la décision, l'Europe et ses alliés devront mener seuls à bien ce projet. Il en va en parti de notre avenir énergétique. Or on sait à quel point notre dépendance énergétique nous coûte chère en pétrole.
Oui à ITER à Cadarache, oui à l'union de l'Europe, de la Russie et de la Chine !
ps : oui je sais c'est un mini-article engagé. Et alors il faut savoir prendre parfois position.
|

|
Par JF Maquiné le 07 Janvier 2004 |    | |
Un des soi-disant aspects intéressants du compilateur C/C++ d'Intel est de pouvoir vectoriser automatiquement certaines parties du code du programme. Ca c'est la théorie parce qu'en pratique il aura du mal à faire des vectorisations. Au fait qu'est qu'on entend par vectorisation ? C'est le fait que le compilateur va remplacer des opérations d'addition, de multiplication, logiques, ... sur des entiers ou des flottants gérées par l'ALU ou la FPU par des instructions vectorielles gérées par les unités multimédias comme le SSE / SSE2. L'intérêt est que ces instructions multimédias vont pouvoir traiter les données de ces opérations par lot, c'est-à-dire que si vous faites A1 = b1 + c1 puis A2 = b2 + c2, les instructions multimédias pourront traiter cela avec une seule addition au lieu de deux. Evidemment si vous n'avez que deux additions à faire dans votre programme ça n'a pas grand intérêt, par contre si ces additions sont dans une boucle qui s'exécute plusieurs milliers de fois ou plus, alors un gain significatif peut être acquis. Toutefois avoir une boucle qui ressemble à celle qui est ci-dessous n'a pas grand intérêt. Il arrive malheureusement souvent que l'intérieur d'une boucle contienne une condition de branchement. La question est donc de savoir s'il existe une condition de branchement la vectorisation aura-t-elle lieu ? J'ai justement sous la main une fonction parfaite pour ce petit test.
 La fonction effectue une addition de grands nombres, ceux-ci étant stockés dans des tableaux d'entiers non-signés. En fait cette fonction est issue d'une bibliothèque mathématique que j'avais faite à l'époque où j'étais un chasseur de PI. Cette fonction est normalement associée à une autre qui se charge des exposants, du signe et du dépassement de capacité de l'addition. Le format du grand nombre pour ce qui nous intéresse est le suivant. Chaque entier 32 bits est utilisé sur 30 bits seulement et la première valeur du tableau contient la taille du grand nombre (= nombre d'entiers utilisés pour sa représentation). Si on compile en activant l'option de vectorisation /QxW associé a /O3 comme le recommande Intel, aucune vectorisation ne se produit ! Dans un premier temps j'ai pensé que c'était la condition de branchement qui empêchait la vectorisation, mais ce n'est pas cela car un des exemples du manuel du compilateur Intel montre une boucle intégrant une condition de branchement. Par contre le problème se situe bien dans la condition de branchement. Si on la supprime provisoirement la vectorisation s'effectue. En fait ce qui dérange le compilateur version 7.1 et 8.0 c'est le terme r = 1 et r = 0. J'ai essayé des tonnes de subterfuges mais rien n'y a fait. Si une des valeurs additionnées à la valeur 'val' est modifiée dans la boucle la vectorisation ne s'effectue plus. Pour vérifier cela j'ai utilisé une valeur b que j'ai modifiée plusieurs fois dans la condition de branchement, mais qui n'est en rien liée à 'val' et la vectorisation s'est bien effectuée.
Bon voyons quand même les performances de la vectorisation. Pour ce faire j'ai repris la fonction d'addition à laquelle j'ai supprimé la partie intégrant la condition de branchement. La taille du grand nombre est de 10000 et je fais une boucle répétant 100000 fois la fonction Add00. Ce qui représente 2 millards d'additions au total !
- Sans vectorisation sans profiling : 0,937 seconde
- Sans vectorisation avec profiling : 0,937 seconde
- Vectorisation sans profiling : 0,594 seconde
- Vectorisation avec profiling : 0,563 seconde
Le gain est tout à fait intéressant avec près de 35% de rapidité supplémentaire entre l'utilisation avec et sans vectorisation. Ce qui est encore plus remarquable c'est que si le profiling ne parvient pas à optimiser la version sans vectorisation elle y arrive pour la version avec, et on atteint environ les 40 % de gain de vitesse d'exécution. Maintenant pour ceux qui voudraient connaître la vitesse d'exécution de la fonction Add00 complète mais sans vectorisation voici les résultats : - Sans profiling : 1,297 seconde
- Avec profiling : 1,125 seconde
Comme vous pouvez le constater, le profiling fonctionne très bien même lorsqu'on n'active pas la vectorisation. A la question y a-t-il eu des différences entre les versions 7.1 et 8.0 des compilateurs d'Intel ? Aucune en termes de performances, mais il s'agit d'une toute petite fonction. Par contre j'ai eu de grandes difficultés à trouver une forme à la fonction pour qu'elle tourne à de bonnes vitesses. La version 8 est beaucoup plus délicate pour trouver le code le plus performant, mais nous allons en discuter dans la prochaine partie.
En conclusion : Les capacités de vectorisation de ce compilateur sont faibles, performantes mais faibles. Il me faut vous dire aussi que l'expression 'unsigned int ptr = *val1' était nécessaire pour avoir une vectorisation. Si j'utilisais directement *val1 comme condition de fin de boucle même sans la condition de branchement il n'y avait pas de vectorisation. De même j'ai pu constater dans les multiples tests que le compilateur préfère les entiers signés aux non-signés (int plutôt unsigend int). Ensuite quand on utilise ce compilateur à partir de Visual C++ 6.0 certaines optimisations de ce compilateur empêchent la vectorisation. C'est le cas de l'optimisation 'maximize speed'. Je vous recommande 'customize' avec les options suivantes cochées : - Assume No aliasing
- Favor fast code
- Frame pointer ommision (un classique pour une bonne optimisation)
- Full optimisation
- Global optimisation (mais seulement si votre projet est suffisamment gros)
La fonction d'optimisation /Qip ou /Qipo semble aussi poser problème à la vectorisation, mais là c'est très délicat car sur un projet contenant à peine plusieurs dizaines de fonctions, c'est une option très utile s'en passer serait dommage. Bref Intel a encore du boulot sur la vectorisation automatique et ce n'est que dans certains cas bien précis et bien gentils qu'elle fonctionnera. Ah, une dernière chose, si la vectorisation ne fonctionne pas pour votre programme, enlevez l'option de vectorisation, cela vous fera gagner quelques pourcents. |

|
Par JF Maquiné le 07 Janvier 2004 |    | |
Vous pensez peut-être que la fonction d'addition de la première partie à une bonne tête et que son écriture sous la forme présentée allait de soi ? Détrompez-vous il m'a fallu plusieurs heures pour trouver la forme du code qui permettait d'avoir des performances optimums. Ainsi si par exemple vous avez la mauvaise idée de commencer le calcul par val[a] = retenu, c'est près de 25% de perte de performances que vous aurez ! C'est un petit jeu qui a toujours existé chez les compilateurs, à savoir le placement des instructions de vos programmes joue un rôle dans la capacité du compilateur à produire un code optimisé. Mais dans le cas du compilateur Intel ce petit jeu est devenu un véritable sport dans lequel il est préférable d'exceller et depuis la version 7 ce n'est plus un sport c'est un art que la version 8 confirme. Alors que 3 variantes de la fonction Add00 offraient de bonnes, voires excellentes performances, avec la version 8 seule une était digne d'intérêt, les autres étant entre 25% à 40% plus lentes ! A quoi cela est du ? Les compilateurs Intel sont capables de générer des optimisations de code extrêmement pointues, ce qui implique que les différences entre un code très optimisé et un peu optimisé seront plus marquées. Un compilateur comme le Borland C++ 5.02 n'a pas de problème à ce niveau, il est assez constant. Il ne s'agit pas de jeter la pierre aux compilateurs d'Intel car ce qu'il fait est le lot de tout compilateur moderne, et GCC sera bientôt dans un cas similaire. Avant d'aller plus loin voici les performances du nouvel analyseur syntaxique d'Onversity, il faudra par contre attendre la nouvelle version du site pour en profiter.
| Version 3.02 | Turbo C/C++ 5.02 | Intel C/C++ 7 | | Août 2002 | 4028 | 2968 | | Avril 2001 | 2921 | 2250 | | Février 2000 | 485 | 359 |
| Version 4.0 | Turbo C/C++ 5.02 | Intel C/C++ 8 | | Août 2002 | 1672 | 1421 | | Avril 2001 | 1234 | 1047 | | Février 2000 | 234 | 188 | Temps en milliseconde - Erreur : +/- 8
Pour faire court ça va vite, beaucoup plus vite. Par contre comme vous pouvez le voir, c'est le compilateur Borland qui a les gains les plus importants. Pourquoi ? L'analyseur syntaxique d'Onversity est très complexe, et c'est un véritable calvaire pour les compilateurs et les microprocesseurs. C'est un code bourré de conditions de branchement qui, la majorité de temps, ne sont pas prédictibles. La différence essentielle entre la nouvelle et l'ancienne version est que j'ai considérablement diminuer les étapes intermédiaires d'évaluation des syntagmes ce faisant j'ai diminué la quantité de données devant se trouver dans les mémoires caches de même que le nombre d'instructions. Mais la complexité du code a été accrue. Le Borland qui ne dispose pas de mécanisme d'optimisation sophistiqué a pu directement bénéficier de la diminution de certains mécanismes qu'il n'arrivait pas de toute manière à optimiser, alors que les compilateurs Intel avaient moins de grain à moudre pour exploiter l'extraordinaire capacité d'optimisation.
Les changements entre la version 3.02 et 4.0 sont très importants et j'y pensais déjà depuis deux ans, mais je n'osais pas franchir le cap car je savais l'opération très difficile. Maintenant que c'est fait, j'ai acquis une expérience sur certains points de programmation en particulier celui-ci. Lorsqu'on travaille sur un grand groupe de fonctions complexes (complexes par leur fonctionnement et leur interaction), il y a nivellement des performances que permettent les optimisations des compilateurs.
Revenons plus directement à notre compilateur Intel 8.0. Comme je le disais en début de chapitre, c'est un compilateur délicat à satisfaire pour en tirer le meilleur parti, mais il est capable du meilleur. Hélas il est aussi capable du pire. Reprenons notre multiplication, mais au lieu d'additionner nos grands nombres comportant 10000 entiers, passons les à 1000000, on ajuste évidemment la boucle exécutant la fonction de add00 pour la faire se répéter 1000 fois au lieu de 100000. Le résultat est surprenant ! - Borland 5.02 : 4,281 seconde
- Intel 8.0 sans profiling : 6,140 seconde
- Intel 8.0 avec profiling : 5,563 seconde
Catastrophique, ces résulats sont catastrophiques. Comment est-ce possible ? C'est ce que nous allons voir dans la troisième partie. |

|
Par JF Maquiné le 07 Janvier 2004 |    | |
Les optimisations qui avaient donné de si bons résultats avec la fonction Add00 de la première partie semble provoquer un gros ralentissement. Si on regarde la documentation Intel sur le compilateur, il est fortement recommandé de ne pas travailler sur les pointeurs, or la fonction add00 n'arrête pas de le faire. J'ai donc refait une fonction où je passe par une valeur intermédiaire 'b' déclarée dans la fonction et qui va centraliser toutes les opérations. Disons que c'est une des nombreuses possibilités que j'ai testé car en pratique les performances restent mauvaises.
 J'ai donc desassemblé le code et je n'y ai rien de trouvé de choquant, mais la manière donc le compilateur Intel produit des instructions assembleur est très particulière comparée au borland et à ma connaissance de l'assembleur. Mais là n'est pas le problème. Le problème c'est que les performances dans le cas de cette fonction ne sont pas stables et le changement de taille des variables ne modifie pas le code généré. C'aurait été idéale pour avoir une explication de ce comportement désagréable, mais non, on n'en dispose même pas. En fait la seule explication que j'ai pu trouver est que le code produit est conçu pour exploiter au mieux la structure du cache des microprocesseurs Intel (en particulier du cache L2) et dans notre dernier exemple on dépasse largement les capacités du caches L2 du Pentium 4. Il est d'ailleurs à noter que si on diminue la taille des grands nombres pour qu'ils se contentent uniquement du cache L1, les temps d'exécution s'allongent aussi. Finalement on peut se demander si cette importante et inacceptable variation de performance n'est pas dû soit à l'architecture des caches du Pentium 4, soit carrément à un bogue du processeur. Voici les codes assembleur des fonctions des compilateurs Intel et Borland.

Conclusion Avant de commencer, sachez que les performances sur cette fonction entre la version 7.1 et 8.0 sont identiques. Maintenant il est clair que les compilateurs d'Intel, s'ils sont des enfants prodigues, sont aussi caractériels. Capable du meilleur comme du pire. Pour éviter cela, n'hésitez pas à ajouter des variables dans une fonction pour éviter que le compilateur n'ait à manipuler souvent des pointeurs. Si vos fonctions travaillent sur des tableaux, testez-les avec de petites dimensions et de grandes dimensions, et pour savoir si cela dérape utilisez un second compilateur (autre qu'Intel) pour voir les réactions. Si ça dérape c'est que votre fonction peut vraisemblablement être améliorée pour mieux coller à la sauce Intel. En même temps c'est là le problème, plus Intel optimise ses compilateurs, plus les chances sont grandes de devoir produire un code spécifique pour obtenir un maximum de performances pour le compilateur Intel. A ce sujet, le profiling est vraiment efficace comme vous avez pu le constater.
Dans les différences entre la version 7.1 et 8.0 j'ai pu constater que l'analyse de profiling de la version 8.0 dure deux fois plus longtemps que pour la version 7.1. Je soupçonne que la version 8 fait une analyse plus importante en profondeur en particulier pour les conditions de branchement. Or le Prescott dispose d'améliorations au niveau des statistiques de branchement. Cela me laisse penser que si l'on ne voit pas aujourd'hui de différence importante entre la version 7.1 et 8.0 sur un Pentium 4, il pourrait en être autrement avec le Prescott. Malheureusement je ne disposerais pas d'un Prescott avant 2 mois, mais dès qu'il sera là soyez sûr que je reprendrais ce mini-article si des modifications de réaction apparaissaient.
Exercice : Il est possible de faire une version de la fonction Add00 sans condition de branchement. Ce n'est pas forcément évident à trouver, mais je sais que c'est possible puisque je l'ai sous les yeux :). Donc à vos claviers et que le plus créatif gagne ;).
|

|
Par JF Maquiné le 06 Janvier 2004 |    | |
Le moins que l'on puisse dire c'est que depuis deux semaines l'activité spatiale bat son plein. Jugez-en par vous-même :
Mars express et beagle-2 : Mars express est un satellite européen d'observation de Mars embarquant la sonde Beagle-2 devant atterir sur Mars pour analyser l'atmosphère, les minéraux et la présence d'eau sous diverses formes. Si Mars express s'est bien mis en orbite autour de Mars et a bien largué Beagle-2 (voir image), Beagle 2 ne donne plus aucun signe de vie. Un satellite américain a tenté en vain de prendre contact avec Beagle-2 mais en vain. Mars express tentera aussi d'établir le contact avec Beagle-2 le 7 janvier dès que sa position orbitale lui permettra de le faire. Même s'il reste un espoir infime, certains considèrent cette sonde comme perdue, ce qui serait un échec gênant pour l'agence spatiale européenne. Cela est d'autant plus gênant que les européens, n'ayant pas les budgets des américains, ne pourront pas envoyer de sonde avant plusieurs années.
Spirit : exploration de Mars : Spirit est un petit véhicule mobile qui a pour fonction première d'analyser l'histoire climatique de Mars et surtout son eau. Il s'est posé sur Mars le 4 janvier dans le cratère Gusev. Spirit n'est pas seul, il fait partie de la mission MER de la NASA qui a pour but de déposer deux véhicules mobiles sur la planète Mars. Spirit est le premier, le second se posera sur l'autre face de la planète d'ici peu.

Stardust : étude d'une comète : Stardust est une sonde lancée par la NASA en février 1999, et qui a pour mission d'étudier la comète Wild-2. La particularité de cette sonde est qu'elle va non seulement prendre des photos à moins de 500 Km de la comète mais aussi récupérer des échantillons et les ramener sur Terre ! La jonction entre Stardust et Wild-2 s'est faite le 2 janvier 2004.
L'intérêt de l'étude des comètes réside dans ce qu'elles représentent et contiennent en leur sein des éléments qui datent des premiers âges de la formation de notre système solaire. Les analyser c'est recueillir des informations précieuses sur la formation de notre système solaire et de la vie.
Double star : satellite pour l'observation de la Terre : Double star est un satellite sino-européen d'observation de la magnétosphère. Envoyer un satellite dans l'espace n'a plus rien de spectaculaire, mais il a été fait par un lanceur chinois : Long March-2C le lundi 29 décembre 2003. Après avoir envoyé en fin 2003 des hommes dans l'espace, la Chine devient un concurrent sérieux dans le domaine des lanceurs. Il va falloir compter avec la Chine à présent. En fait il serait carrément temps que l'Europe se secoue sérieusement car entre les américains, les chinois et les japonais, l'Europe est en train de prendre un retard qui pourrait lui coûter fort cher d'ici 10 à 20 ans.
|

|
Par JF Maquiné le 05 Janvier 2004 |    | |
Avec l'actualité sur l'astronomie qu'il y a depuis la fin décembre et pour le mois de janvier (je vous en reparlerais plus tard) il serait intéressant de faire un petit tour vers trois lois bien pratiques et encore utilisées de nos jours à savoir les trois lois de Kepler. Ces lois permettent de connaitre le mouvement des satellites. Par satellite il faut comprendre les satellites autour d'une planète (lune, satellites d'observation, ...) ou planète tournant autour d'un soleil. Mais avant de vous les présenter je vais vous raconter leur histoire, car Kepler ne s'est pas levé un matin en se disant : 'tient je faire trois lois'. Elles ont une raison d'être et cette raison est hautement historique.
Petite histoire des lois de Kepler Jusqu'au milieu de 16ème siècle, une théorie est en vigueur dite système de Ptolémée qui explique que toutes les planètes et le Soleil tournent autour de la Terre dans un grand mouvement circulaire. On dit qu'un tel système (la Terre est le centre de tout) est géocentrique. C'est Copernic qui révolutionne tout ça en proposant une autre explication (vers 1540) où la Terre est une planète comme les autres qui tourne autour du Soleil. C'est une révolution car pour la première fois la Terre n'est plus le centre de l'univers. Evidemment cette théorie ne convient pas à tout le monde. Ainsi Tycho Brahe astronome de l'empereur d'Allemagne Rodolphe II fait une grande quantité d'observations et recueille un grand nombre de données pour contrer la théorie de Copernic. Avec la précision des appareils de l'époque il n'y arrive pas vraiment sauf pour un cas : la planète Mars. Kepler qui succède comme astronome à Tycho Brahe reprend toutes ses données et va établir les trois lois que nous allons voir à présent. Le point fort de la découverte de Kepler réside dans le fait que les orbites des planètes et satellites ne sont pas circulaires, comme le soutenait Copernic mais elliptiques et grâce à cela il explique la particularité du mouvement de la planète Mars. Planète qui est d'ailleurs sous le feu de l'actualité, mais nous en reparlerons dans un autre mini-article.
Qu'est-ce qu'une ellipse Comme les deux premières lois de Kepler reposent sur les propriétés (leurs particularités) des ellipses, je vais donner quelques éléments qui les caractérisent pour que tout le monde puisse suivre, d'autant plus que la compréhension des lois de Kepler peut se faire dès l'âge de 13/14 ans.
 Une ellipse est une figure géométrique composée d'un grand axe (A, A') et d'un petit axe (B, B'). Dans une ellipse il y a deux points du grand axe qui ont une propriété importante. On nomme ces deux points les foyers de l'ellipse et on les note généralement F et F'. Si on joint le foyer F à un point M sur l'ellipse et si on joint le foyer F' à ce même point alors on a la formule suivante :
F'M + FM = 2a Il faut noter que les ellipses appartiennent à la famille des coniques dont la parabole et l'hyperbole sont deux autres exemples. On les caractérise par une valeur 'e'. Si e = 0 on a affaire à un cercle, si e vaut entre 0 et 1 (0 et 1 étant exclus) tel 0 < e < 1, alors on a afFaire à une ellipse. Si e = 1 c'est une parabole et si e > 1 (1 étant exclu) alors il s'agit d'une hyperbole. Mais dans la suite de ce mini-article seule l'ellipse et ses foyers nous intéresse.
1ère loi de Kepler : loi des orbites (1609) La première loi de Kepler établit une relation entre l'orbite des planètes et le Soleil. Ainsi le mouvement de chaque planète s'effectue sur une ellipse (chaque planète ayant sa propre ellipse) dont l'un des foyers représente la position du Soleil. Cette loi permet de connaitre la trajectoire des planètes et satellites.
 2ème loi de Kepler : loi des aires (1609) La seconde loi est un peu plus complexe. Elle établit une relation entre la distance d'une planète au Soleil et sa vitesse de déplacement. Soit une planète qui se déplace (sur l'ellipse) d'un point P1 à un point P2 durant une durée 't' alors l'aire formée par le triangle P1, P2 et F (l'un des foyers où est situé le Soleil) sera constante (donc toujours la même) quelque soit la position de départ du point P1.
 Cette formule est très importante car d'une part elle implique qu'une planète a une vitesse variable. Plus elle est éloignée du Soleil plus elle se déplace lentement et plus elle est proche du Soleil plus son déplacement est rapide. La seconde conséquence de cette loi c'est qu'on peut déterminer la position d'une planète à une période t, puis t', t" etc ...
Toutefois il ne faut pas perdre de vue que la trajectoire elliptique des planètes n'est pas aussi marquée que sur les figures que je donne, généralement la longueur a et b sont très proches, ce qui explique pourquoi Ptolomée a cru que leur trajectoire était circulaire.
3ème loi de Kepler : loi des périodes (1618) La troisième loi de Kepler est ce qu'on appelle en science une loi empirique c'est-à-dire que Kepler a cherché une formule qui collait aux données qu'il possédait, mais ne l'a pas démontré. En fait comme cette formule s'est avérée juste, elle a perduré jusqu'à nous et nous l'utilisons encore. On sait même la démontrer aujourd'hui ce que je ferais dans un prochain mini-article qui lui sera entièrement consacrée.
 Cette loi énonce que le carré de la période T de révolution d'une planète ou d'un satellite en orbite circulaire autour du Soleil (ou d'un foyer) est proportionnel au cube du rayon 'r' de son orbite. On dit aussi plus simplement que le rapport T2 / r3 est constant. L'interêt de cette loi et de permettre de calculer la période ou la distance au soleil d'une planète en ne connaissant que soit T soit 'r' et la constante.
Vous remarquerez que j'ai utilisé le terme de circulaire. En fait cette loi est d'abord une loi valide pour les mouvements circulaires, et elle fonctionne aussi parfaitement bien avec les orbites elliptiques.
Pour finir sachez que les lois de Kepler sont encore couramment utilisées pour faire une première et rapide approximation sur la position et le mouvement des planètes et leurs caractéristiques comme leur période. Les lois de Kepler s'incrivent dans ce qu'on nomme la cinématique et les lois de Newton sur la gravitation qui leur succèderont 60 ans plus tard s'inscrivent dans le cadre de la dynamique. Voici les définitions selon le dictionnaire de physique de notre bibliothèque :
- Cinématique : Partie de mécanique qui étudie la géométrie des mouvements indépendament des causes qui les produisent.
- Dynamique : Partie de mécanique qui étudie les relations entre les forces agissant sur les corps et le mouvement de ceux-ci.
|





YOUM (analyseur syntaxique temps réel) | Nombre de définitions trouvées 163 Multi-dico par texte : actif - Multi-mots par définition : 4
|
|
|


 
 
|