Intel mise sur le HTML5 et River Trail pour soulager les développeurs

Vite, avant qu'ils ne se pendent tous

Le 13 septembre 2012 à 14h16

4 min

Société numérique

Société

Lors de la seconde keynote de cet IDF , Renée James a tenu à nous parler de son concept de « Transparent Computing ». Si cela inclut des notions de sécurité ou un concept marketing tel que le « cloud flexible » on retiendra surtout la volonté d'Intel d'unifier le développement à travers les plateformes et les OS, notamment grâce au HTML5.

Vie de développeur = VDM ?

Et pour débuter sa conférence, Renée James nous a montré une vidéo au sein de laquelle la vie de développeur était présentée de manière bien amère : celui-ci croule en effet sous les plateformes, les OS, les stores... et n'aurait jamais assez de temps pour s'adapter, le tout avec un environnement qui ne cesse d'évoluer. La monétisation est aussi un gros problème, une majorité d'applications ne permettant pas à ceux qui en sont à l'origine de vivre.

Un constat qui peut paraître assez réaliste, mais qui ne représente sans doute pas la vision que peut avoir l'ensemble des développeurs qui produisent des applications au quotidien. Malheureusement, cette vidéo un brin anxiogène n'a pas été mise en ligne.

Vanter HTML5 après la sortie de Zuckerberg... c'est moche

Quoi qu'il en soit, Intel continue de penser que la solution est toute trouvée : le HTML5. Fonctionnant sur l'ensemble des plateformes disponibles, pouvant être exploité au sein d'applications natives, il ne cesse d'afficher des performances et des capacités plus importantes. Mais cette annonce tombait mal : le lendemain de la fameuse interview de Mark Zuckerberg, que James a évoquée non sans une certaine amertume, il était plus complexe de tenir ce discours.

Mais outre ce cas particulier, il faudra bien que les géants du secteur finissent par s'accorder afin de permettre à des sociétés de taille moyenne d'assurer leur présence sans avoir à embaucher une armée de développeurs, souvent complexe à constituer tant les talents sont rares. Intel annonce ainsi que selon ses statistiques, 40 % des développeurs exploitent déjà HTML5 et autant compteraient y passer.

Le géant de Santa Clara semble néanmoins conscient que le HTML5 dispose encore de nombreux défauts, le fait même d'être rendu par un navigateur étant sans doute le principal, et précise que beaucoup de travail sera encore nécessaire. Mais Intel semble continuer à fonder ses espoirs sur une telle solution.

Un choix d'autant plus intéressant (et ironique) que celui qui vante le x86 et ses instructions dédiées, nous explique donc que les applications doivent s'éloigner du code machine pour fonctionner partout de la même manière, même sur ARM.

Quoi qu'il en soit, plusieurs démonstrations ont été effectuées afin d'évoquer les possibilités offertes par le HTML5, comme vous pourrez le voir sur ces deux vidéos :

River Trail nativement supporté par Firefox en 2013, une nouvelle Developer Zone

De son côté, Intel en a profité pour annoncer qu'il mettait à jour son site dédié aux développeurs, et que celui-ci proposerait toute une palette d'aides et d'outils pour les adeptes de l'HTML5. Certains sont déjà disponibles par ici, comme un « Playground » vous permettant de tester du code en ligne. On attendra néanmoins de voir ce qui arrive par la suite afin de juger de la pertinence de la chose.

On notera aussi que le projet River Trail, actuellement proposé via une extension pour Firefox devrait être supporté nativement d'ici à 2013. Pour rappel, celui-ci consiste à l'exploitation de plusieurs coeurs via du code Javascript. Le malheur des développeurs web est en effet que JS soit au centre de leurs projets, celui-ci n'ayant pas évolué sur certains aspects de ce genre.

Google tente bien de contourner le problème en misant sur Go, mais Intel ne semble pas privilégier vraiment cette approche. Reste maintenant aux développeurs à trancher, et à se positionner entre le natif et le HTML5, la présence sur l'ensemble des plateformes ou le fait de ne se concentrer que sur certaines d'entre elles...

Commentaires (36)

levhieu

Le 13/09/2012 à 14h28

Elle est comment l’API HTML5 pour un driver ?

" />

lain

Le 13/09/2012 à 14h49

