tux.generation

Aller au contenu | Aller au menu | Aller à la recherche

jeudi, avril 15 2010

Chapitre 4 : Les langages à machine virtuelle

Au début du chapitre 2, je vous disais qu'il n'existe que deux catégories de langages : compilés ou interprétés. Eh bien j'ai menti :p En réalité, il existe une troisième catégorie que l'on pourrait qualifier d'hybride, car située à mi-chemin entre compilation et interprétation. Parmi ceux-ci figurent des pointures comme Java ou C#.

En quoi ces langages sont-ils hybrides me direz-vous ? A première vue, il est vrai que ces langages sont des langages compilés puisque les fichiers sources doivent être compilés avant toute utilisation. En réalité, c'est un peu plus complexe.

Le point commun entre tous les langages hybrides, c'est la nécessité d'avoir à installer une machine virtuelle sur les postes informatiques qui auront à exécuter les fichiers produits en sortie de la compilation : Après compilation, un fichier source Java ou C# ne devient pas un fichier binaire, mais un fichier bytecode, c'est-à-dire un fichier écrit dans un langage plus concret (comprenez plus proche du processeur) que le code source mais pas directement compréhensible par le processeur pour autant !

A la différence d'un fichier binaire, un fichier bytecode ne peut être exécuté par le processeur qu'à la condition qu'un interpréteur appelé machine virtuelle traduise à la volée les instructions bytecode en une suite de 0 et de 1.

