Comme vous pouvez le voir ce blog est encore très vide. J’espère le peupler rapidement le temps de trouver des idées d’articles (courts) à y publier, si vous avez des suggestions n’hésitez pas à les envoyer.

En attendant, voilà une présentation rapide :
Grégory Massal, surnom LeGreg (ne m’appelez pas comme ça dans la vraie vie, en vrai c’est Grégory), je développe.. des trucs on va dire depuis que je suis petit. J’ai commencé par le Basic sur Thomson (à l’école) puis rapidement Amstrad CPC, j’ai vaguement touché à l’assembleur et logo à la même époque mais c’était vraiment pas grand chose. En réalité, je n’ai découvert ma vocation pour la programmation que bien plus tard après des études d’ingénieur. J’ai essayé de lier cette vocation à ma passion pour les jeux vidéo, donc si j’ai un peu évolué dans le domaine du développement de jeux on va dire que mon chemin s’en est un peu écarté je travaille dans le domaine du graphisme PC et du temps réel.

Je vis en ce moment aux USA et en particulier au Texas, dans sa capitale Austin (j’ai longtemps séjourné en Californie dans la Silicon valley).

Je fréquente Developpez.net depuis un bout de temps, voir ma liste de sujets :
http://www.developpez.net/forums/u6269/legreg/
Et vous pouvez me retrouver sur plein de forums (gamedev, nofrag, beyond3d, hardware fr, mes propres sites). À vrai dire je passe probablement trop de mon temps sur le web et mes projets personnels en souffrent mais bon..

En dehors de ce blog je tiens plusieurs sites perso sur divers sujets :

• LeGreg Home page, mon ancien site « CV » et plus du tout à jour, tout en anglais comme vous pouvez le remarquer.
• In a coder’s mind, In a coder’s mind, une tentative récente de regrouper tous mes articles sur la programmation et certaines interventions. Avec son pendant en français Dans l’esprit du codeur.
• Mes photos, de Californie, du Texas, d’Hawaii
• Journal de programmation.La partie blog de mon site CV, centrée sur la programmation et plus très en forme il faut le dire.
• Out of my mind. Un autre blog général, en anglais celui-là.

Voilà visitez mes sites en attendant, envoyez vos suggestions de posts (générales, sur le graphisme, le futur du hardware et de direct3d etc.).

A bientôt !

A quoi sert timeBeginPeriod (API win32) et quelle est son influence sur le timing du VSync (dans Direct3D) ?

Pour résumer : l’OS Windows est un OS multitâche, c’est à dire qu’à un moment donné il y a N applications différentes qui peuvent s’exécuter : on va les appeler Processus (process en anglais) – même si théoriquement application et processus peuvent être différents -, et à l’intérieur de chaque processus il y a des fils d’executions différents (thread en anglais) qui s’exécutent en parallèle.

Comment l’OS fait-il cela ? Et bien il va diviser le temps d’execution processeur en tranches. Si application A et B tournent en même temps : il va donner la première tranche d’execution à A, puis la deuxième tranche à B etc. Si les tranches sont petites alors pour l’utilisateur c’est effectivement comme si A et B s’exécutaient en simultané. Les threads natifs et la gestion des process de l’OS est indépendant du nombre de cores du CPU, il y a peu la plupart des PC vendus avaient un CPU avec un seul core.

Le truc qui permet à cela de fonctionner c’est que le multitâche est invisible pour l’application, ce qui facilite la programmation d’applications mais complique l’OS qui doit empêcher une tâche de prendre plus de temps que la tranche allouée. Il fait ça en lançant des interruptions toutes les X nanosecondes (via un timer interne qui va générer des interruptions systèmes), lorsque l’interruption arrive, meme si l’application A n’a pas fini sa tache courante, le noyau de l’OS va arrêter son exécution et donner la main à l’application B.

Bien entendu ce changement est coûteux (relativement et en temps processeur, ça arrive tout de même des centaines de fois par secondes) : il faut sauver l’état de A (son contexte) pour que quand B a fini, A puisse reprendre comme si de rien n’était. Ce coût doit donc être amorti sur un grand nombre d’instructions pour pouvoir être négligé. Si on fixe chaque tranche à 10ms, cela donne un bon paquet d’instructions exécutables avant d’avoir à changer de contexte.