à la base le html5 c’est pas censé être fait pour les page web ? j’ai du louper l’étape ou le html 5 passe du statue de language de site web a a language de programmation ^^”

methos1435

Le 13/09/2012 à 14h55

lain a écrit :

à la base le html5 c’est pas censé être fait pour les page web ? j’ai du louper l’étape ou le html 5 passe du statue de language de site web a a language de programmation ^^”

+1

Le HTML n’a pas été pensé pour ça. Le javascript également. C’est absurde de vouloir passer par là pour unifier le développement sur plusieurs OS / Architectures…

Ils ont qu’a s’entendre pour développer un vrai langage fonctionnant partout. Mais bon, ca casserait leurs projets d’enfermement de l’utilisateur…

Anonyme

Le 13/09/2012 à 14h58

lain a écrit :

j’ai du louper l’étape ou le html 5 passe du statue de language de site web a a language de programmation ^^”

T’as pas loupé qu’une étape " />

Dude76 Abonné

Le 13/09/2012 à 14h59

methos1435 a écrit :

Ils ont qu’a s’entendre pour développer un vrai langage fonctionnant partout. Mais bon, ça casserait leurs projets d’enfermement de l’utilisateur…

Mmm. Pas d’accord avec cette théorie du complot.

C’est déjà le but de Java et de C#;

Les spécifications y sont ouvertes et accessibles;

Le problème, c’est la portabilité des bibliothèques d’accès aux fonctions systèmes, aux ressources, etc.

ldesnogu

Le 13/09/2012 à 15h02

Un choix d’autant plus intéressant (et ironique) que celui qui vante le x86 et ses instructions dédiées, nous explique donc que les applications doivent s’éloigner du code machine pour fonctionner partout de la même manière, même sur ARM.

Justement, le but n’est-il pas pour Intel que les app dev passent sur HTML5 pour rendre portable les app mobiles majoritairement sous ARM ?

Tout ca bien sur en proposant des outils specifiques a Intel comme River Trail.

Faut ptet que j’arrete de regarder X-Files, je me mulderise et en plus je pense avoir raison " />

methos1435

Le 13/09/2012 à 15h04

Dude76 a écrit :

Mmm. Pas d’accord avec cette théorie du complot.

C’est déjà le but de Java et de C#;

Les spécifications y sont ouvertes et accessibles;

Le problème, c’est la portabilité des bibliothèques d’accès aux fonctions systèmes, aux ressources, etc.

Ils pourront inventer autant de langages qu’ils veulent. Va imposer du java par exemple dans le store d’Apple ou le prochain de Microsoft avec Windows 8 …

On dira qu’il est possible de développer sans passer par le store mais ya qu’a voir comment ça se passe du coté de la pomme. Le store sur OS X cannibalise tout. Il est très difficile voir bientôt impossible de développer en dehors. Alors développer dans un langage pour se priver au final de la clientèle c’est pas terrible. Pire sur les iDevices qui ont pourtant la même base qu’OS X, c’est store obligatoire et les Frameworks qui vont avec.

Bejarid

Le 13/09/2012 à 15h04

lain a écrit :

à la base le html5 c’est pas censé être fait pour les page web ? j’ai du louper l’étape ou le html 5 passe du statue de language de site web a a language de programmation ^^”

C’est un langage parfait pour la programmation, la preuve, tout ceux qui n’ont aucun intérêt à ce qu’un quelconque langage multi-plateforme apparaisse le soutienne dur comme fer. " />

A vous de voir si c’est une supercherie faite pour couler toute véléité d’en faire un en montrant ce que ça peut donner, ou si c’est juste techniquement une aberration qu’aucun informaticien un minimum compétent (cf. qui comprend comment ça marche un logiciel, ce qui se passe une fois qu’il a fini d’écrire une ligne de code ; donc on exclu tous les développeurs qui bidouille jusqu’à ce que ça tombe en marche) ne saurait sérieusement envisager.

Je pense dans tous les cas qu’il est préférable de se faire un avis soit même en se renseignant plutôt qu’en répétant bêtement ce que certains, ayant leur propres intérêts bien sûr, annoncent. Mais rien n’empêche au final de répéter comme un idiot ceci dit, c’est une position qui rencontre un succès certain :p

ronfleur60