A ce stade, vous devez certainement vous demander l'intérêt d'un truc aussi compliqué :D Je dois traduire mon fichier source en bytecode (étape de compilation) puis exécuter le fichier bytecode dans une machine virtuelle (étape d'interprétation)... ... ... gromel gromel... mais quelle perte de temps !!!%% En somme, on cumule les inconvénients des langages compilés et interprétés. Eh bien vous avez (presque) raison...

Presque... car il existe un avantage à s'encombrer d'une machine virtuelle, c'est la portabilité ! La portabilité d'un code source est sa capacité (ou non) à être exploitable dans des environnements différents, comprenez par là sous des systèmes d'exploitations divers : Windows, GNU/Linux, BSD, MAC OS etc...
Ainsi, la traduction en bytecode d'un code source JAVA est directement exécutable dans n'importe quel environnement, à partir du moment ou la machine virtuelle adéquate est installée. C'est la raison pour laquelle on qualifie souvent les machines virtuelles de plate-forme, sorte d'intermédiaire entre le bytecode et le système d'exploitation. La machine virtuelle rend un code source indépendant de son environnement d'exécution.

Attention : Un programmage écrit dans langage compilé traditionnel comme le C n'est pas portable. Un code source écrit en C devra être recompilé dans chacun des environnements d'exécution envisagés car l'étape de compilation induit une dépendance avec le système d'exploitation.

  • Cas du Java :

Java est un langage hybride inventé par Sun Microsystems. Il n'est exploitable qu'en association avec une JVM (Java Virtual Machine). Cette JVM peut être la version officielle de Sun Microsystems ou une version officieuse optimisée dans un but différent. Bien sûre, la JVM est une application disponible sur tous les systèmes d'exploitation, sinon l'atout portable du Java serait perdu.

  • Cas du Microsoft.NET :

Les langages .NET ne fonctionnent qu'en association avec la machine virtuelle .NET de Microsoft. La plate-forme .NET n'est pourtant distribuée que pour les systèmes d'exploitation Microsoft, bien que des portages officieux sous d'autres environnements soient en cours (projet Mono). Quel est l'avantage d'une telle machine virtuelle me direz-vous ?

Eh bien plus que la portabilité, avec .NET Microsoft a offert aux développeurs l'opportunité de coder dans différents langages pour collaborer par delà la limite imposée par leurs compétences.

C'est la raison pour laquelle .NET propose de coder en plusieurs langages : VB.NET (à ne pas confondre avec le VBA), C + +.NET (à ne pas confondre avec le C + +) et C#.NET. Ainsi, la machine virtuelle de Microsoft sert d'interface entre différents développeurs et différents langages d'un côté, et un système d'exploitation Microsoft de l'autre. Tandis que la JVM sert d'interface entre un développeur JAVA d'un côté, et différents systèmes d'exploitation de l'autre. L'objectif recherché n'est pas le même !

Dernière remarque pour finir :
Le nom .NET peut désigner plusieurs choses. Il s'agit souvent de la machine virtuelle. Parfois c'est aussi le mot chapeau pour recouvrir les trois langages VB.NET, C + +.NET et C#.NET. En toute rigueur, .NET est le nom du framework (comprenez, environnement de travail) regroupant la machine virtuelle, des bibliothèques DLL Windows et un pack de logiciels permettant de développer en VB.NET, C + +.NET ou C#.NET. Ces logiciels font partie de la famille des IDE (Integrated Development Environments, Environnements de Développement Intégrés). Ce sont des outils destinés à simplifier le travail du développeur.

Chapitre 3 : Langages compilés VS interprétés

Indépendamment du paradigme auquel appartient un langage, tous les langages de programmation se répartissent en deux grandes catégories selon leur méthode de mise en œuvre :

1. Les langages interprétés
2. Les langages compilés

  • Les langages interprétés

Un code source écrit dans un langage interprété est traduit à la volée en langage machine (binaire) compréhensible par le processeur. La traduction est assurée par un programme appelé interpréteur. Pour exécuter un fichier source écrit en langage interprété, l'interpréteur doit impérativement être en cours d'exécution sur le dit poste informatique. Le code source écrit dans un langage interprété est souvent appelé script, et par extension un langage interprété est dit langage de script.

Exemples : XHTML, PHP, Javascript, VBA et Shell-script font partie des langages interprétés les plus courants. L'exécution d'un code source écrit dans l'un de ces langages ne passe pas par une étape préalable de compilation.

  • Les langages compilés

Un code source écrit dans un langage compilé doit impérativement être traduit en langage machine avant d'être exécuté. Cette étape de traduction - appelée compilation - est assurée par un programme appelé compilateur. Le compilateur prend le fichier source en entrée et produit en sortie un fichier écrit en langage machine, dit fichier binaire. Un fichier binaire peut être selon les cas, soit un fichier exécutable (EXE en environnement Windows) par un utilisateur ou un logiciel tiers, soit une bibliothèque (DLL en environnement Windows) mise à disposition d'un fichier exécutable.

Exemples : C, C++, Fortran, Basic, Pascal et Python font partie des langages compilés les plus courants. L'exécution d'un code source écrit dans l'un de ces langages nécessite compilation. Seul le fichier binaire exécutable ainsi produit est exploitable.

Dans le chapitre 4, nous verrons qu'il existe en réalité un autre type de langage auquel appartient d'ailleurs le C#.NET !

mercredi, avril 14 2010

Chapitre 1 : Notion de langage

En informatique, un langage de développement est un langage formel constitué d'un ensemble de mots-clés et d'une sémantique permettant de réaliser et d'exploiter un SI (système d'information). Il permet au développeur de dialoguer avec le processeur de l'ordinateur. Il s'agit donc d'un véritable langage permettant de dialoguer avec nos chers ordinateurs, tout comme les langues permettent aux populations de communiquer à travers le monde. Notez cependant que les langages de développement ne permettent pas à deux individus normalement constitués de discuter de tout et de rien, à moins d'avoir à faire à des spécimens avérés de nerds !

Retenez au passage qu'un fichier contenant du code porte le nom de fichier source. La terminaison du fichier source est fonction du langage dans lequel il est écrit :

- .HTML pour une source écrite en HTML
- .PHP pour du PHP
- .JAVA pour du Java
- .C pour du langage C
- .CC ou .CPP pour du C++
- .CS pour du C# etc...