Seul problème, cette division en tranche de 10ms est plutôt bonne pour les applications génériques et les serveurs (ce pour quoi NT/2K étaient chargé à la base) mais elle est mauvaise pour toute application qui nécessite un timing très précis (temps réel, rendu vidéo etc). En effet une application qui passe la main, n’est pas sûre d’être rappelée avant N * 10ms, N le nombre d’applications qui attendent leur tour pour être exécutées. Si l’application n’a pas besoin de beaucoup de temps de calcul CPU (attente active) mais tu aimerais être prévenu d’un évènement avec un délai court (moins de x millisecondes) alors ce n’est pas idéal. Certaines personnes préconisent de faire une attente active à 100% (sans rendre la main aux autres processus). Là encore aucune garantie si la tranche courante est écoulée, l’OS va obliger à rendre la main. Par ailleurs l’utilisation du CPU devient non optimale là où on pourrait mettre à profit les mesures de réduction de consommation de courant (CPU idle). Ou l’on pourrait permettre à un autre thread de faire un traitement en tâche de fond pendant ce temps.

En échange quand on passe la taille de chaque tranche à 1ms à la place de 10ms (par exemple), on cause un process switch toutes les 1ms au minimum soit dix fois plus souvent, et le coût de l’échange peut donc être amorti sur beaucoup moins d’instructions qu’avant. D’où le coût CPU supplémentaire à charge apparemment équivalente. Au coût du switch il faut rajouter l’invalidation des caches du processeur (le process qui prend la main n’utilise probablement pas les mêmes données). La période minimale est de 1ms, mais on peut obtenir des résultats proches avec une période de 2ms avec un coût CPU moindre.

Au final, donc l’utilisation de timeBeginPeriod ne se justifie que si l’on a mis en évidence des problèmes de timing. De plus même avec une période petite, rien ne garantit le temps réel : l’OS garantit juste un « best effort » qui peut-être très loin de l’idéal. En pratique pour une application « temps réel » comme un jeu en mode exclusive (plein écran), usuellement la seule concurrence pour les cycles d’horloge est elle-même. Rien n’empêche également d’entamer la période courte juste avant une période d’attente active (le moment où l’on peut rendre la main mais on désire être réveillé rapidement), puis de restaurer la période à son niveau normal après l’attente active.

LeGreg

Free software

Le projet sera publié avec une license Open Source/Code réutilisable librement. Non seulement cela mais il réutilisera largement de nombreuses parties de code Open Source existant. Google Chrome ne part donc pas de zéro comme il serait difficile d’imaginer un tel projet même réalisé avec les moyens de Google. Les pages webs seront rendues par Webkit (le moteur de rendu de page web utilisé par Safari).

Pour résumer, Google ne se réserve pas tous les droits exclusifs sur Chrome, et souhaite même voir des projets s’approprier le code et les idées. Mozilla Firefox ou tout autre projet Open Source avec une license compatible pourrait donc copier directement des parties de Chrome ou simplement des idées. En pratique, il faudra voir ce qu’il en sera. Meme si on peut imaginer que quelqu’un branche le code existant de Chrome et en fasse une copie concurrente, l’expérience passée tend à montrer que seule la branche originale correctement maintenue et avec l’appui des fondateurs originaux survit (Mozilla firefox, Linux, etc). Surtout que Google prévoit l’écriture de Plugins pour étendre le fonctionnement du navigateur.

On peut noter une anecdote amusante est que le nom choisi « Chrome » est couramment utilisé pour désigner une partie d’interface utilisateur qui ne contient pas le contenu web (menus, barre d’adresse, boutons de navigation, etc). Il est très probable que ce soit volontaire.

Architecture

L’une des grosses nouveautés annoncées et la prépondérance du multi-processus au sein de l’application Chrome.Usuellement, chaque application est représentée par un processus système unique. Un processus est associé par l’OS a un espace mémoire virtuel dédié, un contexte d’exécution (avec plusieurs threads) et des privilèges (droits d’accès). Donc une grappe de processus constitue l’entité « Chrome » et ceux-ci collaboreront avec des processus fils et un chef d’orchestre.