Le 13/09/2012 à 15h12

methos1435 a écrit :

Ils pourront inventer autant de langages qu’ils veulent. Va imposer du java par exemple dans le store d’Apple ou le prochain de Microsoft avec Windows 8 …

On dira qu’il est possible de développer sans passer par le store mais ya qu’a voir comment ça se passe du coté de la pomme. Le store sur OS X cannibalise tout. Il est très difficile voir bientôt impossible de développer en dehors. Alors développer dans un langage pour se priver au final de la clientèle c’est pas terrible. Pire sur les iDevices qui ont pourtant la même base qu’OS X, c’est store obligatoire et les Frameworks qui vont avec.

Ben, tu ne connais les applications hybrides ? Tu développe 80%, voire+, de ton application en html5+css+JS , tu mets ca dans un contener “natif” permettant de faire une app qui est publiable sur le store, le tout sur les plateformes que tu vises, c’est-t-y pas beau tout ca ?

Et si tu es embêté par des manques liés au html5, tu développes (ou tu fais développer) des plugin pour gérer la caméra, le gyroscope ou autre … pour fair ele lien avec ton appareil.

Phonegap, sencha touch … sont des solutions tout à fait mures à ce niveau là.

Tout ca est vrai dans le domaine d’appli de gestion par ex.

à méditer …

methos1435

Le 13/09/2012 à 15h19

ronfleur60 a écrit :

Ben, tu ne connais les applications hybrides ? Tu développe 80%, voire+, de ton application en html5+css+JS , tu mets ca dans un contener “natif” permettant de faire une app qui est publiable sur le store, le tout sur les plateformes que tu vises, c’est-t-y pas beau tout ca ?

Et si tu es embêté par des manques liés au html5, tu développes (ou tu fais développer) des plugin pour gérer la caméra, le gyroscope ou autre … pour fair ele lien avec ton appareil.

Phonegap, sencha touch … sont des solutions tout à fait mures à ce niveau là.

Tout ca est vrai dans le domaine d’appli de gestion par ex.

à méditer …

Ca revient à mon commentaire initiale: le HTML n’a pas été créé pour ça à la base. On cherche à le détourner pour combler les lacunes du système actuel (rien de réellement viable pour créer du multi plateforme).

brazomyna

Le 13/09/2012 à 15h37

methos1435 a écrit :

Ca revient à mon commentaire initiale: le HTML n’a pas été créé pour ça à la base. On cherche à le détourner pour combler les lacunes du système actuel

Le HTML, d’accord: vouloir faire des applications avec me semble aussi pertinent que vouloir faire un Super PI en flash.

Par contre le Javascript n’est rien d’autre qu’un langage, ce qui reste très générique. Et de par sa popularité, son accessibilité, l’investissement de plusieurs ‘gros’ dedans (google et son v8 en premier), et la productivité qu’il offre pour le développeur, c’est loin d’être une aberration.

Certes, ça reste un langage faiblement typé, et donc ça limite forcément les possibilités en matière d’optimisation des performances (et encore, on est parfois surpris de voir à quel point ça peut dépoter). Mais surtout l’association d’un framework natif bien conçu proposant un binding javascript au dessus peut donner des résultats absolument bluffant d’efficacité sans être pénalisé pour autant au niveau des perfs.

Au passage, Node.js n’est qu’un annonciateur de la tendance lourde qui se trame en sous-main amha.

(rien de réellement viable pour créer du multi plateforme)

Technologiquement parlant, ce n’est pourtant pas ce qu’il manque. tu as des pelletées de frameworks justement conçus pour ça, de Qt jusqu’aux moteux multi-plateforme WP / iOS / Android pour les smartphones.

Le vrai problème de l’interopérabilité, c’est plutôt l’émergence des stores affublés d’une vision ultra restrictives des libertés accordées aux développeurs. (au passage, on peut dire merci à Apple d’avoir ouvert la boite de Pandorre dans laquelle les autres se sont engouffrés puisque le client Michu était déjà ‘formaté’).

youtpout978

Le 13/09/2012 à 15h44