Le premier langage de programmation s'appelait Assembleur et fut inventé en 1947. Depuis Assembleur, l'informatique a fait du chemin et les développeurs actuels ont le choix parmi plusieurs centaines de langages de programmation. Parmi les langages de développement les plus répandus aujourd'hui figurent C/C++ en programmation système, JAVA et .NET en développement logiciel, XHTML/PHP/Javascript en développement web et SQL pour interagir avec les bases de données.

De nombreux autres langages sont utilisés dans des domaines divers, comme Prolog dans le domaine de l'Intelligence Artificielle. Gardez bien à l'esprit qu'il existera toujours des langages dont vous n'avez jamais entendu parler, aussi ne cherchez pas à tous les connaitre mais plutôt à maîtriser la méthode et les réflexes qu'un bon développeur doit suivre indépendamment du langage qu'il pratique.

Le développement C# par l'exemple

Aujourd'hui, je vous propose avec ce billet d'entamer un projet qui me tient à cœur depuis quelques temps, à savoir la rédaction d'un cours présentant les notions fondamentales du développement en C#.NET. Mais attention ! Il ne s'agit pas d'un cours normal composé d'une succession de chapitres académiques. Pour cela, il existe déjà de nombreux livres et ressources web qui vous apprendront bien mieux que moi à développer en C#.

Mon objectif est plus modeste : Il consistera à mettre en ligne une succession d'exemples abordant différentes thématiques de programmation (scientifique, temps réel, console ou graphique etc...). Lycéen, mon prof de maths en terminale avait pour habitude d'introduire chaque nouvelle notion - non par un cours - mais par un exercice (simple) afin de rendre plus concret le thème abordé. C'est le même principe que je me propose de développer tout au long de mon blog ! L'apprentissage par l'exemple en somme :)

Mais avant d'en arriver là (aux premiers exemples de sources C#), il me semblait important de redéfinir la notion de langage de développement et de présenter les grandes typologies de langages afin de situer le C# dans cette jungle qu'est le jargon IT !

Ce premier billet est donc le sommaire du cours à venir. Il sera régulièrement mis à jour afin de pointer vers les différents chapitres du cours au fur et à mesure de leurs rédactions. Bonne lecture !

Sommaire :
Chapitre 1 : Panorama des langages de développement
Chapitre 2 : Langages compilés vs langages interprétés
Chapitre 3 : La compilation
Chapitre 4 : Présentation du framework .NET
Chapitre 5 : Premier programme en C# : Hello World en mode console
Chapitre 6 : Second programme en C# : Hello World en mode graphique
Chapitre 7 : Programmation scientifique : Implémentation du modèle de Black & Scholes

vendredi, mars 6 2009

GTA IV sur PC : Historique et optimisation

  • Introduction

GTA IV aura sans doute été un des jeux PC ayant fait couler le plus d'encre durant la fin d'année 2008. D'abord sorti sur consoles (XBOX 360 et PS3) en Avril 2008, le portage du jeu sur PC aura duré 8 long mois, Rockstar Games ayant plusieurs fois repoussé la date de sortie. Lorsque le jeu est sorti, ses graphismes de pointe et son gameplay très immersif (la ville est telle un terrain de jeu dans lequel le joueur peut faire ce qu'il veut) ont incité nombre de joueurs à acheter une console pour jouer au jeu sans attendre.

  • La sortie tant attendue

Si vous faites comme moi partie des courageux ayant attendu la version PC, vous trépigniez à la sortie du jeu le 08 Décembre 2008. Vous avez surement été déçu. Pourquoi ? Simplement parce que sur la majorité des configs, le jeu est moche. Ehhh oui ! Alors que tout le monde se trémoussait d'impatience à l'idée de déambuler dans un somptueux Liberty City, de nombreux joueurs ont été déçus car le jeu laggait en réglant pourtant la qualité des graphismes au minimum et les ombres étaient si moches qu'elles gâchaient littéralement le plaisir du joueur.

