Google NaCl : Du code natif dans le navigateur

Arnaud de la Grandière |
Alors que Chrome OS déplace le débat au sein du navigateur, ce choix technologique ne va pas sans inconvénients : le code exécutable au sein d'un navigateur est autrement plus lent que du code natif. Un détail qui est d'autant plus gênant que Chrome OS se destine avant tout aux netbooks, qui sont déjà très limités en puissance. Pour y remédier, Google a mis au point une technologie qui semble toute indiquée pour son système d'exploitation.

Commençons par expliquer le pourquoi du comment : les applications exécutables contiennent du code binaire qui s'adresse tant au processeur qu'aux API (Application Programming Interface) du système d'exploitation. En tant que telles, les applications se destinent donc à un couple CPU/OS spécifique et ne peuvent être utilisées sur d'autres plateformes telle quelles. Le langage machine est spécifique à chaque processeur, et il est fastidieux d'apprendre ce langage à chaque fois qu'on programme pour un processeur différent, sans oublier qu'il est assez abscons et difficile d'accès. Afin de rendre la programmation plus accessible, on utilise un langage universel tel que le C, qui est converti dans le langage spécifique à la machine par un compilateur.

Le web se destinant à une multitude de postes clients, il a donc fallu trouver d'autres moyens pour exécuter des instructions, afin que ces opérations soient universelles. Ainsi, toutes les technologies qui exécutent du code côté client (JavaScript, Flash, Shockwave, Java…) sont basées sur une couche d'abstraction matérielle, par le biais d'un langage intermédiaire qui n'est pas compilé mais interprété. Un "interpréteur" spécifique à chaque machine se charge de traduire ce langage universel dans un langage compréhensible par la machine concernée, ce qui se fait au prix d'une exécution bien moins véloce. Par conséquent, toutes les fonctions "lourdes", comme par exemple le décodage d'une vidéo, sont transférées à l'intérieur des interpéteurs, ne laissant aux développeurs que la latitude d'y faire appel sans pouvoir les modifier ou créer leurs propres fonctionnalités évoluées.

L'autre inconvénient de cette approche, c'est que les fonctions en question ne seront disponibles que sur les plateformes qui disposent de l'interpréteur idoine. Il est ainsi impossible de lire les contenus en Shockwave sur une machine tournant sous Linux (à moins de passer par un intermédiaire supplémentaire tel que Wine). C'est notamment pour remédier à ce problème qu'on a intégré nombre de fonctions équivalentes dans le standards HTML 5. L'interpréteur n'est cette fois plus dans un plugin, mais intégré directement dans le navigateur.

La question de la fluidité d'exécution est devenue d'autant plus cruciale avec la multiplication des "web apps" et du "cloud computing" : si un certain nombre de fonctions peuvent être exécutées par le serveur, il reste important de limiter les accès et d'exécuter un certain nombre de fonctions côté client pour plus de réactivité. Les différents navigateurs sont entrés dans une course à la compatibilité et à la rapidité d'exécution de leur moteurs JavaScript précisément pour ces raisons. Mais aussi rapides qu'ils soient, les moteurs JavaScript ne pourront jamais arriver qu'à une fraction de la vitesse d'exécution du code natif. Il existait bien des moyens d'exécuter du code natif, comme par exemple les ActiveX, mais ceux-ci restent non seulement cantonnés à Windows, mais en outre ils posent de sérieux problèmes de sécurité, puisqu'ils sont susceptibles de faire tout un tas de misères à la machine sur laquelle ils s'exécutent.

C'est pour tâcher de remédier à ces différents problèmes que Google a mis en chantier une nouvelle technologie, nommée Native Client (NaCl pour faire plus court, et plus geek, puisque c'est également le symbole chimique du chlorure de sodium). Il s'agit d'un environnement permettant d'exécuter du code natif dans un navigateur web, tout en garantissant une certaine portabilité et plus de sécurité que les ActiveX.

Ainsi, il devient possible d'intégrer du code exécutable dans le navigateur, ce qui permet de faire bien plus de choses qu'avec les alternatives existantes jusqu'ici : créer son propre codec vidéo, intégrer des jeux tels que Quake, etc. Il est possible d'utiliser différents langages, y compris de l'assembleur.

Native_Client_Quake_01