Le plus gênant c’est pas vraiment l’html qui correspond plutôt à la couche de présentation mais le JavaScript et bon à part voir des gens dirent ça à l’air génial html5 (surtout les non initié), peu le manipule vraiment (à part les dev de chez intel, google et consort pour faire de jolie démo), et bon le full html/css/js j’y crois pas trop ça sera surement moins efficace, réactif et simple à développer que du natif ou java/c#.

Vivement la fin du JS mais qui le remplacera donc ???

Gloorian

Le 13/09/2012 à 15h46

Vivement la fin du JS mais qui le remplacera donc ???

Et pourquoi ça ? Je trouve qu’à son application actuelle, javascript est un langage qui fonctionne bien. Je l’utilise même via node.js et il se porte comme un charme…

methos1435

Le 13/09/2012 à 15h50

brazomyna a écrit :

Technologiquement parlant, ce n’est pourtant pas ce qu’il manque. tu as des pelletées de frameworks justement conçus pour ça, de Qt jusqu’aux moteux multi-plateforme WP / iOS / Android pour les smartphones.

Le vrai problème de l’interopérabilité, c’est plutôt l’émergence des stores affublés d’une vision ultra restrictives des libertés accordées aux développeurs. (au passage, on peut dire merci à Apple d’avoir ouvert la boite de Pandorre dans laquelle les autres se sont engouffrés puisque le client Michu était déjà ‘formaté’).

Je suis d’accord mais au final ça revient au même résultat. Donc on utilise des technologies du web pour contourner cette restriction.

Je ne sais pas si c’est toujours d’actualité mais fût un temps sur iOS, les “applications” web qu’on accrochait directement sur le springboard depuis safari (donc sans passer par le store) n’avaient pas le droit à l’accélération matérielle, et un moteur javascript bridé.

methos1435

Le 13/09/2012 à 15h51

Gloorian a écrit :

Et pourquoi ça ? Je trouve qu’à son application actuelle, javascript est un langage qui fonctionne bien. Je l’utilise même via node.js et il se porte comme un charme…

Perso je trouve ça brouillon le javascripot. J’accroche pas, ou alors à petite dose. Je me vois pas développer du gros code avec.

Et puis de toute façon ça solutionne pas tout. Par exemple en ce moment je commence à développer une appli qui a besoin d’accéder à un scanner. Impossible avec javascript. Le langage ne fait pas tout. Si il n’existe aucune API pour faire le lien avec le matériel, ça ne change rien.

brazomyna

Le 13/09/2012 à 16h01

methos1435 a écrit :

Perso je trouve ça brouillon le javascripot. J’accroche pas, ou alors à petite dose. Je me vois pas développer du gros code avec.

Le javascript est une vraie super méga catastrophe pour un développeur débutant qui fera absolument n’importe quoi avec.

Le javascript est un délice pour qui a déjà pas mal de bouteille en développement car il t’offre une liberté de faire des choses très rapidement sans que ce soit méga verbeux pour un autre langage, typiquement quand il est fortement typé.

Le langage ne fait pas tout. Si il n’existe aucune API pour faire le lien avec le matériel, ça ne change rien.

C’est u nnon sens ce que tu dis: si tu fais du C ou du C++ sans un driver, tu as exactement la même problématique. La nature et les caractéristiques intrinsèques du langage n’entrent pas en ligne de compte pour savoir si tel langage est ‘vertueux’ ou pas.

methos1435

Le 13/09/2012 à 16h03

brazomyna a écrit :

C’est u nnon sens ce que tu dis: si tu fais du C ou du C++ sans un driver, tu as exactement la même problématique. La nature et les caractéristiques intrinsèques du langage n’entrent pas en ligne de compte pour savoir si tel langage est ‘vertueux’ ou pas.

Donc ceux qui voient dans le javascript LA solution pour du développement multi plateforme se plantent royalement. C’est ce que je dit. Ca sera peut être vrai pour afficher deux trois trucs, dès qu’on à besoin de toucher un peu au matos, quel que soit le langage utilisé, si il n’y a pas volonté de s’ouvrir et de faciliter le travail des dev, ca sera voué à l’échec.

brazomyna

Le 13/09/2012 à 16h12

methos1435 a écrit :

Ca sera peut être vrai pour afficher deux trois trucs, dès qu’on à besoin de toucher un peu au matos, quel que soit le langage utilisé, si il n’y a pas volonté de s’ouvrir et de faciliter le travail des dev, ca sera voué à l’échec.