Un vent de protestations a commencé à souffler sur internet. Le jeu a été mal porté dit-on. Le moteur 3D du jeu (portant le doux nom de RAGE) ne permettrait pas l'utilisation du filtre AA (anti-aliasing) même en forçant ce filtrage depuis les paramètres des drivers de la carte graphique. Pour plus de détails sur le principe de fonctionnement du moteur, je vous renvoie à cet excellent article paru sur le site Ère Numérique.

En réalité, le choix du moteur 3D joue pour beaucoup dans l'apparente piètre qualité graphique du jeu sur PC. Bien adapté aux faibles résolutions d'un jeu sur console, le moteur pêche sur PC du fait de l'affichage en plus haute résolution. La situation est un peu ridicule, à l'heure ou les consoles de jeux sont munies de sorties vidéo HD, et alors même que Rockstar Games prévoyait un portage sur PC (comme la grande majorité des précédents opus de la série GTA).

  • En résumé

Au final, les heureux propriétaires de PC dotés de 4Go de RAM, une carte graphique avec minimum 512 Mo de mémoire vidéo et un processeur quad core cadencé à la vitesse de la lumière (j'exagère un peu) pourront sans doute se permettre de monter allègrement les paramètres graphiques du jeu et ainsi retrouver sur PC la beauté du jeu tel qu'il est sur console. Pour les autres, c'est dur ! Très dur ! Le jeu est soit moche, soit moins beau qu'il ne devrait être compte tenu de la configuration sur laquelle il tourne. C'est la réflexion qui revient le plus souvent sur les forums : Je ne comprends pas, je fais tourner Crysis avec tous les paramètres à fond et c'est fluide alors que GTA IV lagge en réglages minimum. Bah oui...

A mon sens, Rockstar Games a commis une énorme erreur en procédant à un tel portage sur PC. On ne peut pas affirmer Mon jeu est beau, c'est juste qu'il faut attendre la prochaine génération de PC pour s'en rendre compte. Quand les PC haut de gamme actuels correspondront à l'entrée de gamme demain, là vous verrez que le portage était réussi. Ce raisonnement revient à dire qu'aujourd'hui on peut commercialiser des jeux nécessitant une config' plus musclée que celle équipant la majorité des PC-istes. Est-ce le début des jeux accessibles uniquement aux hard-gamers ?

  • Un patch, deux patchs, trois patchs, quatre patchs...

Rockstar Games n'est pourtant pas resté sans rien faire. Un premier patch (v1.01) est sorti le 15 Décembre 2008. En parallèle, le fabriquant de GPU nVidia a sorti la version bêta 180.84 de ses drivers GeForce sensée améliorer les performances du jeu. Pour finir, un second patch officiel (v1.02) est sorti le 24 Janvier 2009. C'est mieux mais c'est pas encore ça !

  • Hallelujah

Tout n'est pas sombre à Gotham Liberty City et il existe fort heureusement quelques manipulations relativement simples permettant d'améliorer de manière significative les performances graphiques du jeu. J'ai testé ces manips sur une configuration présentée comme minimale pour faire fonctionner le jeu, soit :

CPU : Intel Core 2 Duo @ 2.4GHZ GPU : nVidia GeForce 8600 Gt @ 256 Mo dédiés RAM : 2 Go DDR G-Skill OS : Windows XP SP3

Pour rappel, voici la config préconisée par Rockstar Games :

OS : Windows Vista - Service Pack 1 ou XP - Service Pack 3 Processeur : Intel Core 2 Duo 1.8Ghz ou AMD Athlon X2 64 2.4Ghz Mémoire : 1.5 Go Disque dur : 16 Go d'espace disque disponible Carte graphique : 256 Mo NVIDIA 7900 ou 256 Mo ATI X1900

1. La première des choses à faire est de s'interroger sur son OS. Je dirais qu'au dessus de 2Go de RAM, vous pouvez vous permettre de faire tourner le jeu sous Windows Vista. Sinon je vous conseille de le démarrer sous Windows XP. Cela dépend aussi de votre processeur. Windows Vista est sensé savoir tirer meilleur parti d'un processeur à cœurs multiples, puisqu'il s'agit d'un OS plus récent que Windows XP. Cependant, Windows XP a été tenu à jour par les Service Pack donc cela joue-t-il réellement ?

2. La seconde chose à faire est de procéder à une défragmentation du disque ou de la partition sur laquelle est installé GTA IV.

3. La troisième chose à faire est d'installer le dernier patch officiel.

4. Vient maintenant le temps de la bidouille. Rendez-vous dans les propriétés du raccourci vous permettant de lancer GTA IV et modifiez la ligne de commande en passant le paramètre -norestrictions. Si vous avez installé le jeu dans le dossier par défaut, vous devriez obtenir : “C:\Program Files\Rockstar Games\Grand Theft Auto IV\LaunchGTAIV.exe” -norestrictions

5. Dans la foulée, allez à la racine du jeu (répertoire contenant les exécutables gtaiv.exe et LauchGTAIV.exe) et créez un fichier intitulé commandeline.txt (avec le notepad) contenant la liste des paramètres suivants sur une seule ligne : -norestrictions -nomemrestrict -percentvidmem=99 -availablevidmem=1.0 -novblank Vous pouvez mettre une valeur de paramètre pour availablevidmem supérieure à 1.0 si vous le souhaitez. Cette valeur indique le pourcentage de mémoire vidéo que vous allouez à GTA IV, en plus de la mémoire dédiée sur votre carte graphique. En d'autres termes, c'est le pourcentage d'utilisation de l'option turbocache.

Exemples : Si vous mettez la valeur à 1.0 et que vous avez un GPU avec 512 Mo dédiés, vous utilisez 100% x 512 Mo VRAM = 512.0 Mo VRAM. Si vous mettez la valeur à 0.8 et que vous avez un GPU avec 512 Mo dédiés, vous utilisez 80% x 512 Mo VRAM = 409.6 Mo VRAM. Si vous mettez la valeur à 1.5 et que vous avez un GPU avec 512 Mo dédiés, vous utilisez (100% x 512 Mo VRAM) + (50% x 512 Mo RAM) = 512.0 Mo VRAM + 256 Mo RAM = 768 Mo au total etc...

Veillez donc à régler ce paramètre au minimum à 1.0. Si votre GPU ne dispose pas de beaucoup de mémoire dédiée (VRAM) alors réglez ce paramètre à une valeur supérieure à 1.0, tout en veillant à ne pas trop monopoliser votre mémoire RAM. Il est inutile d'allouer une part trop importante de votre mémoire RAM au processeur graphique si vous ne disposez plus suffisamment de RAM pour faire tourner le jeu correctement.

6. Exécutez le jeu et allez dans l'écran des options graphiques. Commencez par régler la qualité des ombres sur Haute au minimum.En dessous, les ombres scintillent et c'est vraiment moche. Concernant le réglage de la résolution et de la qualité des textures, je vous conseille de privilégier la qualité des textures au détriment de la résolution. Sur ma config' minimaliste, je règle la qualité des textures sur Haute et la résolution sur 1024x768 alors que je joue sur un écran 19" => interpolation ! Pourtant le résultat est meilleur qu'avec une faible qualité de textures et une résolution adaptée à mon écran.

  • Pour conclure
Avec ma faible configuration décrite précédemment, je fais tourner le jeu à une moyenne de 25 FPS, ce qui est excellent compte-tenu de mon matériel. Avant de lancer le jeu, je kille le processus explorer afin de gagner un peu en performances.

jeudi, mars 5 2009

Tux Generation est né !

Bienvenue aux tous premiers visiteurs de mon blog Tux Generation. Ce blog a pour vocation d'aborder des sujets divers comme l'informatique, les sciences, la musique, l'actualité ou tout simplement réfléchir sur le monde qui nous entoure.

Bonne visite ! N'oubliez pas de déposer un commentaire ;)
Votre Très Dévoué, Tux

egg.png