Pour le moment NaCl fonctionne sur Windows, Mac OS X et Linux, mais il ne supporte que les processeurs x86 en 32 bits, cependant Google travaille au support du 64 bits ainsi que des processeurs ARM. Google n'a pas encore précisé comment elle comptait simplifier le support de multiples processeurs pour les développeurs. Le projet en est encore à ses balbutiements, et se présente pour le moment sous la forme… d'un plugin, ce qui va quelque peu à l'encontre des efforts du HTML 5, pourtant soutenus par Google. La firme de Mountain View a cependant d'ores et déjà intégré le code de Native Client dans son navigateur Chrome (quoi que désactivé par défaut), et enjoint les autres acteurs à en faire autant, sachant que NaCl est distribué en open source.

Ca ne suffira malheureusement pas à l'utiliser sur l'iPhone, à moins qu'Apple ne l'intègre elle-même dans une future version de Safari, puisque la licence de l'App Store interdit toute application permettant d'exécuter du code externe arbitraire. Quoi qu'il en soit, Google compte mettre cette fonction à profit dans Chrome OS, ce qui lui permettrait d'avoir des applications intégrées dans le navigateur presque aussi véloces et puissantes que n'importe quel exécutable autonome. Native Client ne permet pas pour le moment d'accéder à la carte graphique, les éléments graphiques sont donc entièrement calculés par le processeur, mais elle compte y mettre bon ordre en interfaçant NaCl avec son autre plugin, O3D, qui ouvrirait ainsi la porte d'OpenGL aux applications natives réalisées par ce biais (voir notre article Google sort un plugin 3D).

En somme, Google résout ici un problème épineux de Chrome OS, mais sachant que les systèmes d'exploitation concurrents n'ont pas les mêmes problématiques, il est difficile d'évaluer dans quelle mesure cette initiative trouvera un écho chez les autres fabricants de matériels et éditeurs de navigateurs. Google se confronte là à une autre quadrature du cercle : les développeurs n'ont d'intérêt que pour les technologies susceptibles de s'adresser à un assez grand nombre d'utilisateurs, et les utilisateurs n'installeront le plugin que s'ils rencontrent des contenus qui le nécessitent. Si NaCl a un intérêt tout trouvé pour les utilisateurs de Chrome OS, il faut encore que cette population atteigne une masse critique suffisante pour justifier l'investissement sur ces développements spécifiques.

Faute de quoi, ceux-ci devront se cantonner aux web apps en JavaScript, universellement reconnues, ce qui limitera la portée et l'intérêt du système d'exploitation de Google. Il ne faudra donc pas trop de la puissance du géant de l'Internet pour imposer ses technologies face à un marché qui ne voit pas toujours d'un très bon œil son expansionnisme.