Tu n’as visiblement pas compris de quoi on parle.

On ne parle pas de remplacer tous langages actuels par du JS dans tous les besoins. Le but n’est ici que d’avoir une solution pour les besoins les plus ‘high level’ (mais qui constituent quand même l’immense majorité des développements).

Ca ne fait que reprendre un principe éculé: avec différentes couches successives d’abstractions. De la même façon qu’openGL (a vocation à) t’abstrait le matos quand tu veux faire de la 3D, tu as des moyens de proposer des API au niveau du javascript avec une machinerie faite en C derrière (ou ce que tu veux d’autre).

Bien évidemment qu’on ne va pas faire des drivers en JS. " />

methos1435

Le 13/09/2012 à 16h19

brazomyna a écrit :

Tu n’as visiblement pas compris de quoi on parle.

On ne parle pas de remplacer tous langages actuels par du JS dans tous les besoins. Le but n’est ici que d’avoir une solution pour les besoins les plus ‘high level’ (mais qui constituent quand même l’immense majorité des développements).

Pour tout le reste, les langages actuels continueront d’être évidemment complémentaires pour ces besoins là (mais largement minoritaires)

Bien évidemment qu’on ne va pas faire des drivers en JS. " />

Si si j’ai bien compris. Mais on vois actuellement dans le couple HTML5 / Js THE SOLUTION pour coder une fois et éxecuter n’importe où (OS X, Windows, GNU/Linux, iPhone, android etc etc). C’est une solution à l’arrache pour un programme qui doit afficher deux trois trucs à l’écran voir, allez je suis gentil, être un jeu au niveau d’un jeu en flash.

Maintenant tu prend un logiciel (et pas un driver, où t’a lu driver dans mes commentaires ?) qui doit accéder à plus qu’à ta carte graphique, tu l’as dans l’OS pour faire du multi plateforme. C’est juste ce que je voulais dire. Ca peux calmer les dev pour certains types de soft, pas pour tous.

Au lieu de sortir des solutions qui, POUR MOI, sont en carton, ils feraient mieux de se mettre d’accord pour des frameworks multi-plateformes (Qt par exemple est très bien) et ne pas limiter leurs stores à certains langages/frameworks.

youtpout978

Le 13/09/2012 à 16h34

Gloorian a écrit :

Et pourquoi ça ? Je trouve qu’à son application actuelle, javascript est un langage qui fonctionne bien. Je l’utilise même via node.js et il se porte comme un charme…

le faite qu’il soit pas typé (après certain le préfère comme ça), que ça soit pas un langage objet (même si je crois que des frameworks permettent de faire ça), une vrai et bonne documentation, un débogueur efficace, heureusement les différents framework permettent d’en faciliter l’usage.

methos1435

Le 13/09/2012 à 16h38

Le jour où il feront ça, le langage utilisé ne sera plus un problème et certains ne seront plus tenté de faire sortir un langage de script du navigateur pour en faire un langage de programmation qui n’apportera, seul, rien de plus que ce qui existe actuellement. Bref, à mon avis actuellement, ils dépensent du temps et de l’argent mais pas sur le bon problème.

ldesnogu

Le 13/09/2012 à 16h45

methos1435 a écrit :

Bref, à mon avis actuellement, ils dépensent du temps et de l’argent mais pas sur le bon problème.

C’est quoi le bon probleme du coup, j’ai perdu le fil on dirait " /> C’est la portabilite et l’inter-operabilite ?

Gloorian

Le 13/09/2012 à 17h18

le faite qu’il soit pas typé (après certain le préfère comme ça), que ça soit pas un langage objet (même si je crois que des frameworks permettent de faire ça), une vrai et bonne documentation, un débogueur efficace, heureusement les différents framework permettent d’en faciliter l’usage.

Le fait qu’il soit pas typé, ça me gêne pas personnellement. Pour le côté objet, c’est hard mais faisable. Et créer un framework pour gérer ça plus simplement prend 30 minutes à faire. Pour ce qui est de la documentation, ben la MDN permet de couvrir l’usage de javascript, je ne vois pas le problème. Et enfin, les débuggers s’améliorent constamment (mon préféré est Dragonfly, web Inspector est pas mal. Et node en intègre un pour le out of browser).