Un vrai plus ? L’espace mémoire n’est plus partagée entre les processes, ce qui est donc mis en avant par Google est donc que la gestion mémoire est très simplifiée, puisqu’une tab, plugin etc, qui utilise de la mémoire n’interfère pas avec un autre et donc peut-etre fermé et immédiatement libérer toute la mémoire associée. Il faut mettre cela en parallèle à une application « classique », qui a une gestion mémoire centralisée. Si une page A et une page B sont chargées en même temps, alors tous les bouts de mémoire alloués par A et B vont se retrouver dans une page mémoire commune. Lors de la fermeture de B, les bouts de A seront entourés de bouts de B et à moins de faire une défragmentation active (avec déplacement des pointeurs qui pointe toujours vers cette mémoire) il ne sera pas possible de libérer cette page mémoire. C’est ce qu’on appelle la fragmentation et est lié à la difficulté à recycler la mémoire inutilisée. En pratique cela dépend des applications. Il faudrait connaître les chiffres dont Google dispose sur le niveau de pertes entrainées par la fragmentation avant de voir si il y a un gain réel et perceptible. Par exemple Firefox 3 a beaucoup amélioré la gestion de la mémoire par rapport à ses prédecesseurs et ceci en améliorant et en réarchitecturant leurs allocations. Difficile de dire également si l’utilisation d’un processus par tab ne va pas causer une surallocation de mémoire puisque certaines parties partagées ne pourront plus l’être. Qu’en est-il du coût de reconfiguration de la mémoire après un process switch ? Cela n’est pas le seul avantage apporté par le multi-processus cependant. Voir plus bas.

Un autre avantage est que tout échec catastrophique dans un des processus entraine la fermeture de ce processus et c’est tout. C’est une idée qui a déjà utilisé pour d’autres applications, mais ceux qui ont expérimenté des crashs de navigateurs seront heureux d’apprendre que les dégâts resteront localisés dans une seule tab. Le site web A, ne pourra pas accéder aux infos du site web B puisqu’ils résideront dans des processus différents. Non seulement chaque tab aura un processus mais également le moteur de rendu de page web, la machine virtuelle javascript pour cette page web, etc. D’après Google dans les autres navigateurs le rendu de la page web et l’exécution de javascript sont sérialisés, l’un attendant constamment après l’autre ce qui peut limiter l’intéractivité ou obliger le script de faire des contournements pour émuler le multitâche. Tâches longues ou requêtes asynchrones viennent à l’esprit. Chaque processus est également listé indépendamment dans le gestionnaire des tâches et donc sa consommation mémoire etc peut être facilement visible. Enfin on peut donner des droits variés pour chaque sous-partie du browser, ce qui augmente la sécurité, voir plus loin.

Performance

Google s’est focalisé sur la performance avant les features. On vient de citer l’architecture multiprocessus qui réduit théoriquement la fragmentation. Mais Google veut aller plus loin que la simple amélioration graduelle. Leur but annoncé est de rendre le navigateur suffisamment rapide pour un lot de nouvelles applications webs (plus complexes que ce qui est possible actuellement).

On a également cité Webkit, le moteur de Safari, qu’ils ont choisi pour le rendu des pages. D’après eux, le moteur est beaucoup plus simple et rapide que la plupart des autres moteurs existants (chiffres ?).

V8 est le nom de leur nouvelle machine virtuelle. Là par contre il semble qu’il s’agit d’un nouvel effort. Elle inclut une compilation just in time en code natif (pour une execution beaucoup plus rapide que si interprétée). Et également l’instanciation de classes. Il faut savoir que Javascript est un langage très souple où la notion d’objet prédomine sur la notion de classe (comparé à un langage comme C++ ou Java où les classes doivent être explicitement déclarées à la compilation). Ceci lui fait gagner en flexibilité mais perdre en rapidité potentiel, le code ne pouvant pas être théoriquement partagé entre objets différents, de même leurs membres étant à des positions arbitraires. La machine virtuelle va tenter d’analyser le code pour extraire une structure de classe là où le développeur n’en a pas déclaré afin d’accélerer le traitement pour les objets qui partagent les mêmes propriétés. Leur garbage collector est d’après eux également beaucoup plus efficace à libérer les objets de la mémoire et semble d’après leur description beaucoup plus agressif au prix d’un book keeping plus important probablemnt.

UI

Dans les navigateurs actuels, la tab est un ajout par rapport à la navigation en fenêtre. Ici c’est le contraire c’est la tab qui prédomine. La fenêtre est un conteneur temporaire : il est possible de déplacer la tab d’une fenêtre du navigateur à une autre, instancier une fenêtre à partir d’une tab ou même peut-etre entre plusieurs applications (?), soyons fous.