skitched
avatar biniou | 
Ca sent le sel cette multiplication de technologies ... Le code natif dans un browser me laisse dubitatif. On est en train de réinventer la roue. Je pense qu'il faut séparer la toile du desktop ...
avatar negaca | 
Quand j'ai vu le titre, me suis dis que c'étais une blague mais en fait non ! C'est bien le nom du sel qui est utilisé pour faire un nom de techno scientifiquo prout prout ..
avatar johannk | 
Je n'ai pas d'avis, mais je dis merci à Arnauld pour cet excellent article, bien expliqué malgré la complexité de la chose.
avatar Anonyme (non vérifié) | 
Google re-invente la roue et Apple a encore une longueur d'avance sur ce sujet, pour ceux qui ne sont pas au courant il y a le projet clang qui se base sur LLVM ( Low Level Virtual Machine http://www.llvm.org/ ). Adobe l'utilise déja dans flash 10 pour faire tourner du code C dans les applications flash ( http://www.quaddicted.com/engines/files/quake-flash.swf ), mais ce n'est pas encore aussi performant que cela devrait être. Le principe est de compiler du code C ( ou autre ) pour un processeur virtuel et de recompiler ce code à l'exécution pour obtenir un exécutable parfaitement adapté à sa configuration ( le résultat est souvent proche voir même supérieur à du code directement compilé pour le processeur ciblé ).
avatar Dr_cube | 
On s'éloigne un peu de la fonction première du web, qui était de partager facilement l'information avec un langage de description de données simple (HTML). Même si je comprends parfaitement les raisons des webapps et de la décentralisation des données et des logiciels, je reste dubitatif sur l'intérêt de transformer à ce point le web en usine à gaz.
avatar lukasmars | 
plokta Si y'a bien un domaine dans lequel Apple fait figure de dernier de la classe, c'est bien le cloud. Ils essaient de se coller au streaming avec l'achat de lala, vont sans doute rendre dispo itunes store via un simple navigateur mais il etait plus que temps ! Ils collent tant bien que mal à la concurrence mais l'innovation dans ce domaine, c'est clairement google qui donne le "la" .
avatar pervi | 
Les navigateurs passeraient outre les systèmes d’exploitations, ils pourraient se contenter que du « bas niveau ».
avatar Zed-K | 
Réinventer la roue, et carrée tant qu'à faire... Google, hier : le web c'est l'avenir, on y croit, tout sera appli web. Google, aujourd'hui : le web, c'est l'avenir, on y croit, mais en fait vu qu'on se rend compte qu'on a ouvert notre gueule un peu trop vite, on va rajouter une couche système sur les applis web... Super convainquant... J'essaye déjà peu à peu de m'extirper du développement web que je trouve infâme par la démultiplication des technos qu'on monte les unes sur les autres, et qui sont interprétées différemment suivant les navigateurs, les différentes versions des navigateurs, voire le même navigateur sur des OS différents... ça ne fait que conforter ce que je pensais, faut VRAIMENT que je change de job... surtout qu'en moyenne, les dev web sont carrément sous payés comparé aux dev "bureau" (bien souvent à raison, mais ça cause du tort aux autres =/)
avatar an3k | 
Google sort pleins de choses ces derniers temps (GoLang, Chrome, Chrome OS, Android, Wave...) mais rien n'accroche vraiment. Les betas ont fait le succès de Google, je ne pense pas que les alphas auront le même effet. Et comme dit plus haut, alchemy dans flash est lui aussi un plugin, et n'est pas en alpha lui...
avatar _HAL_ | 
Plokta : Neanmoins Flash Alchemy compile le code C/C++ en bytecote LLVM puis en source Actionscript 3 puis enfin en bytecode de la vm Flash, donc ce n'est pas du code natif. [url=http://labs.adobe.com/wiki/index.php/Alchemy:FAQ]source (How does Alchemy work?)[/url]
avatar françois bayrou | 
En attendant, le résultat est là, les performances sont impressionnantes, ce qui est le but :)
avatar Goldevil | 
La plupart des interpréteurs modernes comprennent un compilateur JIT (Just In Time). C'est pour cela que du code Java peut parfois fonctionner à près de 70% de la vitesse que le même code en C++ compilé. Si des applis java peuvent paraître lentes c'est pour d'autres raisons. La première étant que Java propose ses propres API qui font l'interfaçage avec les API du système d'exploitation. C'est normal car cela assure la portabilité mais pas un accès optimum aux ressources de la machine. Un développeur Java n'a pas à connaître Cocoa, Carbon, Windows, X-Window... Tout cela pour dire que les interpréteurs ont encore de beaux jours devant eux. Google réinvente la roue. Je trouve que l'on touche à un problème de fond. Le langage HTML n'a pas été conçu pour être exécutable. Il s'agit de mélanger des informations et la manière de les afficher de manière cohérente. Le Javascript, les évolutions des CSS et du HTML 5 ne font que rajouter des trucs et astuces pour faire avec le HTML une chose non prévue. Si je dois faire une analogie, je dirais que le HTML est une voiture 4x4 sur laquelle on a rajouté un turbo, une carrosserie aérodynamique, une seconde suspension surbaissées, etc. Tout cela pour en faire un bolide de course. Oui, on y arrive mais cela ne sera jamais aussi bien adapté qu'une véritable F1 dont tout a été pensé pour la course en partant du châssis. Baser un OS sur un navigateur cela me semble aussi ridicule que baser un OS sur un tableur ou un traitement de texte. Puisque je vous dis qu'on fait tout avec des Macro dans Word ! L'informatique est cyclique comme la mode. Aujourd'hui on veut reproduire le bon vieux modèle client serveur avec AJAX, HTML5, NaCl... Dans 10 ans on nous dira qu'il faut simplifier le client au maximum et un génie réinventera le navigateur web.
avatar Dr_cube | 
[quote]Baser un OS sur un navigateur cela me semble aussi ridicule que baser un OS sur un tableur ou un traitement de texte. [/quote] Je partage quelques uns de tes arguments. Mais attention quand même : un navigateur est depuis toujours une sorte de système d'exploitation. Il permet de faire tourner des logiciels dans une machine virtuelle qui fait totalement abstraction de la machine physique. Selon ce point de vue c'est système d'exploitation. Alors bien sûr après il y a tout l'aspect gestion de ressources qui n'est pas forcément présent, mais bon. Oui ok je chipotte ^^.
avatar Un Vrai Type | 
@Dr_cube : On peut même dire que ce n'est plus du web, déjà. @ lukasmars : Le cloud est une sorte d'absurdité, ou un passage "obligé" du présent vers l'avenir. Apple s'en fou, elle a déjà du "cloud" depuis longtemps avec ses iPod par exemple. Sauf que ça oblige l'utilisateur à acheter un truc en plus. Ho tiens, les iPod ne synchronisent que certaines choses dans certaines conditions... Gageons que ces limitations seront levée avec la iPlaque ( :D ) et que ce sera l'argument commercial majeur ! Rappelez vous "Un iPod, un téléphone, une tablette pour surfer" Pour Apple la synergie est un synonyme de OS+matériel+accès au réseau et c'est aussi un homonyme parfait de ++$$$ Bref, je pense au contraire que les limitations frustrantes quand on a 2 macs ou un iPhone et un mac seront levée par la iPlatteCommeUneLimande qui sortira bientôt. Et globalement, Apple à raison, les gens* préfèrent mettre 1000€ dans un trucs qu'ils peuvent toucher tout les matins que 10€/mois dans un truc dont l'intérêt et le sens leur échappe un peu. *Les gens, sous entendu les personnes qui ne s'intéressent pas à l'informatique. @ Goldevil : Je continue à penser que l'évolution générale est : 1 ordinateur pour XX personnes. 1 ordinateur par personne. XX ordinateurs par personne. (Reste que l'avenir pourrait être xx ordinateur pour YY personnes) Dans ces conditions, on passe du web au "cloud". Mais le cloud s'appuyant sur le web à des limitations etc... C'est pour ça que je epnse que c'est juste une transition.
avatar Dr_cube | 
@ Un vrai type : James Crowley, un chercheur que j'ai eu la chance d'avoir pour prof, dit que le nombre d'ordinateurs par personne double tous les 3 ans. Par ordinateur il comprend aussi bien les iPod, les iPhone, et les PC. [quote]Law for Digital Device Density: The number of networked programmable digital devices per person doubles every 3 years[/quote] 1 ordinateur pour XX personnes. 1 ordinateur par personne. XX ordinateurs par personne. XX ordinateurs pour YY personnes = décentralisation (cloud computing) + informatique ubiquitaire. Je suis entièrement d'accord avec ça. Par contre je ne pense pas que le cloud computing soit une absurdité. Tous les médias sont voués à passer par deux étapes : — Démétérialisation : plus de support physique : - CD = iTunes Store, - DVD = divx / VoD, - lettre = email, - cartouche de jeu = AppStore/Steam, - logiciel version boite = téléchargement sur site éditeur, - etc. — Décentralisation : on ne possède même plus le fichier et on ne sait plus où il est ! - iTunes Store = Deezer / Spotify, - VoD = Streaming, - email = webmail, - AppStore = OnLive (streaming de jeux), - téléchargement et installation de logiciels = applications web, - etc. Ca marche pour absolument tous les types de média. Selon cette théorie, l'avenir des logiciels est au web (ou équivalent), donc il est logique que les principaux acteurs cherchent à l'améliorer. Avec l'iPhone, Apple a voulu faire un grand coup en misant tout sur les applications web, mais c'était encore trop tôt, surtout pour un téléphone. Ils vont certainement récidiver dans quelques années. Palm a voulu faire le même coup avec le Palm Pré et le WebOS, mais là encore c'est trop tôt. On verra si ChromeOS (idem pour Jolicloud) arrive trop tôt lui aussi. Dans tous les cas on voit clairement qu'ils sont pressés et qu'ils ne veulent pas manquer le coche des applications web. Comme toujours dans ce domaine, il ne suffit pas d'avoir la techno, il faut l'avoir au bon moment, ni trop tôt ni tard.
avatar Dr_cube | 
Tous mes signes "=" sont à remplacer dans votre tête par un signe "flèche vers la droite", mais on n'a pas le droit de les faire...

CONNEXION UTILISATEUR