lossendae

Le 13/09/2012 à 17h26

youtpout978 a écrit :

le faite qu’il soit pas typé (après certain le préfère comme ça), que ça soit pas un langage objet (même si je crois que des frameworks permettent de faire ça), une vrai et bonne documentation, un débogueur efficace, heureusement les différents framework permettent d’en faciliter l’usage.

" />

brazomyna

Le 13/09/2012 à 18h11

youtpout978 a écrit :

le faite qu’il soit pas typé (après certain le préfère comme ça)

C’est pas une question de ‘préférence’, mais ça induit l’impossibilité d’optimiser le code machine autant que dans un langage fortement typé. Donc un langage comme JS ne pourra JAMAIS être aussi ‘optimisable’ qu’un Java ou un C++ par exemple. L’autre aspect c’est que ça donne énormément de liberté. Et ça c’est à double tranchant: c’est le risque qu’un développeur qui n’est pas carré fasse n’importe quoi, mais pour celui qui a de la bouteille (et qui est notamment passé par les langages fortement typés ci-avant), c’est juste un bonheur et une productivité incomparables.

que ça soit pas un langage objet (même si je crois que des frameworks permettent de faire ça)

C’est exactement le contraire: c’est bien plus un langage objet qu’un C++ étant donné que TOUT est objet, même les fonctions, les prototypes, …

une vrai et bonne documentation

C’est un langage, il y a une syntaxe. Je vois pas où tu veux de la documentation. Si tu parles des libs tierces, tu confonds le langage JS et l’écosystème dans lequel il évolue la plupart du temps, à savoir dans un navigateur (DOM et cie). Dans ce cas là, jette un oeil à Node.js pour comprendre la différence (JS d’un côté, libs et API tierces de l’autre).

un débogueur efficace, heureusement les différents framework permettent d’en faciliter l’usage.

Idem, le JS est plus souple et offre plus de potentiel pour le déboguage, avec des choses évaluables à la volée, de l’injection de code, de la réflectivité, etc…

En JS, avec une simple boucle de 10 lignes, tu peux encapsuler d’un coup d’un seul en runtime l’ensemble des méthodes d’un classe pour logger chaque appel/résultat par exemple. Va faire ça en C++.

zozolebo

Le 13/09/2012 à 19h27

Un choix d’autant plus intéressant (et ironique) que celui qui vante le x86 et ses instructions dédiées, nous explique donc que les applications doivent s’éloigner du code machine pour fonctionner partout de la même manière, même sur ARM.

Ca fait pourtant tellement longtemps que les développeurs d’assembleur disent que les OPCODES x86 sont d’une absurdité incroyable… Ca serait un bon début si les fondeurs pouvaient se mettre d’accord sur un standard, au moins pour les instructions non optionnelles. Ca permettrait d’avoir des programmes compilés portables sur toutes les machines sans avoir besoin de les recompiler.

C’est beau de rêver…

liukahr

Le 13/09/2012 à 20h50

Je ne suis pas sur d’avoir bien compris la tirade sur le go de Google à la fin.

Go comme alternative au Javascript ? Vraiment ?

youtpout978

Le 13/09/2012 à 21h04

Merci pour le mdn je ne savais pas qu’on y trouvait une doc complète.

Dans le sens ce n’est pas un langage objet c’est la création de classe, d’interface la possibilité de faire de l’héritage ….

Je fais de l’asp.net le côté c# ne me pose pas de problème mais dès que certaine opération nécessite l’utilisation exclusive du JS " />

Si demain on me demande de faire des application full Html5/Css/JS " />

Foudge

Le 13/09/2012 à 21h06

ldesnogu a écrit :

Justement, le but n’est-il pas pour Intel que les app dev passent sur HTML5 pour rendre portable les app mobiles majoritairement sous ARM ?

Tout ca bien sur en proposant des outils specifiques a Intel comme River Trail.

Faut ptet que j’arrete de regarder X-Files, je me mulderise et en plus je pense avoir raison " />

J’allais justement faire la remarque. Il me parait évident qu’Intel pousse au HTML5 pour cette unique raison !