L’UI externe est très réduite, il est désormais possible de faire beaucoup plus depuis la barre d’adresse qui acceptera toutes sortes de commandes et des raccourcis claviers. Il est possible d’afficher la liste des sites les plus souvent visités, récemment visités ou réouvrir des tabs fermées à partir de la nouvelle page d’accueil (qui remplace la page « blank » des autres navigateurs). Il n’est plus nécesaire de bookmarker explicitement pour se souvenir des sites visités.

Sécurité

La sécurité a été mise fortement en avant, avec l’acceptation du fait que le web est un endroit pas très sécurisé malgré tous les efforts.

La tab, le moteur de rendu de pages, les plugins, le javascript, tous ont leurs propres processus système et les parties qui traitent le contenu des pages webs tournent dans une sand box, ou un process aux droits les plus limités possibles (sand box = bac à sable). Par exemple, aucune communication ne peut-être initiée par la sand box, toute communication se fait par l’intermédiaire d’une question réponse d’un niveau supérieur comme en réponse à un clic de l’utilisateur. Un contenu type javascript ou même un exploit qui prend contrôle du processus de rendu, ne peut générer un clic sur l’interface, capturer les touches du clavier ou lire à un endroit arbitraire du programme ou de l’OS.

Si le rendu de pages web standard et l’exécution de javascript sont fortement sécurisés, le contenu additionnel qui doit passer par un plugin est un vecteur d’attaque potentiel. Google reconnait cela et va donc créer de nouvelles classes de plugins. Certains pourront s’exécuter dans la sand box donc avec un risque minimal. Ou d’autres plugins seront externes à la sand box (comme l’UI) mais intéragiront avec la contenu de manière totalement standard et donc avec peu de vecteurs potentiels d’attaque. Bien sûr pour cela il faut que l’auteur du plugin soit adepte des principes fondateurs de Chrome, et donc nécessitera du travail supplémentaire et de la persuasion.

Tout comme Microsoft IE8, un nouveau mode qui permet de surfer en mode totalement privé c’est à dire sans qu’aucune info de la séance de navigation ne soit stockée sur l’ordinateur localement ce qui empêche les gens qui ont accès à l’ordinateur de retrouver les sites webs etc que vous avez visités. Bien entendu cela ne veut pas dire que vous êtes « anonymes » sur Internet (les sites webs connaissent au moins votre adresse IP), et cela n’est pas le but de cette feature.

Les popups sont totalement contrôlables par l’utilisateur et l’ouverture de fenêtres intempestives est totalement éliminé. Bien entendu cela veut dire que l’utilisateur doit faire un effort supplémentaire pour les sites qui aiment ouvrir de nouvelles fenêtres qui ne sont pas des publicités, mais l’alternative (heuristique pour détecter une popup de pub) laisse trop de trous dans lesquels les auteurs de scripts peuvent s’engouffrer.

Quoi de neuf ?

Google Chrome vient se rajouter à la longue liste de propriétés possédées par Google, et donc contribuera à la prédominance de la marque pour tout ce qui touche au web. Bien entendu leur discours officiel c’est que l’amélioration de l’expérience du web pour tous profitera indirectement et mécaniquement à Google qui est bien positionné par là. Y a-t-il des gains potentiels bien plus direct sur la captation d’audience ? le tracking d’utilisateur etc ? Difficile à dire, mais ce sont des arrières pensées dont Google est certainement coutumier.

On s’interrogera également sur le positionnement d’un nouveau web browser par rapport à la concurrence. Est-ce que les nouveautés annoncées changera quelque chose à l’équilibre actuel entre les poids lourds Internet Explorer et Mozilla firefox ? Pour quelque chose qui est considéré comme aussi basique que l’affichage de page web et dans un monde où théoriquement la seule valeur ajoutée possible d’un navigateur est d’afficher ces pages correctement et rapidement ? Ou est-ce que les ajouts à l’interface utilisateur vont changer la manière dont les gens consommeront le web ? Pourquoi ne pas contribuer à Firefox directement avec les nouvelles idées plutot que de créer une nouvelle marque ? Bien entendu on se souviendra que Firefox génère une partie de ses revenus de l’accord qui le lie avec Google concernant les gains publicitaires de la fonction recherche de Firefox. Gains qui disparaitraient si les gens n’utilisaient plus que le navigateur made in Google.

Bref encore une annonce encore un peu floue, mais on espère en apprendre plus et surtout pouvoir tester la bête dans les jours à venir.

LeGreg

Sources:
* L’annonce de Google Chrome en BD : http://www.google.com/googlebooks/chrome/index.html
* Télécharger la béta de Google Chrome : http://www.google.com/chrome