Ce qui va gêner l’invasion de ses puces x86 dans le monde de l’ultra-mobile, ce ne sont pas le manque de qualité de leur puces x86, mais bien le fait qu’ils débarquent dans un écosystème 100% ARM. Le seul moyen est donc de pousser à utiliser une solution pouvant tourner sur toute les plateformes (sous-entendu “y compris x86 !”).

Bonne chance Intel, ça ne va pas être simple " />

levhieu

Le 14/09/2012 à 07h14

Foudge a écrit :

J’allais justement faire la remarque. Il me parait évident qu’Intel pousse au HTML5 pour cette unique raison !

Ce qui va gêner l’invasion de ses puces x86 dans le monde de l’ultra-mobile, ce ne sont pas le manque de qualité de leur puces x86, mais bien le fait qu’ils débarquent dans un écosystème 100% ARM. Le seul moyen est donc de pousser à utiliser une solution pouvant tourner sur toute les plateformes (sous-entendu “y compris x86 !”).

Bonne chance Intel, ça ne va pas être simple " />

Et l’émulateur ARM sur l’androphone x86, il marche bien ou pas ?

ldesnogu

Le 14/09/2012 à 07h36

levhieu a écrit :

Et l’émulateur ARM sur l’androphone x86, il marche bien ou pas ?

J’avoue que j’aimerais bien savoir, enfin tester moi-même je veux dire. J’ai quand même lu à droite et à gauche que certaines apps ne fonctionnaient pas du tout, et d’autres étaient trop lentes. Et bien entendu beaucoup marcheraient bien.

De toute façon techniquement y’a pas de miracle possible : si une app dépend fortement du CPU, hors librairie de l’OS, l’émulateur aura de gros soucis de performance. La question est combien de telles applis existent ? :)

brazomyna

Le 14/09/2012 à 07h48

ldesnogu a écrit :

si une app dépend fortement du CPU, hors librairie de l’OS, l’émulateur aura de gros soucis de performance

Ou pas si le CPU hôte est largement plus puissant que celui qu’il émule.

Emuler une SNES n’est pas un problème pour un Core i7. Emuler une PS3 un peu plus.

ldesnogu

Le 14/09/2012 à 07h50

brazomyna a écrit :

Ou pas si le CPU hôte est largement plus puissant que celui qu’il émule.

Emuler une SNES n’est pas un problème pour un Core i7. Emuler une PS3 un peu plus.

On parle de téléphone. Medfield n’étant pas plus performant que ce qu’il veut émuler, ça ne peut pas bien fonctionner s’il y a trop de code natif.

anonyme_5308cee4763677866e1421efa4474f79

Le 14/09/2012 à 10h45

youtpout978 a écrit :

le faite qu’il soit pas typé (après certain le préfère comme ça), que ça soit pas un langage objet (même si je crois que des frameworks permettent de faire ça), une vrai et bonne documentation, un débogueur efficace, heureusement les différents framework permettent d’en faciliter l’usage.

Toi t’as pas vu les spécs de ECMAScript 6 qui va arriver " />

http://www.synbioz.com/blog/2012/08/29/ecmascript_6

levhieu

Le 14/09/2012 à 17h26

ldesnogu a écrit :

si une app dépend fortement du CPU, hors librairie de l’OS, l’émulateur aura de gros soucis de performance

brazomyna a écrit :

Ou pas si le CPU hôte est largement plus puissant que celui qu’il émule.

Emuler une SNES n’est pas un problème pour un Core i7. Emuler une PS3 un peu plus.

ldesnogu a écrit :

On parle de téléphone. Medfield n’étant pas plus performant que ce qu’il veut émuler, ça ne peut pas bien fonctionner s’il y a trop de code natif.

Mais c’est quand même plus facile d’émuler de l’ARM que du x86:

Pas besoin de se taper d’abord un décodage des prefixes

Moins de variantes de modes d’adressage.

ldesnogu

Le 14/09/2012 à 17h46

levhieu a écrit :

Mais c’est quand même plus facile d’émuler de l’ARM que du x86:

Pas besoin de se taper d’abord un décodage des prefixes

Moins de variantes de modes d’adressage.

Tout ca est parfaitement trivial. En plus sur un JIT tu payes le cout une seule fois.

Enfin bref, au mieux t’as un facteur 2 de ralentissement, mais vraiment au mieux. Donc si c’est lourd en CPU, Medfield n’y arrivera pas.