Avertissement habituel: Mozilla est mon employeur, je suis biaisé. Ceci dit, ce que j'écris ici ne reflète que mes opinions personnelles.
Un nouveau front s'est ouvert dans «guerre du Web»: le jeu vidéo. Ce journal va tenter d'expliquer ce que Mozilla est en train d'y faire, et pourquoi c'est important.
Par "jeux du Web ouvert" je veux dire des jeux vidéo n'utilisant que des standards du Web ouvert tels JavaScript, HTML, les Canvas 2D et WebGL, WebAudio et autres technologies ouvertes, sans utilisation de plugins binaires tels que Flash.
Pour un développeur de navigateurs, s'intéresser au jeu vidéo peut sembler étrange. C'est une chose récente pour Mozilla. Il y a seulement deux ans, on n'avait pas vraiment d'organisation rationelle sur ce sujet. On se contentait d'assister passivement à l'émergence très lente des premiers jeux du Web ouvert, qui commençaient péniblement à faire un peu de concurrence aux jeux Flash alors omniprésents.
Et puis on s'est réveillés, je dirais en sursaut, vers la fin 2011, quand on s'est rendu compte de ce qui était sur le point de se passer:
1. Si le Web ouvert n'est pas prêt à temps, les jeux utiliseront alors des technologies propriétaires. C'est ce qui s'est passé avec Flash lors de la «première manche» il y a quelques années (Farmville…), à nous de ne pas rater la «deuxième manche».
2. Lorsque (et si) les jeux du Web ouvert émergeront, les navigateurs qui seront prêts à les exécuter en tireront un grand avantage compétitif sur ceux qui ne le seront pas.
3. Les jeux vidéo sont généralement des applications très exigentes en matière de performances et de fonctionnalités. Un navigateur qui sait les exécuter dans de bonnes conditions sera prêt à exécuter la plupart des autres applications. C'est un très bon test pour un navigateur.
Alors, qu'est-ce qu'on fait à Mozilla quand on se rend compte qu'il est temps de s'organiser? On crée une page de wiki, bien sûr! Cette page n'est plus à jour depuis longtemps, mais pendant les 6 premiers mois de cet effort (fin 2011, début 2012), elle a été notre principal outil. On y a recensé tous les aspects à prendre en compte pour le jeu vidéo: des performances JS à WebGL au stockage local de gros fichiers… Selon les domaines, il y avait besoin soit d'améliorer le navigateur, soit même d'ajouter des APIs manquantes au Web pour offrir aux jeu vidéo un environnement d'exécution complet. Par exemple, à l'époque, il n'y avait pas d'API Web pour accéder aux manettes de jeu ni pour accéder à la souris en mode verrouillé. Par chance, Google travaillait sur les mêmes problèmes au même moment, ce qui a permis de partager l'effort.
Deux problèmes se posaient cependant, qui allaient nous causer beaucoup de souci:
1. Les développeurs de jeux vidéo ont déjà écrit des millions de lignes de code, le plus souvent en C++. Les autres plateformes de jeu leur permettent d'utiliser leur code existant. Le Web leur demandait de tout réécrire en JavaScript. Comment leur faciliter la tâche?
2. Le JavaScript, même après des années d'améliorations des performances, n'arrivait toujours pas à dépasser environ 10% de la vitesse du code natif dans des applications réelles.
Pendant ce temps, Google réfléchissait aux mêmes problèmes, et mettait au point une solution qui devait les résoudre tous les deux: Native Client. Native Client consiste à distribuer du code machine à la place du JavaScript, mais ce code machine est un peu restreint, est préalablement vérifié statiquement, et est exécuté dans un environnement contrôlé, avec des entrées-sorties limitées, pour offrir un bon niveau de sécurité. On peut dire qu'avec Native Client, Google a résolu les problèmes de sécurité des plugins binaires. Le but de Native Client est de résoudre les deux problèmes mentionnés plus haut: facilité de porter le code C/C++ existant car il suffit de recompiler, et performances proches du code "natif".
Cependant, Native Client n'est pas une solution que Mozilla pouvait adopter, et ceci pour deux raisons:
1. Le code Native Client est du code machine spécifique à une architecture de CPU. Il n'y a donc pas de portabilité à ce niveau-là. Un jeu Native Client pour x86 ne peut pas tourner sur une machine ARM, sauf à le faire tourner dans un émulateur x86… Réciproquement, une application Native Client ARM ne tourne pas sur x86. Or à Mozilla on n'est pas prêts à renoncer à la portabilité du Web.
2. Le code Native Client ne peut en gros faire d'entrées-sorties que par un ensemble d'APIs spécifiques, dites Pepper. Il y a certes la possibilité théorique d'utiliser les bonnes vieilles APIs DOM du Web, mais tout un ensemble de raisons fait que ce n'est pas ce que font les applications Native Client dans la pratique (c'est lent et ce n'est pas fait pour ça). Il est donc clair que supporter Native Client n'a pas de sens si l'on ne supporte pas les APIs Pepper. Or, contrairement aux APIs DOM du Web, les APIs Pepper ne sont pas le fruit d'un processus ouvert entre les différents développeurs de navigateurs. Ce sont des APIs décidées par Google seul, visant à offrir une interface à des composants spécifiques de Chromium. Par exemple, pour le graphisme de bas niveau, alors que le Web ouvert propose WebGL, Pepper propose d'utiliser directement l'OpenGL ES 2.0 implémenté par Chromium. La différence est que dans le cas de WebGL, l'éventail de fonctionnalités (et donc le compromis entre fonctionnalités et portabilité) est décidé conjointement par les différents fabricants de navigateurs, alors que dans le cas de Pepper, on a un compromis différent, décidé par Google seul. Il serait futile de croire que cela pourrait changer si d'autres fabricants de navigateurs rejoignaient Pepper maintenant, alors que des centaines d'applications Native Client sont déjà commercialisées dans le Chrome Web Store.
En résumé, Mozilla avait du souci à se faire: alors que les problèmes du JavaScript semblaient difficiles à résoudre, Google avait une solution à ces problèmes en route, et Mozilla ne pourrait pas adopter la solution de Google sans renoncer à la fois à ses principes (portabilité multi-architecture du Web) et à son influence (APIs Pepper déjà décidées par Google venant remplacer les standards ouverts existants).
La clé de la solution finalement retenue a été un projet jusque-là maintenu par un chercheur de Mozilla: j'ai nommé Emscripten. Emscripten est un compilateur basé sur LLVM qui émet du JavaScript. Tout code C/C++ peut ainsi être traduit en JavaScript. Il existait déjà des démos intéressantes de ce que ça permettait, telles qu'un portage de Doom en JavaScript utilisant un Canvas 2D pour l'affichage.
Est-ce qu'Emscripten pourrait évoluer assez vite pour offrir une vraie solution pour porter des jeux vidéo récents avec un bon niveau de performances? On pensait que oui, mais ça restait à prouver, afin que l'industrie du jeu vidéo nous prenne au sérieux.
Ainsi on a pris un jeu libre en 3D, Sauerbraten. Il s'agit d'un jeu de tir à la Quake, écrit en C++ avec OpenGL, et des graphismes assez avancés, comparable à ce qui se faisait de mieux il y a environ 10 ans. Qu'est-ce qui allait se passer si on demandait à Emscripten de le traduire en JavaScript? La réponse est que bien que la traduction du code C++ en JS fonctionne à merveille, les entrées-sorties utilisant des APIs natives ne sont pas triviales à traduire en termes d'APIs Web. Par exemple, le code utilise des appels à OpenGL, incluant des vieux appels OpenGL 1, qui n'ont pas d'équivalent direct en WebGL. Très vite on s'est fixés une règle: pour porter un jeu vidéo au Web, on doit autant que possible étendre les capacités d'Emscripten pour faire le portage automatiquement, plutôt que de faire du portage manuel. Ainsi chaque portage de jeu conduit à améliorer Emscripten pour en faire un outil complet. C'est pourquoi nous avons étendu les capacités d'Emscripten pour traduire automatiquement les appels OpenGL en appels WebGL, même les vieux appels OpenGL 1. De même les entrées-sorties réseau sont traduites en WebRTC pour permettre le jeu multi-joueur.
Le résultat est ici, et répond au doux nom de BananaBread («gâteau banane»). Une fois le jeu lancé, appuyer sur la touche en-dessous de Echap pour afficher le menu. Tout marche assez vite, même avec plusieurs bots et adversaires humains en réseau par WebRTC.
Ce qui est unique avec cette démo, c'est que le jeu lui-même est libre, et donc ce projet a pu être ouvert dès le premier jour. Bien sûr tout le code écrit par Mozilla est libre, mais il est plus rare de pouvoir travailler sur un jeu vidéo libre.
Une fois BananaBread prêt, les gros acteurs du monde du jeu vidéo ont commencé à nous prendre bien plus au sérieux que par le passé. On avait désormais une vraie solution à leur proposer pour porter leurs jeux au Web, et une vraie démo montrant que les performances étaient correctes.
Pourtant, les performances correctes ne dépassaient toujours pas 10% de la vitesse du code natif. On n'avait toujours pas résolu ce problème. Ça n'était pas rédhibitoire pour de nombreux jeux, car grâce à WebGL la partie graphique s'exécutait déjà très près de la vitesse du code natif, mais pour le reste (physique, intelligence artificielle…) les jeux Web avait encore un grand handicap à surmonter. On n'avait toujours pas résolu le problème que JavaScript était un langage fondamentalement lent, parce que difficile pour le compilateur à optimiser. Pendant ce temps, Native Client proposait déjà des performances proches du code natif.
Et c'est là qu'un autre ingénieur de Mozilla a eu une idée simplement géniale, qui a changé la donne presque instantanément. Il s'est dit que si JavaScript était difficile à optimiser, c'était parce que ce langage offrait trop de fonctionnalités, et que l'on pourrait simplement définir un sous-ensemble de JavaScript qui ait moins de fonctionnalités mais qui soit bien plus facile à compiler en code efficace. Le résultat est une spécification, publique dès le début, d'un tel sous-ensemble de JavaScript et de la façon dont un compilateur JS peut l'optimiser: c'est le projet asm.js.
La beauté de la chose est que comme il s'agit d'un sous-ensemble de JavaScript, du tel code va être exécutable par n'importe quel navigateur moderne. En plus, comme ce code est de façon inhérente mieux optimisable que du JS «ordinaire», il s'exécute généralement plus vite que du JS ordinaire dans tous les navigateurs. Mais bien entendu, dans un navigateur spécialement prévu pour optimiser ce type de code, les niveaux de performance sont encore plus élevés, et les premiers tests, après seulement quelques semaines de travail, atteignaient déjà plus de 50% de la vitesse du code natif! Et comme ce n'est que du JavaScript, nul besoin d'inventer un nouvel environnement d'entrées-sorties tel que Pepper. Le code asm.js utilise les mêmes APIs DOM que n'importe quel code JavaScript.
Pour en apprendre plus sur asm.js, je recommande la lecture de ce journal de Clochix.
Emscripten a vite gagné une option pour générer du code asm.js, permettant à du code C++ d'être traduit en JS en conservant cette fois-ci plus de 50% de ses performances natives dans tout navigateur reconnaissant asm.js, tout en continuant de tourner dans d'importe quel navigateur.
À peu près au même moment, Mozilla avait pris contact avec Epic Games, les développeurs du fameux moteur Unreal Engine. Grâce à la démo BananaBread, ils nous avaient pris juste assez au sérieux pour accepter qu'une petite équipe d'ingénieurs de Mozilla vienne passer une semaine chez eux pour essayer de porter Unreal Engine 3 au Web ouvert. Ils ne pensaient pas vraiment que ça pourrait marcher d'ici quelques années, mais ils trouvaient que ça serait intéressant de voir ce qu'on pourrait déjà faire.
Grâce à tout le travail déjà effectué sur Emscripten au cours des portages précédents, le portage de Unreal Engine 3 était achevé en seulement 4 jours. Utilisant asm.js, les démos de Unreal Engine 3 tournaient à 50-60 images par seconde dans Firefox sur une machine raisonnable. Epic Games était désormais enthousiaste à l'idée que les jeux utilisant son moteur pourraient tourner sans plugins dans n'importe quel navigateur moderne. Ils nous ont alors proposé d'aller présenter ça ensemble au Games Developers Conference: c'était à San Francisco la semaine dernière.
L'effet de cette annonce sur l'industrie a été énorme. Le même jour, un ingénieur de Chrome (et le chef du groupe de travail WebGL à Khronos) a enregistré un ticket pour V8 demandant à ajouter les optimisations asm.js. Bien qu'il soit encore tôt et que Google n'ait pas communiqué sur ce sujet, je pense que la raison d'être de Native Client s'est évaporée depuis qu'il est établi qu'on peut en faire autant en JavaScript. Par ailleurs, les présentateurs d'autres technologies concurrentes au GDC (tel Adobe promouvant encore Flash) ont dû modifier à la dernière minute leurs exposés pour tenir compte de la nouvelle donne (il faut saluer au passage l'exposé très honnête d'Adobe sur les différentes technologies permettant de faire des jeux Web à l'heure actuelle). Et, coïncidence ou pas, des rumeurs de plus en plus persistantes affirment que Microsoft va enfin supporter WebGL dans IE11.
# Et pour quelques liens de plus...
Posté par Benoit Jacob (site web personnel) . Évalué à 10.
Quelques liens que j'aurais dû mettre:
- le blog de Clochix, en fait plus complet que son journal que j'ai lié ci-dessus
- un article dans la presse relatant Unreal Engine 3 tournant dans le navigateur
J'ai aussi oublié de préciser que la démo Unreal Engine 3 devrait être publiée par Epic sous quelques semaines. D'ici-là malheureusement il faut se contenter de regarder la vidéo… ou bien il fallait venir au GDC la semaine dernière ;-)
[^] # Re: Et pour quelques liens de plus...
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Est-ce que vous allez ajouter les api qui utilisent du code SIMD ou multicpu dans Emscripten ?
"La première sécurité est la liberté"
[^] # Re: Et pour quelques liens de plus...
Posté par Benoit Jacob (site web personnel) . Évalué à 3.
C'est la question à un million de dollars. Je l'ai posée la semaine dernière aux spécialistes, ils pensent que quelque chose dans ce goût-là va se passer probablement plus tard cette année, mais ils ont quelques problèmes à régler au préalable.
[^] # Re: Et pour quelques liens de plus...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Cela revient au support du SIMD de gcc et de openMP j'imagine.
"La première sécurité est la liberté"
[^] # Re: Et pour quelques liens de plus...
Posté par Benoit Jacob (site web personnel) . Évalué à 3.
En fait je parlais uniquement de SIMD. Cela va revenir au support d'«intrinsics» similaire à ce que les compilos comme GCC supportent pour SSE/Neon. Les difficultés à surmonter vont être de trouver des «intrinsics» portables et efficaces à la fois (pas question de faire des intrinsics spécifiques à SSE par exemple) et de trouver la bonne façon de représenter un __m128 et autres types de paquets.
Pour le parallélisme (je n'avais pas vu cette partie de ton commentaire) plusieurs pistes sont en train d'être explorées. Gecko contient une implémentation expérimentale de RiverTrail. Une autre approche est simplement d'exposer une API du type pthreads: c'est moche, mais c'est 99% du parallélisme dans le monde réel. Il y a déjà les Web Workers mais ils sont dépourvus de mémoire partagée (ce qui est aussi leur beauté). Enfin une autre approche est WebCL, mais il est peu probable que les fabriquants de navigateurs l'adoptent massivement à court terme.
[^] # Re: Et pour quelques liens de plus...
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Tu parles d'intrasec javascript ? Je croyais qu'il était question de créer une lib javascript utilisant des tableaux pour faire des calculs dessus avec des instructions SIMD.
Gcc supporte les intrasec SSE, mais il est possible de faire du code SIMD portable en déclarant des nombres groupés:
"API du type pthreads: c'est moche, mais c'est 99% du parallélisme dans le monde réel."
Je croyais que openMP devenait très courant. C'est quand même plus propre que pthread.
"Enfin une autre approche est WebCL, mais il est peu probable que les fabriquants de navigateurs l'adoptent massivement à court terme."
J'imagine que cela n'existe pas encore dans les codes de jeu actuels. Mais si c'est bien un port de openCL pour le web, c'est quand même le meilleur moyen d'exposer une puissance de calcul parallèle complexe et changeante, à base de multicpu, SIMD + GPU.
"La première sécurité est la liberté"
[^] # Re: Et pour quelques liens de plus...
Posté par Benoit Jacob (site web personnel) . Évalué à 2.
On verra quelle forme ça prend, mais oui je pense que le plus probable est que ça soit des constructions JS interprétables comme des intrinsics. Après, je ne fais que spéculer, ce n'est pas moi le spécialiste.
Je ne suis pas très au courant des derniers développements. Mais on ne peut pas nier que pthreads (ou APIs de threads similaires) est de loin la façon la plus répandue de faire du multithreads en-dehors du monde scientifique.
Je ne sais pas trop. OpenGL 4.3 et ses «compute shaders» risque de faire pas mal d'ombre à OpenCL. Et quand on voit que ce n'est que maintenant en 2013 avec Unreal Engine 4 que ce genre de choses commence à être réellement utilisé dans les jeux… je ne suis pas convaincu que WebGL, avec ses bons 5 ans (voire 10 ans) de retard sur OpenGL, en ait besoin à court terme i.e. on a d'autres problèmes plus urgents.
[^] # Re: Et pour quelques liens de plus...
Posté par Gof (site web personnel) . Évalué à 6.
Pour le SIMD, Clang est capable de comprendre les intrinsics de GCC, et LLVM est aussi capable de vectoriser le code.
Emscripten doit alors trouver un moyen de transformer le bytecode LLVM en javascript.
J'imagine que pour le moment il doit dé-vectoriser. (ou ne pas passer les flags de vectorisation à LLVM)
Mais il serait peut-être possible pour asm.js de re-vectoriser le code JS dé-vectorisé.
(Javascript n'a pas de type vectoriel, mais asm.js pourait détecter que huit entiers côte à côte forment en fait un vecteur)
Pour le multi-thread ça me parait bien plus compliqué puisque javascript est simple thread. (Les web worker n'ont pas de mémoire partagée je pense)
# Pas convaincu
Posté par devnewton 🍺 (site web personnel) . Évalué à 10.
Mettre les jeux "sur le web" pose pas mal de problèmes:
Alors oui, les jeux natifs peuvent aussi être lents, buggés, bourrés de pubs ingame et demander une connexion permanente.
Mais j'ai l'intuition que le web va augmenter fortement la tentation des studios à suivre Voie Du Mal.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas convaincu
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
Les navigateurs peuvent aussi proposer de bon plugin pour éviter tous ce tracking : RequestPolicy, Ghostery,… Ce qui n'est pas aussi simple en natif.
"La première sécurité est la liberté"
[^] # Re: Pas convaincu
Posté par tuxicoman (site web personnel) . Évalué à 4.
Ce n'est basé que sur des listes noires de service de tracking très connus. Un peu comme un antivirus. Et bien je ne donne pas cher de ta machine si tu lui laisses exécuter n'importe quel script perso sous prétexte que tu as le dernier Norton.
[^] # Re: Pas convaincu
Posté par claudex . Évalué à 4.
Pour adblock, c'est le cas, mais il y a plusieurs addons qui permettent par défaut de n'exécuter des scripts qu'à la demande ou sur liste blanche.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas convaincu
Posté par tuxicoman (site web personnel) . Évalué à 3. Dernière modification le 04 avril 2013 à 00:37.
Adblock, ghostery, etc…
Dans le sujet du jeu qui s'exécute sur ta machine, si tu ne mets pas les communications du jeu dans la liste blanche ca risque fortement de ne pas fonctionner.
Le jeu, voila un consentement à accepter la pub bien appréciable pour les annonceurs vu qu'on ne reste plus devant la TV ni la radio, voila leur créneau pour toucher la nouvelle génération.
[^] # Re: Pas convaincu
Posté par freem . Évalué à 3.
Euh…. les firewall sont 1000 fois plus efficaces que n'importe laquelle de ces trucs basés sur des listes…
Sinon, pour MS windows, il existe des outils capables d'empêcher des programmes d'accéder à des fonctions spécifiques (enfin, je n'ai connu qu'un, dont je n'arrive pas à me souvenir du nom, mais au moins ça me permet de savoir que ça existe. Ce superbe outil se disais firewall, mais au final faisait plus que faire la circulation sur mon réseau, et ça m'allais très bien.). En gros, dès lors qu'une appli tentait d'accéder à une fonctionnalité du système (registre, disque dur, systray, chargement de DLL systèmes… je n'exagère pas, je ne fait que décrire assez mal ce dont je me souviens) l'outil nous prévenais si on avait pas encore défini de règle pour cette application et cette action.
Je sais pas si ça existe sous linux, cela dis.
En tout cas, de tout faire dans les navigateurs, avec le peu de contrôle qu'ils nous offrent sur ce qu'ils font réellement, est vraiment un problème pire que les applications natives. Avec les browser, c'est tout ou rien. La possibilité qu'on a de pouvoir filtrer à l'action ne crée bien souvent pas des listes d'actions autorisées, et ça rend donc le navigateur complètement inutilisable.
[^] # Re: Pas convaincu
Posté par barmic . Évalué à 2.
Ça dépend de ce dont tu parle. En performance oui. Quand il s'agit d'accepter ou non une connexion en fonction du destinataire, tu as de toute manière besoin d'une liste et cette liste se doit d'être dynamique dans le sens ou c'est l'utilisateur qui accepte ou non la connexion (il peut même changer d'avis). Donc il va falloir que tu trouve un outil (ou que tu le code) pour pouvoir ramener ça au niveau utilisateur (ne parlons pas de permettre ça en multi-utilisateur ça commencera à devenir compliqué). En plus l'utilisateur aimerait probablement bien savoir pourquoi tel ou tel truc ne s'affiche pas ça demande donc d'utiliser un hook pour reporter à l'utilisateur qu'une règle a matchée. Bref au niveau firewall, ça n'a rien de très pratique ni de très flexible. Tu gagnera bien plus à utiliser soit les fonctionnalités de ton navigateur soit un proxy http qui fait ce que tu lui demande (et qui est capable d'aller inspecter le contenu si tu en a besoin). S'il ne s'agit que d'interdire les connexions vers une liste de serveur, généralement on gère ça au niveau de la résolution de nom comme ça c'est bloqué encore plus tôt dans le scénario.
Je ne vois pas l'intérêt d'un firewall pour tout ça.
À moins bien sûr que tu imagine un protocole spécifique aux pub qu'il suffirait de bloquer, mais ça c'est du fantasme autant interdire les pub.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas convaincu
Posté par zul (site web personnel) . Évalué à 3.
Tous les firewalls peuvent faire plus ou moins de l'inspection de paquet aussi (cf les hacks ftp par exemple)., je ne vois pas particulièrement l’intérêt de passer par un proxy http. Y'a même des choses en dehors de http dans la vie.
Quand aux autres problématiques que tu évoqués, le Michu moyen (ne soyons pas sexiste), il n'y comprend de toute façon rien, donc soit réponds oui à tout, soit désactive juste tout.
Pour les fonctionnalités du navigateur, elles font surtout doublon avec un tas de trucs qui existent déjà dans ton système d'exploitation. Mais bon, un navigateur c'est moderne, c'est cool et au diable l'esprit unix !!!
[^] # Re: Pas convaincu
Posté par barmic . Évalué à 4.
Respire profondément.
Tu parle du hack fait pour gérer le FTP passif qu'il faut activer manuellement. Tu en connais d'autres ? (mis à part « yakafocon ») C'est une vrai question.
Au final ça t'apporte quoi ? PolicyRequest te permet de bloquer ça au plus tôt avec une finesse bien plus importante (bloquer les accès à google.com depuis linuxfr mais pas depuis autre.fr).
Cool ! C'est quoi l'alternative ? Chaque jeu développe son protocole qui est chiffré par SSL (ou truc plus exotique) et qui inclus les pub au sein même de son flux normal ? Tu as quoi pour te protéger d'un skype (tout en t'en servant) ?
Quand des alternatives existent (par exemple pour les mails) c'est agréable, mais pour le reste qui propose quoi ? (gopher peut être ?)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas convaincu
Posté par zul (site web personnel) . Évalué à 2.
find /lib/modules// -name "*conntrack*"
mais oui, évidémment, ça le fait au niveau système. Pour le faire au niveau process, on peut utiliser les solutions évoqués plus haut pour refuser le connect selon des listes banches | noires. Évidemment, quand il y'a k "processus" dans un processus, bah on est obligé de le faire au niveau dudit processus et de tout réiventer. Mais bon, d'après moi, c'est déjà une "erreur de design" à la base qu'une application gére ses "tabs" en interne (uzbl, uzbl … :)). C'est au noyal de gérer les différents processus, et au wm de gérer les différentes fenêtres.
Parce qu'il ne va pas se passer exactement la même chose, sauf qu'au lieu d'être encapsulé dans un paquet tcp, il sera encapsulé dans un paquet http (ce qui est déjà la technique générique pour essayer de bypasser les firewalls).
[^] # Re: Pas convaincu
Posté par barmic . Évalué à 2.
Oui ça permet d'avoir des hooks pour accepter ou refuser les connexion en espace utilisateur. C'est ce que je disais plus haut, tu as un bon gros temps de dev pour pouvoir te servir de ça et au final, tu sera content de faire plus de chose au niveau noyau, mais tu aura moins de fonctionnalité (refuser les connexions vers le domaine exemple.com à moins que tu ne visite explicitement exemple.com, ça peut peut être se faire si tu analyse les entêtes http, mais bon en ayant une vision de plus haut niveau tu le fait de manière bien plus simple et performante.
Je ne vois pas le rapport, à moins que tu cherche à avoir un filtrage basé sur les PID (ce qui n'est pas une bonne idée).
Ça se discute. Tu perds pas mal en retirant ça du navigateur notamment pour la gestion des sessions au niveau du navigateur (oui le DE peut aussi s'en occuper, mais c'est avec une granularité bien moins fine -néanmoins il paraît que KDE est pas mal là dessus).
D'autre part c'est assez rare les WM qui gèrent ça correctement. Par exemple metacity, kwin, openbox, wmii, dwm et awesome ne le font pas. Il semble par contre que i3 et xmonad si.
uzbl ? Ce truc est incroyablement lent ! Il a l'air de suffoquer à chaque fois que tu lui demande quelque chose. Je préfère de loin utiliser luakit.
Ne crois pas que je suis contre ce genre d'idées, au contraire moi aussi j'ai étais sectaire pendant un temps et puis j'ai fais fasse à la réalité. Je ne dis pas que c'est impossible d'avoir des découpages comme il faut etc. Je dis juste que dans notre monde l'existant l'empêche et on a pas les outils pour faire autrement (ou alors ils manquent de visibilité/maturité).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas convaincu
Posté par freem . Évalué à 2.
C'est vrai que la lenteur de ce truc est impressionnante. Peut-être due au fait qu'il ne soit pas encore stable, et que donc l'accent soit encore a l'ajout de fonctionnalités, et pas à l'optimisation?
Par contre, sa légèreté aussi, c'est pour ça que cet outil est un lecteur de doc locale potable. (idem, du au fait de pas encore être stable?)
Je l'aime bien, mais pas assez pour le juger utilisable en conditions réelles quoi.
Par contre, je connaissais pas luakit. Vais aller y jeter un oeil, si ça peut être plus performant, je risque d'adopter (a condition que la config de base soit pas trop merdique, naturellement). En plus il semble avoir grosso modo les mêmes motivations?
[^] # Re: Pas convaincu
Posté par barmic . Évalué à 2.
Démarrer un interpréteur (perl, python ou sh par exemple) pour gérer l'historique ne doit pas aider.
Je sais pas trop, en tout cas il réussi là où uzbl échoue. Mais il n'est pas le seul, surf de chez suckless est encore plus léger.
D'ailleurs ceux qui adorent ces principes unix, devraient allez regarder ce qui existe chez suckless. Ils ont certains logiciels « complet » comme surf ou dwm qui peuvent plaire ou pas, mais surtout ils ont une liste d'outils qui sont très intéressants.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas convaincu
Posté par freem . Évalué à 1.
Il me semble que ça dépend de quel "binaire" on lance. Perso, je prends celui qui est censé être le plus léger. Mais bon, je dois admettre que je trouve marrant de vouloir embarquer un langage interprété dans un logiciel qui se veut minimaliste.
Je n'ai pas inspecté très longtemps ce que suckless propose, mais je connais dmenu, qui a son utilité. Pas la panacée, cela dis, mais bon, il me suffira jusqu'a ce que j'en aie marre et fasse un truc plus adapté à mes besoins personnels.
[^] # Re: Pas convaincu
Posté par barmic . Évalué à 2.
Pour ça que les logiciels de suckless sont généralement fait pour être des sources C à compiler soit même une fois qu'on l'a configuré.
Je ne sais pas ce que tu lui reproche, mais peut être que ton bonheur se trouve dans l'un des patchs qui ajoute des fonctionnalités à dmenu (être vertical par exemple). Quoi qu'il en soit, si tu te met à bosser sur un truc pour toi n'hésite pas à regarder leur sources elles sont simples à prendre en main, ça peut être une bonne base.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas convaincu
Posté par freem . Évalué à 1.
Oh, c'est en fait assez simple: il donne trop d'infos :)
dmenu a ceci de pratique qu'il affiche tous les binaires (dans la limite du PATH de mémoire), mais un grand nombre est inutile dans le cas d'utilisation de dmenu. Grep, par exemple.
Ce que je finirai par bricoler, un jour lointain, serait un équivalent, mais qui n'affiche en fait que les applications graphiques (pour le coup, vu qu'on peut pas trop savoir lesquelles le sont, celles ayant un .Desktop suffiront j'imagine).
C'est vraiment de la flemme en plus, parce que lire un fichier de conf le nom des dossiers à scanner, puis parser les fichier Desktop pour en extraire le nom des applications n'est pas bien compliqué. Allez, 200-300 lignes de C++ peut-être? Et encore, avec quelques lib (genre boost filesystem/program_options. Je me demande si il existe une lib pour parser ces fameux fichiers desktop?) c'est l'affaire de 2-3 fonctions avec un peu de récursivité.
Comme je l'ai dis, c'est pour mes besoins, et je serai limite à dire que les deux seraient complémentaires, tant il est vrai que xkill par exemple est bien utile.
[^] # Re: Pas convaincu
Posté par barmic . Évalué à 4. Dernière modification le 05 avril 2013 à 16:43.
Ok tu n'a pas compris ce qu'est dmenu. Ce n'est pas un lanceur de programme (ou du moins ce n'est pas que ça). Il faut plutôt le voir comme un
readgraphique. Toi tu ne vois que dmenu_run. Pourquoi t'embêter avec 200 lignes de code C++ là où tu peut écrire le tout en 3 lignes ?Ou si tu veux être posix :
Note j'écris ça vite fait, il faudrait vérifier s'il faut protéger la variable pour le exec (je sais plus si exec du shell correspond à
exec(2)ou à un/bin/sh -c "...").Mais ça demande pas grand chose comme boulot (vraiment).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas convaincu
Posté par freem . Évalué à 0.
Sisi j'ai a peu près compris ce qu'il fait.
Mais vois-tu, je suis très peu à l'aise avec les outils tels que awk (ta regex inclue d'ailleurs une certaine dose de choses que je ne comprend pas, je verrai ça ce soir pour faire mumuse avec), je ne connais ni n'imagine même pas ce que signifie "shopt extglob" (pour le coup la version posix me parait bien plus lisible).
Je suis encore un grand débutant quand ça touche à bash, donc navré de ne pas toujours penser à exploiter toute sa puissance.
[^] # Re: Pas convaincu
Posté par daeldir . Évalué à 1.
Tu n'as pas forcément besoin de connaître bash… Juste la manière d'utiliser dmenu. dmenu prend une liste en entrée et renvoie le choix de l'utilisateur. Tu peux générer cette liste avec du C++, du Python, du shell… Perso, j'irai sur une approche shell bien plus (extrêmement) naïve, de ce genre :
Certes, c'est beaucoup moins efficace, mais ça demande pas un très haut niveau en shell. Si tu tiens absolument à générer ta liste avec du C++, tu peux écrire deux programmes en C++ (un qui génère la liste, un qui lance l'application), puis faire la glue en shell, comme ça :
(
|appname-to-commandest optionnel si ta liste est déjà une liste de commandes, bien entendu)Au final, tu auras au moins évité de réécrire ce que fait dmenu : l'affichage de la liste et le choix dans celle-ci.
Bref, vu ton commentaire, dmenu semble correspondre à ton besoin. Faut juste que tu remplaces dmenu_run par ton propre code ^^
[^] # Re: Pas convaincu
Posté par barmic . Évalué à 2.
Il ne fallait pas le prendre comme ça. Je présume que le ton ne t'a pas plu mais si j'ai pris le temps de pondre deux exemples c'est bien pour illustrer et rien d'autre. Le fait que tu explique qu'il fallait que tu sorte ton compilateur et 200 LOC m'a fait penser que tu imaginer qu'il fallait aller patcher le code de dmenu pour ça. Mes exemples ne sont là que pour montrer qu'il n'était pas nécessaire de modifier dmenu pour lui faire faire ce que tu souhaite.
Pour le ** c'est une extension de l’expansion de chemin (globbing extended) comme le * bien connu. Il permet d'être récursif, par exemple :
grep toto **/machinest équivalent àfind -name machin -exec grep toto \{\} \;.Les deux ont leur avantages et leur inconvénient. Les globbings étendus sont plus rapides à écrire (ce qui est agréable en mode interactif), mais il peuvent être plus lent (dans l'exemple avec grep le shell commence par créer la liste des chemins de fichier avant d'appeler grep, alors que find appel grep dès qu'il trouve le premier fichier).
Le shopt c'est juste pour l'activer dans bash.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas convaincu
Posté par freem . Évalué à 1.
Désolé, on est un peu plus sensibles quand on est fatigués.
Non, je ne compte pas patcher dmenu pour lui ajouter une fonctionnalité: je ne pense pas qu'ajouter des features à gogo à un unique programme soit une bonne façon de procéder, bien au contraire.
Merci pour tes précisions en tout cas.
[^] # Re: Pas convaincu
Posté par freem . Évalué à 1.
uzbl?
[^] # Re: Pas convaincu
Posté par Benoit Jacob (site web personnel) . Évalué à 10.
Asm.js permet de s'en approcher d'assez près, comme expliqué plus haut. Je pense que les liens ci-dessus donnent assez d'informations vérifiables là-dessus. On ne sait pas encore à quel point on va pouvoir s'en approcher, mais on est déjà à 50% du code natif, après seulement 3 mois de travail d'une seule personne travaillant sur le compilateur.
Non négligeable certes, mais raisonnable tout de même. C'est ce qui permet aux prototypes de téléphones Firefox OS que j'utilise, dotés de seulement 256 M de mémoire (pour nous forcer à optimiser), de fonctionner correctement, alors que tout y tourne dans Gecko.
Non! Aucun rapport entre «être un jeu Web» et «demander une connexion permanente»:
- il y a beaucoup de jeux Web qui ne demandent pas de connexion permanente, comme par exemple presque tous les jeux Firefox OS et Chrome Web Store, qui sont installables en local.
- réciproquement il y a beaucoup de jeux non-Web qui demandent une connexion permanente, par exemple le dernier jeu que j'ai acheté, Might&Magic Heroes 6.
On verra. En attendant je vois beaucoup de pub aussi sur les jeux sur iOS/Android non-Web… Pour le tracking, c'est un souci très important à prendre en compte, on verra. Mozilla a déjà fait un pas important en bloquant les biscuits émis par des tiers.
[^] # Re: Pas convaincu
Posté par zebra3 . Évalué à -4.
C'est bien beau les prototypes, mais s'il n'y a pas d'application réelle ça n'est pas vraiment utile.
Dans la vie réelle, Firefox 20 ne fonctionne pas sur des machines Android de moins de 512 Mo. Avant de s'atteler à sortir un OS complet, ça serait déjà pas mal de sortir un navigateur potable.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Pas convaincu
Posté par claudex . Évalué à 9.
FirefoxOS a des applications réelles et tourne sur des smartphones réels. Je ne vois pas ce qu'Android vient faire là-dedans.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas convaincu
Posté par zebra3 . Évalué à 3.
Ce qu'Android vient faire là-dedans, c'est qu'il est beaucoup plus répandu et surtout utilisé par des gens dans la vie de tous les jours.
Firefox OS, même s'il existe, n'est compatible que pour quelques téléphones, et son installation est manuelle.
Donc à mon avis, avoir un Firefox avec des performances décentes sur Android serait bien plus intéressant pour les utilisateurs.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Pas convaincu
Posté par claudex . Évalué à 5.
Il y a des smartphones de prévu avec Firefox OS dès la sortie. Mais tu t'éloigne du sujet, tu dis que Firefox est gourmand, pourtant gecko tourne sur des smartphones de 256Mo de ram. Si Firefox sur Android a besoin de plus de ram, c'est peut-être aussi lié à Android, et c'est 384 Mo pas 512.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas convaincu
Posté par zebra3 . Évalué à 0.
Ben oui, Firefox est gourmand. Peu importe que ça vienne ou non de Gecko, c'est un fait. Rien que la 19 prenait une bonne minute à se charger sur mon téléphone et était inutilisable. Et je parle bien sûr d'un profil vierge.
Sachant qu'il reste un bon paquet d'appareil avec Android 2.2/2.3 et 256 Mo de RAM, ça ne change pas grand chose.
Quand bien même, je me réfère plutôt aux notes du dépôt qui demandent 500 Mo pour ARM6.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Pas convaincu
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Question sérieuse: quel est l'intérêt de prendre un smartphone dont l'OS est juste un navigateur par rapport à un OS qui a un navigateur et de vraies applications en plus?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas convaincu
Posté par claudex . Évalué à 8.
C'est quoi des vrais applications ? Parce que, Android et Firefox OS font tous les deux tourner les applications dans une VM.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas convaincu
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Ce que je veux dire, c'est qu'en prenant un smartphone android, j'aurais accès à tous les jeux html5 et android. Avec FirefoxOS, j'aurais juste accès aux jeux html5. Pourquoi prendre FirefoxOS?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas convaincu
Posté par claudex . Évalué à 7.
Parce qu'il tourne sur des smartphone moins cher, parce que toutes les API JS n'ont pas encore été standardisées et qu'il y a donc des applications spécifiques à Firefox OS, parce que tu préfère le design de Firefox OS…
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas convaincu
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Je souhaite bonne chance à FirefoxOS et j'en prendrais peut être un si mon vieux nokia me lâche, car je n'apprécie pas le tracking de google, mais la concurrence risque d'être rude sur le marché des jeux, si on se retrouve dans la situation suivante:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas convaincu
Posté par barmic . Évalué à 5.
Tu as des infos là dessus ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas convaincu
Posté par claudex . Évalué à 4.
Ça me semble surtout difficile à mesurer alors qu'on est seulement au début d'asm.js.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas convaincu
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Dalvik n'est pas plus rapide que du javascript?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas convaincu
Posté par claudex . Évalué à 4.
C'est sa question.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas convaincu
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Je croyais que oui, puisque dans les classement les jvms sont souvent juste derrière C++, mais apparemment ce n'est pas si évident pour Dalvik…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas convaincu
Posté par claudex . Évalué à 5.
Dalvik n'est pas une JVM.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas convaincu
Posté par groumly . Évalué à 1.
Mais pourquoi donc oracle a fait un proces a google?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Pas convaincu
Posté par claudex . Évalué à 3.
C'était sur le langage Java, qui n'a pas grand chose à voir avec la JVM si ce n'est que le nom. La JVM c'est une machine virtuelle standardisée pour exécuter un bytecode bien défini (il en existe plusieurs implémentations d'IBM, d'Oracle…). On peut utiliser la JVM sans faire de Java (Jython, JRuby…), et on peut faire du Java sans JVM (à part Dalvik, je n'en connais pas mais c'est faisable (de la à dire que c'est intéressant…)), si tu veux plus d'information http://fr.wikipedia.org/wiki/Dalvik_%28machine_virtuelle%29#Architecture .
Si je me souviens bien (mais j'ai la flemme de chercher pour vérifier mes propos), c'est parce que Dalvik n'est pas une JVM qu'Oracle a pu faire un procès, puisqu'ils garantissent de ne pas faire de procès à ceux qui implémentent une JVM opensource.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas convaincu
Posté par Jean B . Évalué à 2.
C'est un petit peu au point mort suite à la libération de Java mais: GCJ
[^] # Re: Pas convaincu
Posté par claudex . Évalué à 3.
GCJ ce n'était pas une JVM ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas convaincu
Posté par Larry Cow . Évalué à 2.
Les deux mon capitaine. Il pouvait (peut?) compiler vers du bytecode ou du code natif.
[^] # Re: Pas convaincu
Posté par claudex . Évalué à 3.
Ah, merci pour l'info.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas convaincu
Posté par barmic . Évalué à 3.
Il y a les CPU qui exécutent directement du Java, non ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas convaincu
Posté par claudex . Évalué à 3.
Ils sont morts. Et je crois que le but était que ce soit des JVM matérielles.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas convaincu
Posté par freem . Évalué à 1.
Une Java Virtual Machine matérielle… intéressant comme concept, mais un peu voué à l'échec, puisque, du coup, il faut parler de Machine Java directement, non?
Ou alors on peut dire que les processeurs intel sont des machines virtuelles, puisqu'ils font la même chose que bochs par exemple xD
[^] # Re: Pas convaincu
Posté par claudex . Évalué à 3.
Si tu veux, je voulais surtout dire que ces machines étaient prévue pour voir exécuter du bytecode Java standard (c'est-à-dire en respectant les normes des JVM).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas convaincu
Posté par barmic . Évalué à 3.
Parce que le support d'APIs HTML5 est plus développé (notamment pour tout ce qui est utilisation du matériel) ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas convaincu
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Ca peut m'intéresser en tant que développeur amateur, mais pas en tant que joueur.
(Oui j'ai des personnalités multiples et incohérentes).
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas convaincu
Posté par barmic . Évalué à 2.
Ben si tu veux utiliser l'appli HTML5 de firefox OS pour te prendre en photo entrain de faire un duck face, il vaut mieux avoir le support de la webcam (je dis bien pour utiliser cette appli en question et pas une appli parmis d'autres).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas convaincu
Posté par Benoit Jacob (site web personnel) . Évalué à 3. Dernière modification le 04 avril 2013 à 15:05.
C'est vrai, Android consomme plus de mêmoire que Firefox OS, donc c'est plus difficile, mais c'est un projet qu'on essaye de mener à bien: https://bugzilla.mozilla.org/show_bug.cgi?id=792131
…Edit: oups, ce projet a été WONTFIXé, apparemment on n'y arrivera pas, Android consomme trop de mémoire… il reste vrai que Firefox OS tourne bien sur des appareils avec 256M de RAM unifiée.
Sur le bug:
[^] # Re: Pas convaincu
Posté par Julien Jorge (site web personnel) . Évalué à 7.
Je me souviens avoir entendu cet argument pour un langage de programmation à base de bytecode et de machine virtuelle. Il parait que ce langage aurait fait vendre de la RAM et des processeurs… Quelqu'un se souvient d'un tel truc ?
[^] # Re: Pas convaincu
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Python?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas convaincu
Posté par Olivier Serve (site web personnel) . Évalué à 2.
Pascal ?
[^] # Re: Pas convaincu
Posté par Giovanna . Évalué à -1.
Un ancêtre?… Me rappele dans les années 85/90…
[^] # Re: Pas convaincu
Posté par freem . Évalué à 2.
Java?
[^] # Re: Pas convaincu
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
certes, mais on s'en approche. Aujourd'hui, c'est "seulement" 2 fois plus lent, mais il y a encore de quoi faire des optimisations dans l'implem de asm.js.
Oui, mais c'est surtout à cause des sites web. J'ai vu une présentation de conf dernièrement, qui montrait que statistiquement, le poid moyen d'une page a "grossie" de 44% en un an ! Beaucoup de dev web sont des gorets, qui utilisent des libs à tout va sans réfléchir (et avec tout ces bloatwares de framework js qui pullulent, c'est pas prêt de s'arreter…). Des pages web à 1Mo pour afficher 2 textes, merde quoi.
En quoi ? Si leur jeux sont lourds, ils ont tout intérêts à utiliser App-cache et cie, sinon bonjour leur bande passante. Et ils peuvent packager sous forme de web-app.
malheureusement oui… mais il y a des extensions pour éviter toutes ces merdes.
le trou de sécurité n'est pas si énorme que ça. il y a quand même pas mal de mécanismes pour éviter l’apocalypse. Maintenant, pour les crash, faudrait voir exactement d'où ça vient (driver graphique moisi ? ou carte incompatible ?). Les implémentations sont jeunes. Et puis perso, j'ai pas d'écrans bleus sous linux ;-)
[^] # Re: Pas convaincu
Posté par Prae . Évalué à 4. Dernière modification le 03 avril 2013 à 18:23.
J'ai été autant étonné de voir des célèbres librairies js avoir autant de leak-memories. En développant une appli qui demande des grosses performances par web, j'ai dû me résigner à utiliser JQuery et autres librairies js. Et là, j'en suis à me poser des questions sur socket.io …
Quand je fais nativement, j'ai aucun leak-memory, quand j'utilise ses librairies, c'est la foire aux fuites.
A titre d'information, par jour, (en utilisant une seule librairie et le reste en code natif), je dois perdre environ 10 Mo. En une semaine, c'est entre 100 à 150 Mo de leaké. Ma consommation mémoire est passée de 4.9% de la mémoire totale à maintenant 8.1% (sur 4 Go). Et pourtant, j'ai quasi-rien. Quand je désactive ses librairies et que je reviens à un code natif, la consommation (et les leaks) descendent globalement et fortement.
Maintenant, c'est à se poser la question: soit on déplombe la librairie JS (et on perd beaucoup de temps sans être sûr d'y arriver), soit on passe sur un code natif qui fait la même chose mais avec moins de leak-memory au final.
[^] # Re: Pas convaincu
Posté par barmic . Évalué à 5.
Quand tu parle de natif, tu parle de code compilé nativement ou de javascript sans surcouche ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas convaincu
Posté par Prae . Évalué à 3.
C'est l'API de "base" Javascript, genre :
document.addEventListener("DOMContentLoaded", function(){ }); à la place de Jquery $(document).ready(); et autres video.addEventListener("play", function() { }); au lieu des API des autres sur-players. (Idem pour HTML5 WebSocket), etc…
[^] # Re: Pas convaincu
Posté par groumly . Évalué à 10.
50% plus lent je comprends surtout ca comme "ca bouffe vachement plus de batterie".
Autant la vitesse pure est pas trop un probleme pour faire angry birds (et ca tourne sur de l'armv6, alors bon, du js sur un a6 c'est pas delirant).
Par contre si ca me flingue ma batterie en 2 heures, ca va etre un vachement plus gros probleme.
Ou alors vous visez les desktops? Si oui, bonne chance!
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Pas convaincu
Posté par Guillaume Denry (site web personnel) . Évalué à 5.
Est-ce que c'est si important que cela, en regard des avantages de pouvoir faire tourner un jeu sur un navigateur web ?
(attention, "important" ne veut pas dire que je pense qu'un marché prédominant de jeux AAA serait forcément une bonne chose)
[^] # Re: Pas convaincu
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Quels sont les avantages pour les joueurs? Avoir une bonne excuse pour acheter un nouveau PC?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas convaincu
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Cela mrche sous android/iOS/linux/Windows sans rien faire de spécial.
Cela veut dire qu'il risque d'avoir une vrai concurrence de console/box de jeu sous différent OS, qui pourront faire tourner les mêmes jeux tout en étant différente.
"La première sécurité est la liberté"
[^] # Re: Pas convaincu
Posté par zul (site web personnel) . Évalué à 1.
on nous a déjà vendu ça avec un langage avec vm, bytecode et dont le nom commence pareil.
[^] # Re: Pas convaincu
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
l'HTML5, javascript et webgl ne marche pas déjà sur plein de plateforme ?
"La première sécurité est la liberté"
[^] # Re: Pas convaincu
Posté par Batchyx . Évalué à 7.
À quelques exceptions près, c'est lent sur toutes les plateformes.
[^] # Re: Pas convaincu
Posté par zebra3 . Évalué à 3.
Faudrait peut-être se pencher sur la question des pilotes graphiques avant, non ? J'ai l'impression qu'on met la charrue avant les bœufs.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Pas convaincu
Posté par barmic . Évalué à 3.
Actuellement tu as déjà un paquet de jeux qui tournent dans un navigateur sans problème. Si c'est pour tenter de faire tourner Crysis 3, oui ça ne marche pas à l'heure actuelle. Mais il y a un paquet de jeux qui n'ont pas besoin de la dernière nVIDIA pour fonctionner et qui sont véloces sur navigateur (les jeux de plateforme 2D par exemple ;) ).
Regarde une « petite » liste de jeux sur navigateur (environ 760)
Les avantages c'est d'être multiplateforme (soit plus facilement soit au moins en supportant un navigateur multiplateforme), c'est sans installation et tu as un peu de contrôle de ce qui entre et ce qui sort de ta machine (avec la palanqué d'extension et/ou de proxy qui servent à ça), là où tu code compilé avec un protocole spécifique (skype ?) ne te permet rien.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas convaincu
Posté par zul (site web personnel) . Évalué à 2.
ça pointe vers des jeux flash, c'est normal?
Et on a pas attendu les applications dans le navigateur pour filtrer ce qui entre et ce qui sort d'une application ("firewall applicatif", "systrace", "selinux",…). Évidemment, si tu as un contenu bien chiffré et qui passe tout par un proxy, il n'y a pas grand chose à faire, mais je ne vois pas bien ce que le navigateur peut faire de mieux.
Et tu peux évidemment utiliser des logiciels libres, ce qui évite tout déboire (on pourrait dire la même chose sur le web évidemment, même si par définition, on a beaucoup moins de contrôle sur ce qui est téléchargé puis exécuté).
[^] # Re: Pas convaincu
Posté par barmic . Évalué à 5.
Ma liste n'était là que pour montrer que du jeux sur navigateur c'est déjà présent et pas qu'un peu, que les perf sont suffisantes. Donc soit les standards ont quelque chose à proposer soit flash restera encore longtemps.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas convaincu
Posté par barmic . Évalué à 10.
Je crois que la question n'est pas est ce que le jeux vidéo dans un navigateur c'est bien ou pas, mais comment est-ce que ça va se faire. Aujourd'hui il existe déjà que ce soit sous la forme de jeux de gestion comme ogame ou des jeux plus animés, ils sont déjà là, depuis longtemps.
Si flash tend à disparaître c'est parce que HTML5 (l'ensemble des technologies de ce label) ouvrent la voie à une alternative à chaque cas d'utilisation de flash. Personnellement je préfère que ce soit fait avec des technologies qui ont des spécifications ouvertes, des implémentations libres et qui mangent un overhead de 50% entre autre pour avoir un peu plus de sécurité, que de trimballer un blob binaire qui fait je ne sais pas trop quoi.
Après personnellement je ne joue pas sur navigateur (pour le moment).
Prépare une instance uniquement pour ça (que tu peut tuer si besoin).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas convaincu
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Il y a deux autres voies pour avoir la portabilité du web et de meilleurs performances:
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas convaincu
Posté par barmic . Évalué à 4.
Un peu comme ECMAScript 6, mais en changeant encore plus ? Un truc implémenté nulle part et utilisé dans 15 ans.
Je crois que d'autres en parlent plus haut comme quoi ça devrait se faire d'ici la fin de l'année.
Il y a des gens qui codent des jeux en java et il semble que ne pas avoir de mot clef delete ne les dérange pas trop.
Ce serait dommage : pourquoi ce serait « pour les jeux » ? Quelle est la sécurité en plus dans les jeux au quel on aurait pas le droit ailleurs ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas convaincu
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Je préfèrerais un vrai langage, mais oui pourquoi pas :-)
L'approche de Dart était sympa, je n'ai pas compris pourquoi Mozilla a boudé.
C'est LE problème majeur quand tu fais des jeux en java : comment gérer les ressources (textures, buffers sons) et empêcher ce $!*! de ramasse miettes de se faire gros lag au beau milieu de la partie.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas convaincu
Posté par claudex . Évalué à 7.
J'imagine qu'une VM à développer avec tous ses bugs et ses trous de sécurité à corriger ne les motive pas tant que ça.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas convaincu
Posté par devnewton 🍺 (site web personnel) . Évalué à -2.
Du coup, ils font un coup de force en imposant un bytecode pour lequel il va falloir écrire un VM spécifique.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas convaincu
Posté par claudex . Évalué à 4.
Tu as vraiment lu les documents sur asm.js ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas convaincu
Posté par devnewton 🍺 (site web personnel) . Évalué à -1.
Oui et j'ai du mal à voir autre chose qu'un mauvais bytecode.
La compatibilité avec l'existant est juste une tactique géniale pour forcer les autres à l'implémenter puisque du point de vu de l'utilisateur, le ressenti ne sera pas ce site est nul, le jeu ne se lance pas, mais mon navigateur est nul, le jeu est lent avec.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas convaincu
Posté par claudex . Évalué à 3.
Tu fais un concours avec l'alien des Secret Service ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas convaincu
Posté par devnewton 🍺 (site web personnel) . Évalué à 0.
Je n'ai compris cette référence, c'est certainement un message codé pour Eux.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas convaincu
Posté par claudex . Évalué à 0.
https://www.youtube.com/watch?v=Sm7-5HV3Pk4
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas convaincu
Posté par barmic . Évalué à 5.
Ils ont réussi à améliorer de manière drastique les performance d'une partie de javascript (qui est un langage normalisé). Tu te disais la même chose quand Chrome est arrivé avec des perf de malade ? (Bouhou, ils font ça juste pour que ce soit plus rapide pour leurs utilisateurs et avoir des parts de marchés (quels salauds !)).
Alors que tu es pour que tout le monde se mettent à faire du dart (à ça non, ce n'est pas un projet de domination de google).
Bref d'un coté Mozilla améliore l'existant et a une approche basée sur des standard (mais bouh ! tout le monde va devoir améliorer leur performance javascript pour se mettre à niveau !), là où google repart de rien et trace sa route tout seul.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas convaincu
Posté par devnewton 🍺 (site web personnel) . Évalué à -2.
Les façons de sortir dart et asm.js apparaissent effectivement comme des tentatives de domination. L'une est propre, l'autre est une bidouille et malheureusement c'est cette dernière qui va probablement gagner.
Je pense aussi à une chose: maintenant que la boite de pandore est ouverte et si d'autres bytecodes javascript faisaient leur apparition? Certains mieux pris en charge par webkit, d'autres par Trident, etc…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas convaincu
Posté par GnunuX (site web personnel) . Évalué à 7.
Mais asm.js n'est pas un bytecode, arrête de dire que c'est un bytecode. C'est un sous ensemble de javascript ".".
[^] # Re: Pas convaincu
Posté par Littleboy . Évalué à 6.
As-tu regarde la spec? La difference entre un module asm.js de quelques megas et un gros bloc de bytecode est pas tres grande, hein.
Et quand on parle de sous-ensemble de javascript, c'est un sous-ensemble tellement reduit et optimise pour etre compile (pas pour etre ecrit a la main) avec des ajouts a la lib juste pour optimiser certains cas super rare dans du code "normal" mais qui reviennent beaucoup dans du code optimisee par un compilateur.
En gros, c'est operations numeriques sur un bloc de memoire statique (et c'est tout). Va donc voir la sortie d'un bloc ASMJS par Emscripten et reviens nous expliquer la difference fondamentale avec du bytecode.
Par ailleurs, si on regarde les plans de Mozilla (AOT force, parseur separe pour le code asm.js), ca ressemble quand meme tres fortement a utiliser ce sous-ensemble du JS comme representation intermediaire plutot que de redefinir leur propre format de bytecode.
C'est pas une mauvaise idee et c'est une bonne alternative a NativeClient, mais il faudrait pas non plus prendre la comm' de Mozilla pour quelque chose d'objectif. Les petits arrangement avec la verite et la petite histoire du gentil Mozilla et les standards contre le mechant Google dans ce journal, c'est joli mais c'est quand meme du BS de premiere.
[^] # Re: Pas convaincu
Posté par Benoit Jacob (site web personnel) . Évalué à 9. Dernière modification le 04 avril 2013 à 03:34.
J'ai du mal à comprendre ce que tu cherches à critiquer ici. On n'a jamais dit que le JS à la asm.js était «différent» d'un bytecode: la question n'a pas de sens, comme je vais essayer de l'expliquer maintenant. On n'a jamais non plus critiqué l'idée en soi d'utiliser un «bytecode» dans la mesure où ce «bytecode» serait vraiment utile et n'aurait pas d'inconvénient rédhibitoire. L'idée poursuivie par Mozilla ici est que tout langage peut être compilé vers tout langage, et donc en particulier que tout langage peut servir de «bytecode». À partir de là, on ne voit pas à quoi bon introduire un nouveau «bytecode» ou, pour utiliser un terme plus approprié, un nouveau «langage intermédiaire», puisque JS peut très bien remplir ce rôle. Tout langage peut être utilisé comme «bytecode», il suffit de savoir décompiler du code compilé vers ce langage. C'est clair?
Parlons maintenant de Native Client. Non content d'introduire son propre langage intermédiaire, ce qui est inutile comme je viens de l'expliquer, Native Client introduit un langage intermédiaire séparé pour chaque architecture (le code machine) ce qui casse la portabilité du Web, et Native Client introduit aussi son propre ensemble d'APIs, Pepper, remplaçant les APIs DOM, ce qui sape l'influence des autres développeurs de navigateurs. Voilà les raisons pour lesquelles Mozilla est résolument décidé à contrer Native Client. Tu peux en penser ce que tu veux, mais c'est cohérent avec les buts que Mozilla s'est fixés. J'ajoute que cet article est vraiment mon opinion personnelle: je n'en ai parlé à aucun collègue et la «comm» n'est pas mon métier.
[^] # Re: Pas convaincu
Posté par Littleboy . Évalué à 10. Dernière modification le 04 avril 2013 à 05:27.
Le message auquel je reponds juste au dessus (dont l'auteur n'a pas du prendre le temps de lire l'intro de la spec), ainsi que la partie de ton journal qui dit "Le code asm.js utilise les mêmes APIs DOM que n'importe quel code JavaScript."
J'ai peut-etre compris la spec completement a l'envers, mais quand je lis les autres commentaires dans le journal j'ai l'impression que les gens mettent un peu tout et n'importe quoi dans l’appellation 'APIs DOM' (et melangent WebGL, JavaScript 'normal' et modules asm.js).
Qu'est ce que tu entends par "utilise les memes APIs"? Qu'un module asm.js peut utiliser une grande partie des APIs DOM (sans tourner en version interpretee)?
Disons que pour faire quelque chose du niveau de asm.js, c'est en effet pas forcement interessant de specifier son propre format de bytecode. Cela-dit, Mozilla prevoit d'ecrire un parseur separe pour les modules asm.js, du coup on voit plus trop l'interet d'etre un sous-ensemble de javascript.
Finalement c'est plutot pour des raisons de strategie: etre pret rapidement en reutilisant l'infrastructure existante, communiquer sur le fait que ca marche partout en mode interprete (on rigole, parce que le moteur Unreal 3/4 qui tourne avec la version interpretee en haute resolution, j'attends quand meme de voir).
C'est tres probablement une strategie gagnante. Au niveau technique j'ai tendance a trouver ca un peu degeu, mais si ca permet une adoption par tous les navigateurs rapidement, ca se discute pas :)
C'est pour ca que Google bosse sur PNaCl depuis un moment (oui, c'est pas si facile que ca et c'est toujours pas pret - voir au dessus pour mon avis sur la meilleure strategie).
Ce qui gene Mozilla c'est qu'ils n'ont aucun controle dessus, pas le fait que ca soit de nouvelles APIs. Si lorsque PNaCl est stabilise Google essaye de standardiser tout ca, Mozilla serait toujours aussi contre.
Si j'ecris un journal pour parler des trucs biens que fait ma boite et critiquant la concurrence (developpement ferme, pas standard), ca sera peut-etre mon avis personnel mais ca fera la comm' de ma boite.
Ce que tu decris dans ton journal est tres interessant (j'ai pertinente), mais les parties non techniques s'averent etre exactement l'axe de comm' de Mozilla. Ca ne veut pas dire que tu repetes betement la comm' mais:
Bref, ca a beau etre ton avis perso, c'est aussi dans la ligne de l'entreprise (et ne soyons pas naifs, en tant qu'employee de Mozilla si tu etais tres critique vis a vis de la strategie de ta boite, tu viendrais pas poster sur LinuxFR).
Desole si ca fait tres critique envers ta demarche, je pointe juste que certaines des critiques que tu fais n'ont rien d'objectif. J'ai d'ailleurs le meme avis sur les personnes qui par exemple sont toujours promptes a critique web/internet et deviennent mysterieusement silencieuses des que ca parle de sauvegarde de la vie privee et tracking des utilisateurs…
Donc continue a poster des journaux sur ce que fait Mozilla, je les lis avec plaisir :)
[^] # Re: Pas convaincu
Posté par devnewton 🍺 (site web personnel) . Évalué à -2.
C'est bien le problème: quand Google sort Dart sans prévenir, on crie à l'infamie, quand Mozilla sort asm.js sans prévenir, on applaudit.
Il s'agit pourtant d'un coup de force qui pourrait se retourner contre eux à coup de fork inamical de asm.js.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas convaincu
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
dart est un nouveau langage, asm.js est 100% retro-compatible et est plus rapide que javascript. Je ne comprends pas le problème.
Si asm.js est plus rapide, c'est parce qu'il introduit du typage dans javascript de façon plus précise qu'habituellement.
"La première sécurité est la liberté"
[^] # Re: Pas convaincu
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
L'approche de dart était plus propre, car à la fin on aurait eu des pages web avec des scripts lisibles dans un nouveau langage propre.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas convaincu
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Tu négliges l'effort et l'énergie nécessaire pour avoir un truc fonctionnel. C'est plus simple de partir sur js.
"La première sécurité est la liberté"
[^] # Re: Pas convaincu
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
On parle du web, ça mérite un peu d'effort!
Mozilla prépare bien le futur firefox en partant de zéro avec Rust.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas convaincu
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
Rust n'est pas un langage web.
[^] # Re: Pas convaincu
Posté par dave_null (site web personnel) . Évalué à 0.
Tout comme il existe UglifyJS, un UglifyDart aurait eu un grand succès.
[^] # Re: Pas convaincu
Posté par Gof (site web personnel) . Évalué à 3.
Dart permet aussi de compiler vers javascript et est donc tout autant retro-compatible.
[^] # Re: Pas convaincu
Posté par barmic . Évalué à 0.
Sortir ? Il n'est pas encore sorti. On en parle beaucoup depuis mi-mars (pour des spec qui sont sorti le 17 mars) et les développements préliminaires sont tout à fait public (https://github.com/dherman/asm.js et https://github.com/kripken/emscripten).
Je ne sais pas si dart était ouvert ou pas et personnellement je n'ai pas d'avis sur dart. Quoi qu'il arrive on voit que ce ne sont que des détails d'implémentation. Aujourd'hui le web s'oriente vers un langage (x, y ou z) qui se compile vers du javascript ou un quelconque autre bytecode OSEF (javascript sert de pierre angulaire¹ parce que c'est lui la norme et qu'il est dispo partout).
¹ : pour asm.js comme pour dart, même si je sais que dart a l'ambition de devenir directement exécutable par les navigateurs enfin directement compilable vers un bytecode via du JIT (que ceux qui l'implémentent utilisent javascript, le bytecode de la jvm, celui de la machine parrot ou s'en créent un nouveau pour l'occasion OSEF).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas convaincu
Posté par Benoit Jacob (site web personnel) . Évalué à 5. Dernière modification le 04 avril 2013 à 15:29.
Par «APIs DOM» je veux dire les APIs exposées à JavaScript par les navigateurs. Du coup bien entendu que WebGL en fait partie, et comme asm.js est un sous-ensemble de JavaScript, cela ne fait aucune différence: le code asm.js a accès exactement aux mêmes APIs que n'importe quel code JavaScript.
C'est déjà fait dans Nightly et c'est un compilateur ou plutôt une nouvelle passe de compilation ajoutée à IonMonkey (initialement appelée OdinMonkey). L'intérêt d'être un sous-ensemble de JavaScript reste que le code asm.js tourne sans condition sur tous les navigateurs.
Je ne sais pas ce que tu veux dire par «en mode interprété». De plus en plus, dans la plupart des navigateurs, tout le code JavaScript est compilé, asm.js ou pas. D'ailleurs depuis hier il n'y a même plus d'interpréteur JS dans Gecko.
Comme je l'ai expliqué dans mon journal, même dans un navigateur dépourvu d'optimisations spécifiques asm.js, le code asm.js tend à tourner un peu plus vite que du JS normal, grâce à son typage implicite que la plupart des moteurs JS sont capables de reconnaître partiellement. Les optimisations asm.js ajoutées à Gecko ne font que formaliser ça pour le rendre systématique.
«Pas si facile que ça» est un euphémisme. PNaCl essaye d'utiliser le langage intermédiaire de LLVM sur le Web, or les devs de LLVM ont clairement indiqué que c'était une mauvaise idée.
Admettons un instant que PNaCl sorte en vrai. Le problème de portabilité de NaCl serait alors résolu, mais il resterait le problème que ça requiert le support des APIs Pepper, qui, comme je l'ai expliqué, est inacceptable pour tout autre développeur de navigateurs que Google, puisque ces APIs sont contrôlées par Google seul. Donc oui, Mozilla rejetterait ça même si asm.js n'existait pas, et oui ça serait parce que Mozilla n'aurait pas le contrôle nécessaire sur ces APIs, mais soyons clair, tu ne peux pas blâmer Mozilla pour ça: il est sain pour un développeur de navigateurs de rejetter une technologie qui implique de brader son influence au profit d'un concurrent, car il est sain que les APIs du Web soient contrôlées par tous les développeurs de navigateurs et non par un seul. Dans le monde réel maintenant, comme asm.js existe, Mozilla n'aurait même pas à invoquer ces raisons, puisqu'il suffirait de dire que comme PNaCl n'apporte rien qui ne puisse être fait avec asm.js et requiert bien plus de travail dédié, c'est simplement une mauvaise idée.
[^] # Re: Pas convaincu
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Si PNaCl devient populaire, Mozilla sera forcé de le gérer, tout comme ils ont implémenté un lecteur pdf (contrôlé par Adobe), ont pour projet d’implémenter un player flash en js (contrôlé par Adobe) ou permettent de lire du h264 (contrôlé par MPEG LA).
Les standards du web, c'est un concours de gros mumuscles :-(
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas convaincu
Posté par Littleboy . Évalué à 2.
Cough cough…
Custom asm.js parser (bug 854061) (estimated time: 2 months): create a new parser (reusing the tokenizer) that only recognizes asm.js, falling back to the general purpose parser on any failure. This would avoid creating 1.5GB of ParseNodes for 50MB asm.js files and also making parsing a lot faster.
https://wiki.mozilla.org/Javascript:SpiderMonkey:OdinMonkey
Les navigateurs qui n'implementent pas le support direct pour asm.js et donc ne font pas une passe de compilation AOT dessus doivent executer le code en mode interprete/JIT (pareil que du code qui ne passerait pas la validation pour les navigateurs avec le support d'ailleurs). Et c'est evidemment beaucoup beaucoup plus lent, sinon faire son propre parseur et compilateur AOT n'aurait aucun interet.
[^] # Re: Pas convaincu
Posté par mackwic . Évalué à 2.
Le code asm.js est plus rapide que son équivalent sémantique utilisant l’entièreté du vocable JS. Inconditionnellement.
Après, tu peux optimiser encore plus cette partie. GRAND SCOOP ! L'optimisation tire parti de cas spécifiques ! (ici, typer les variables définitivement, se limiter a certaines opérations, etc.).
Qu'est-ce qui te choque tant la dedans ? C'est pourtant simple.
[^] # Re: Pas convaincu
Posté par Littleboy . Évalué à 5.
Dans la cas de figure qui nous preoccupe (moteur de jeu recent avec des grosses demandes en perf), ca nous fait une belle jambe que compiler vers asm.js / JIT permettent de grappiller quelques % par rapport a du javascript idiomatique / JIT lorsque l'abscence de support AOT te donne juste un slideshow.
Comme dit plus haut, la partie "c'est du javascript ca va tourner pareil sur les navigateurs qui n'ont pas de support asm.js", c'est de la comm' (en gros c'est vrai tant qu'il n'y a aucune application qui necessite les perfs fournies par le support asm.js)
[^] # Re: Pas convaincu
Posté par mackwic . Évalué à 8. Dernière modification le 04 avril 2013 à 22:10.
C'est le principe de l'optimisation, grappiller de la perf, ouais. Ah c'est sur, tu passe pas de O(n²) a O(log n), mais c'est toujours ca. D'ailleurs la version de Mozilla apporte un gros gain ! C'est une belle avancée en terme d'optimisation !
P*** mais non ! On te montre un JS qui est garanti comme étant plus performant que la moyenne partout. C'est quoi que tu comprends pas ? Plus performant que du JS classique ou partout ?
Asm.js est performant, partout, tout le temps, qu'il vente, qu'il pleuve ou qu'il neige. C'est vrai. Point. Période, dix de der et rebelote. Oui les performances varient selon les plateformes et l'implémentation. Le C# sous windows est plus performant que le C# sous Mac. L'eau ca mouille.
[^] # Re: Pas convaincu
Posté par Shuba . Évalué à 5.
D'un point de vue CPU peut-être, mais est-ce que ça n'implique pas des temps de chargement des pages plus longs pour cause de code javascript plus volumineux (a priori faut plus de code pour exprimer la même chose en prenant un langage de moins haut niveau)?
[^] # Re: Pas convaincu
Posté par mackwic . Évalué à 2.
Ca, c'est un point pertinent. J'imagine que de toute facon charger UT4 en mémoire ca implique un temps de chargement.
[^] # Re: Pas convaincu
Posté par Littleboy . Évalué à 6.
Il y a plusieurs problemes en fait:
la taille du code et des donnees a telecharcher (ceux qui se plaignent au dessus de la taille des libs js vont pleurer avec des fichiers JS de 20Mo ou plus :P): on peut distribuer sous forme d'application et stocker tout ca en cache local sur les navigateurs recents (mais c'est souvent limite a 5Mo). C'est une problematique plus large en fait: comment distribuer des applications qui font plusieurs Go dans un environnement ou les utilisateurs sont habitues a un chargement quasi instantane. Il y a plein de developpements interessants dans ce domaine (streaming, application cache, etc.)
le temps de compilation du code et la memoire consommee (le code asm.js est compile AOT): Mozilla a prevu d'ecrire un parseur specifique et optimise pour asm.js, vu qu'apparemment les tests sur des fichiers de 50Mo voient la conso memoire titiller la barre des 1.5Go (ouch!). Et comme pour les donnees, on peut essayer de mettre en cache une partie du code compile.
[^] # Re: Pas convaincu
Posté par Littleboy . Évalué à 3.
Oui, et comme on oublie de bien preciser que ca ne concerne pas 99% des cas d'utilisation du JS et que pour les 1% restant (les jeux et les applis qui ont besoin de perfs) ca risque de necessiter le support complet asm.js de toute facon, ca reste de la communication.
Ce que tu ne sembles pas comprendre c'est que gagner quelques % de perfs c'est pas forcement desirable si les contreparties sont trop importantes. En particulier:
Si on oublie de parler de tout ca, on pense que asm.js c'est la solution magique juste parce que c'est un peu plus rapide, alors que pour le moment c'est reserve uniquement a la compilation via un generateur de code (ou a du code qui doit etre tres optimise, mais qui ne concerne certainement pas la totalite d'une appli web).
Bref, ma critique initiale c'est pas que c'est inutile parce que c'est juste un peu plus rapide que du code JS, c'est que pour la cible (les jeux avec grosse demande de perf) etre juste un peu plus rapide que du code JS c'est deja redhibitoire. Par consequent pointer ca comme un gros avantage est mensonger puisque des applis qui ont besoin de grosses perfs seront de toute facon inutilisables sans un support natif.
Mais on s'en fout, ca n'a jamais ete la question.
L'assembleur est performant, partout, tout le temps, qu'il vente, qu'il pleuve ou qu'il neige.
Le C est performant, partout, tout le temps, qu'il vente, qu'il pleuve ou qu'il neige.
Voila, c'est a peu pret ce que tu racontes. Pas besoin de t'expliquer ce que je pense des gens qui affirment betement ce genre de chose je pense.
[^] # Re: Pas convaincu
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 04 avril 2013 à 08:47.
Hum, faudrait quand même prendre un peu de recul, et ne pas voir sa solution comme la super-méga-génial sans inconvénient :
Tant que Mozilla n'arrivera pas a des perfs équivalentes (allons, prenons large, disons 90% du natif, ça fait quand même après peut-être 10% de durée de vie de la batterie en moins, déjà pas très appréciable), c'est utile pour… Avoir des perfs (ou de la batterie, au choix).
Argument dépassé (PNaCl), et si c'était un argument, il aurait suffit à Mozilla de faire la version portable.
Et surtout n'a pas été proposé par Mozilla. Parce quand Google propose WebM, pas standard du tout alors qu'il n'y a un standard qui existe, et que Mozilla n'a rien à proposer en face, Mozilla n'a aucun problème à prendre un nouveau produit introduit avec son propre ensemble de code pour arriver à ses fins. Pepper est ce qu'il est, ses qualités, ses défauts, mais pas que des défauts, il a été fait pas pour rien.
Espérons qu'il soit un peu plus résolument décidé à contrer Native Client qu'H264, j'avais parié que Mozilla abandonnerait son idée de ne pas supporter H264 car ils étaient "absolument contre", mais j'ai été surpris de la rapidité du retournement de veste. Quand Mozilla est "résolument décidé", c'est comme dans toutes les boites, ça veut dire "demain on peut changer d'avis", alors pas la peine dans un journal perso de ré-utiliser les éléments de langage du département marketing, tu as dis que c'était un avis perso, écrit perso sans l'aide des éléments de langage du département marketing de Mozilla. Le journal est très intéressant à lire, continue, mais à mon avis il le serait encore plus si il contenait un peu moins de marketing "on est les meilleurs les autres sont nuls".
Je ne dis pas que c'est nul de faire asm.js, il faut tenter, mais pas la peine de critiquer autant son concurrent, surtout en se cachant les qualités du fait de certains choix (perfs) et sans regarder à moyen/long terme les évolutions (pour pas parler d'un truc qui ne sera plus valide dans quelque mois quand ce qu'on va sortir sortira), ce choix a pour le moment un problème énorme face à son concurrent (les perfs!!!), alors pourquoi autant critiquer son concurrent dont l'objectif (les perfs) n'est pas rempli par ce qu'on propose à la place, ça fait un peu louche sur la com' marketing…
Après, quel que soit la solution technique proposée, que le meilleur gagne!
[^] # Re: Pas convaincu
Posté par patrick_g (site web personnel) . Évalué à 9. Dernière modification le 04 avril 2013 à 11:46.
Il me semble que dans toute ton argumentation tu établis un parallèle absolu entre Google et Mozilla. Tu dis des gens de Mozilla qu'ils font les choses "comme dans toutes les boites", tu évoques les stratégies marketing, etc.
Le message de Littleboy au-dessus parle de "la ligne de l'entreprise".
Ce serait bien de se souvenir que si Google est une entreprise et que son but est de faire du profit, de l'autre côté Mozilla est une fondation à but non lucratif. Pour moi cela change absolument tout en terme de confiance qu'on peut accorder à l'une et pas à l'autre. Les mettre sur le même plan c'est méconnaitre cette différence fondamentale.
Et qu'on ne vienne pas me sortir la MoCo parce que c'est une entité au service de la MoFo:
[^] # Le fond plutôt que la forme
Posté par Zenitram (site web personnel) . Évalué à 5.
Comme tu le dis : pour toi. Pour moi, ça ne change rien, c'est composé dans les deux cas de personnes qui en tirent un revenu, avec les conséquences qui en découlent. SA ou Loi 1901 sont des enveloppes fiscales, aucune des deux n’empêchent ni "de faire le bien", ni de'orienter l'argent dans les poches qu'on veut, ce n'est pas ça qui va changer le fond (qui peut être différent, c'est une autre histoire, je dis juste que je ne me base pas sur l'enveloppe fiscale pour juger). Tu t’attaches à la forme, je m’intéresse au fond.
Non, je dis personnellement que dans les deux cas, il y a de l'argent qui transite vers des personnes physiques.
Tu mets, toi, un importance fondamentale dans cette différence, mais moi, je ne met aucune importance dans cette différence sur les réactions humaines (que le directeur de l'entité soit une homme ou une femme, que le comptable soit noir ou blanc, que la forme financière soit "non profit" ou SA, c'est des choses qui n'ont pas grand chose à voir avec la direction prise par l'entité), merci de laisser aux gens la liberté de décider subjectivement (car autant pour toi que pour moi, utiliser la forme de l'entité pour imaginer des choses autre que la forme de l'entité, c'est subjectif) de ce qui est une différence fondamentale (si tu fouilles dans les assos 1901 en France, tu seras choqué de voir que certaines ont pour but de filer un salaire à une personne, bref, d'être lucratif, car seule l'entité crée est à but non lucratif, pas les gens qui composent cette entité, donc non ce n'est pas fondamental pour moi).
Ce serait bien de se souvenir que Google et Mozilla sont composés d'être humains, et que ton point de vue subjectif n'est pas forcément le point de vue (autant subjectif) d'autres personnes. (je n'aime pas le "Ce serait bien de se souvenir" qui fait pompeux, mais je ne fais que reprendre le ton de ton message ;-) ).
[^] # Re: Pas convaincu
Posté par Benoit Jacob (site web personnel) . Évalué à 7.
Native Client non plus n'a pas 100% des perfs "natives" hein. Et les 50% de asm.js ne sont que ce que un type seul a été capable de faire en 3 mois. On ne sait pas encore jusqu'où asm.js va pouvoir aller mais a priori on ne voit pas de raison pour qu'il plafonne en dessous de ce que peut faire un autre langage intermédiaire.
D'autre part ton commentaire suggère que tu crois que l'utilisation du CPU est proportionelle à la consommation de batterie; ça n'est pas le cas.
Tant que PNaCl n'est pas sorti il n'y a aucune raison de croire que c'est faisable, puisque PNaCl cherche à utiliser la représentation intermédiaire de LLVM et les devs de LLVM ont averti que c'était une mauvaise idée.
Mozilla n'a jamais proposé un ensemble de technologies qui viendrait à remplacer tous les standards du Web par un ensemble d'APIs décidées par Mozilla seul. Ça demanderait un sacré culot. C'est ce que Google fait avec Pepper.
Le parallèle avec H264 ne marche pas. La raison de rejetter H264 initialement n'avait rien à voir avec la raison de rejetter Pepper. H264 était rejeté parce que non libre de droits et donc impossible à implémenter directement dans Firefox. Le problème avec H264 est que Firefox va devoir se reposer sur les codecs système ce qui va conduire à des cas où une même page Web peut s'afficher ou pas suivant des détails de ton système. C'est un problème de portabilité.
[^] # Re: Pas convaincu
Posté par Zenitram (site web personnel) . Évalué à 3.
tant mieux! Je n'ai pas dit le contraire, et je souhaite bonne chance à cette technologie.
C'est un exemple. La consommation a quand même une importance.
Donc :
- techno Mozilla : pas de bonne perfs, mais pas de raison de croire que ce n'est pas faisable
- techno Google : pas encore la, mais pas de raison de croire que c est faisable
Euh… Désolé de ne pas me positionner en fonction de l'entité.
Donc je fais comme ce que tu fais à propos de Google : tant que ce n'est pas fait, pas de raison de croire que vôtre idée marchera.
Donc le problème est zappé, pas grave, quand on veut un autre marché on met de côté les principes "super méga importants". Désolé, mais comme ça a été fait au moins une fois, si asm.js ne remplit pas son objectif (perfs), je ne doute pas que ce sera le même changement sur le style Native Client. Quand on a changé une fois un truc "super mega important pour le web", on peut changer deux fois (pour la même raison, ne pas laisser l'espace vide).
[^] # Re: Pas convaincu
Posté par claudex . Évalué à 4.
Vu que ceux qui sont à l'origine de la technique que Google veut employer déconseille fortement de l'utiliser pour ce but là, ça me semble une bonne raison de ne pas y croire.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas convaincu
Posté par Zenitram (site web personnel) . Évalué à 2.
Si on écoutait tous ceux qui sont "à l'origine" d'une chose, pas mal de choses n'auraient pas été inventées / améliorées…
[^] # Re: Pas convaincu
Posté par groumly . Évalué à 2.
Ca veut dire que s'il bosse 9 mois dessus on aura 150% des perfs du natifs?
Plus serieusement, sorti du hardcore gamer, le jeu video n'est pas cpu bound - apres tout flash avec ses performances miserables a tenu le haut du pave sur le web pendant un long bail, et actionscript est pas si different de js dans le fond.
De meme, le monde du jeu video tablette/smartphone a commence a decoller avec le 3gs et l'original ipad, c'est loin d'etre des foudres de guerres aussi.
Ca veut pas dire que c'est pas bien de faire du js qui va plus vite, mais si tu penses que c'est tout ce qu'il manque pour faire un succes du jeux video sur le web, tu te fourvoies.
Un bon ide avec un bon tooling et un bon debuggeur me semblent plus important que grapiller des pourcents de performances, surtout si tu t'addresses a des gens qui viennent du monde natif et qui sont habitues a avoir des outils, mais ca reste mon avis perso.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Pas convaincu
Posté par devnewton 🍺 (site web personnel) . Évalué à 2.
Ce n'est plus vrai depuis l'avènement des moteurs physiques 2d.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas convaincu
Posté par freem . Évalué à 2.
Ca tombe bien, on parle de compiler du C++ en asm.js. Côté IDE, le C++ n'a peut-être pas les meilleurs (langage trop complexe pour l'auto-complétion, notamment) mais possède certainement de bons outils malgré tout.
En fait, c'est surtout ça qui m'a intéressé quand j'ai lu l'article: pouvoir faire du "dev web" en utilisant un langage fortement typé et faire des tests de débogage en natif avec au final assez peu de modif à faire pour le transformer en web ensuite.
Le gain de performance contre l'asm.js ne me semble également pas négligeable, et côté du "code écrivable et lisible à la main" je suis désolé mais l'argument ne tiens pas trop, JS est pas vraiment un modèle quand on parle de choses lisibles. Rien que l'absence de typage… bon, après, ce dernier point est un avis très personnel, bien sûr.
De toute façon, le "code lisible" est obfusqué quand ils veulent nous passer des saloperies, alors je me demande si ça importe réellement.
[^] # Re: Pas convaincu
Posté par groumly . Évalué à 4.
Un plaisir a debugger, google a essayer de vendre ca avec gwt, yen a quelques un qui en sont revenus. Sans compter que tu te prends a la fois la lourdeur de langage, les temps de compile et des debuggueurs tout pourris.
Ou alors tu codes tout en c++ et tu fais une conversion a la fin, mais
1) tu vas te taper une palanquee de code en c++ "pour rien": creation de fenetre, gestion d'input, scripts de builds
2) ta phase de qa en js va etre absolument horrible, tu te tapes tout d'un coup et tu vas prier pour ne pas avior deux problemes en paralleles.
C'est quoi le probleme de lisibilite du js? Face a de l'abus de template c++, j'ai vite fait mon choix perso.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Pas convaincu
Posté par freem . Évalué à 1.
gwt? Je ne connais pas. A part ça, je trouve le code machine plutôt simple a déboguer oui, bien que linux soit très loin de proposer des débogueurs avec une IHM aussi efficace que ce que l'on peut trouver sous windows.
Il n'y a pas besoin de gérer l'input en JS? Et niveau création de fenêtres… il semble qu'asm.js supporte openGL, alors utiliser un gui toolkit qui exploite openGL me semble permettre de s'affranchir de ce souci. Accessoirement, j'ai plutôt tendance à faire une lib qui fasse le job réel, et ensuite des interface.
Devines laquelle je fais en 1er?
Interface console. Pas de fenêtre, et juste de l'entrée clavier. Voire même pas d'interface du tout, pour ceux utilisant les tests unitaires.
L'intérêt? Mon code est coupé, avec une partie qui est totalement indépendante du système au sein duquel elle s'exécute.
Parce que tu fais souvent du QA sur de l'asm toi?
Je n'ai pas eu l'impression que le binaire (si on peut dire ça comme ça) asm.js soit destiné à être utilisé pour déboguer le programme. Bien entendu, aucun programme n'est exempt de bugs.
Oui, c'est sûr, quand on abuse d'une fonctionnalité, on risque de galérer. Enfin, sinon, y'a les typedef, couramment utilisés par ceux usant des template.
Du coup, on a l'écriture template qu'une seule fois: pendant le typedef. Après, on crée un type, et ça deviens tout à fait lisible.
Enfin, je conçois que ce soit personnel, d'autant que l'absence de typage, par exemple, est vraiment quelque chose qui me gêne, peu importe le langage.
J'imagine qu'ensuite, c'est une question d'idiomes et de conventions de nommage dans les deux langages (la notation polonaise, qui consiste à indiquer le type dans les noms de variable me gonfle si le langage est typé, alors que dans le cas contraire, elle me semble quasi vitale, par exemple).
[^] # Re: Pas convaincu
Posté par groumly . Évalué à 2.
Faut se tenir au courant si tu veux te faire l'evangeliste du web mon canard ;-)
Sinon, le probleme, c'est pas debugger du c++, c'est debugger du c++ convertit en js qui tourne dans un browser. C'est ce que gwt propose, et c'est un enfer a debugger quand t'as un bug dans la version de production de l'appli.
Sisi, ya besoin de gerer l'input. Mais je doute que Qt, GTK ou la SDL soit contents une fois sandboxes dans un browser, et donc va falloir un code different pour les 2 versions.
Je vais pas dire que c'est une mauvaise chose de decoupler le domain de la presentation, parce que clairement ca l'est pas, par contre se fader 2 implementations de la presentation pour le plaisir, comment dire?
Heu, ben ouais, tout le temps. On s'en fout que ca tourne en debug dans mon IDE, ce qui compte c'est que ca marche sur le poste des utilisateurs… Mon automation tourne sur des builds release sur device, pas grand chose a faire que ca marche dans mon simulateur en debug si la version de l'appstore plante.
Si tu t'amuses a ecire un jeu en c++, faire ta qa sur le build natif, passer tes qq centaines de milliers de lignes de code a travers un outil de generation et balancer ca sur le web dict, tu vas avoir qq surprises.
Un code natif en -02 est tres chiant a debugger, mais au moins c'est faisable. Bon courage pour trouver le probleme quand t'as une couche de traduction. Le monsieur du journal le dit a mot couvert: si t'as un pb, c'est probablement dans la traduction (et encore…), bonne fete des morts pour le corriger la dedans si t'es pas sur la core team emscripten…
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Pas convaincu
Posté par Larry Cow . Évalué à 2.
Tu peux assez facilement t'en rendre compte par toi-même : http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Demos et les limitations sont décrites ici : http://vps2.etotheipiplusone.com:30176/redmine/projects/emscripten-qt/wiki/Wiki#Many-C-Qt-apps
Disons que les entrées n'ont pas l'air d'être le plus ennuyeux ;)
[^] # Re: Pas convaincu
Posté par Zenitram (site web personnel) . Évalué à 1.
De quelles entrées parlez-vous? Parce que tu peux prendre l’exemple de Kate (cf tes liens), fait "Fichier" --> "Ouvrir", et tu ne vas rien comprendre (tes fichiers à toi? Pas la!). C'est la qu'on voit que le portage de Kate est ridiculement fait, sans adaptation, inutilisable, car il manque l'essentiel (accéder aux fichiers à éditer).
Et les fichiers de ton disque dur, c'est une entrée il me semble, et c'est très ennuyeux (ceci dit, c'est ennuyeux avec NativeClient aussi, aucun des deux n'expose le système de fichier de l'utilisateur)
[^] # Re: Pas convaincu
Posté par claudex . Évalué à 2.
Il parle des entrées souris/clavier. Vu que n'est qu'une PoC pour montrer qu'Emscripten est capable de compiler, c'est un peu normal que ce ne soit pas parfait.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas convaincu
Posté par freem . Évalué à 1.
Ce qui résume en quelque sorte ce que je voulais dire: si ton natif tourne sans bug (pays des bisounours, tout ça…) et que l'appli bug, ce n'est pas nécessairement la faute de ton code, mais ça peut provenir d'un compilateur encore très jeune.
Avant d'utiliser cet outil en production, il me semble évident qu'il ait au moins pris un peu d'âge. Un bon whisky se fait pas en un an… (j'étais parti sur le vin, mais j'ai pas envie de troller sur le beaujolais nouveau :D )
Les bugs de compilo, ça existe, mais quand tu es amené à les déboguer (en natif sur ton application bien entendu) j'ai plutôt envie de dire que tu débogue le compilo que ton appli, non?
Après, c'est sûr, GCC ou VC++ sont plutôt propres, mais ils ont combien d'années derrière eux? Clang commence à bien marcher, mais il me semble qu'il n'est pas encore exempt de bogues (Après, je ne sais pas la fraîcheur de cette page).
Mais ça fait quand même quelques années qu'il existe: wikipedia me dit 2005 (survol très, très rapide de l'article) soit 8 ans.
[^] # Re: Pas convaincu
Posté par Ontologia (site web personnel) . Évalué à 2.
N'oublie pas qu'il y a ici un biais : le code généré en asmjs est généré à partir du bytecode LLVM qui est assez bas niveau.
Si tu regardes la spec de asmjs tu peux constater que c'est essentiellement un javascript classique qui doit être statiquement typé, le reste est moins fondamental (Bon, si, faut éviter les lambda et l'ordre supérieur en général ).
Statiquement typé signifie simplement qu'on explique bien clairement au compilateur que c'est du int/float/whatever et on ne change surtout pas le type de la variable en cours de route.
L'impression de bytecode est un peu biaisé si tu lis la spec. Le bytecode c'est plus une sorte d'assembleur, asm.js c'est plutôt du javascript écris comme du C-- sans pointeur.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Pas convaincu
Posté par GTof . Évalué à 5.
D'après la spec d'asm.js, j'ai clairement l'impression que c'est le but recherché. Mais au lieu d'introduire un nouveau langage incompatible avec l'existant en espérant que tout le monde se mettent dessus, ils ont étés malins en créant un langage dédié au cœur même de javascript. Je ne serais pas surpris que d'ici quelques mois le couple emscripten+asm.js supporte les opérations vectorielles. Quant aux structures à la C ou a une gestion semi-manuelle de la mémoire, rien ne les empêche d'introduire dans la spec quelques contraintes pour simplifier l'analyse de flot de donnée pour optimiser la création/destruction d'objets.
De manière générale, vu qu'ils voient javascript comme un langage cible et non un langage source, ils peuvent contraindre autant que nécessaire la forme des programmes valides en asm.js tant qu'emscripten est capable de générer du code correspondant.
[^] # Re: Pas convaincu
Posté par devnewton 🍺 (site web personnel) . Évalué à 0.
C'est une idée de génie pour réussir le coup de force, mais on va perdre un des atouts du web: pouvoir lire et écrire simplement des pages.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas convaincu
Posté par barmic . Évalué à 7. Dernière modification le 04 avril 2013 à 10:24.
Le fait d'avoir un langage différent entre ce que tu écris et ce qui s'exécute sur le navigateur n'a rien de nouveau (les compresseurs/obfuscateurs, coffescript, dart, GWT/pyjama, etc).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas convaincu
Posté par devnewton 🍺 (site web personnel) . Évalué à -2.
Ce qui montre bien que javascript est Le problème du web :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Pas convaincu
Posté par barmic . Évalué à 2.
Non c'est l'un des problèmes. HTTP 1.1 en est un autre (pas pour rien que Google sort SPDY et que HTTP2 est en route) et HTML aussi. Si on veut repartir de 0, javascript ne sera pas le premier truc à améliorer, mais l'existant est là et bien implanté.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Pas convaincu
Posté par claudex . Évalué à 3.
Tu oublie les CSS.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pas convaincu
Posté par psychoslave__ (site web personnel) . Évalué à 2. Dernière modification le 04 avril 2013 à 13:57.
Et html.
<br>On a fait le tour là, non?[^] # Re: Pas convaincu
Posté par GnunuX (site web personnel) . Évalué à 1.
Ce n'est pas déjà le cas avec Valve/Steam ? Il me semblait que la connexion internet était obligatoire pour jouer.
[^] # Re: Pas convaincu
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Souvent, mais pas toujours.
Heureusement il est encore possible d'acheter des jeux jouables offline.
Ce que je crains avec html5, c'est que les développeurs rendent la connexion obligatoire sans faire exprès ou par paresse.
Rendre un jeu html5 jouable hors ligne, ça demande un développement bien particulier: http://smus.com/game-asset-loader/
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Intéressant, mais...
Posté par freem . Évalué à 5. Dernière modification le 03 avril 2013 à 17:14.
Du coup, ça veut aussi dire que "l'écriture" d'applications JS sera moins pénible, non? (De ce que j'entends de nombreux dev web, ce langage est horrible…)
Ce sera peut-être pour moi une occasion de m'y mettre :D (ou de faire semblant pour le coup)
Accessoirement, il existe des toolkit graphique exploitant opengl en C++, donc logiquement, une application les utilisant devrait être "portable" sur un navigateur assez aisément, non?
D'autres questions que je me pose, plus orientées compatibilité entre langages:
Au passage, même si 50% de la vitesse du natif c'est déjà moins pire, c'est encore loin d'être la panacée…
[^] # Re: Intéressant, mais...
Posté par Benoit Jacob (site web personnel) . Évalué à 5.
Emscripten est basé sur LLVM, et supporte donc tous les langages qui ont un front-end LLVM. Par exemple, pour compiler du C/C++ on utilisera généralement Clang, qui supporte très bien le C et le C++ (y compris une bonne partie du C++11), va donc voir leur site web… et oui, bien sûr, C est un langage séparé du C++, Clang le sait très bien…
[^] # Re: Intéressant, mais...
Posté par _seb_ . Évalué à 4.
Sur la page Officiel Emscripten:
Emscripten is an LLVM to JavaScript compiler. It takes LLVM bitcode (which can be generated from C/C++ using Clang, or any other language that can be converted into LLVM bitcode) and compiles that into JavaScript, which can be run on the web (or anywhere else JavaScript can run).
En résumé, tous les langages compilables par LLVM peuvent être transcrits en JS via Emscripten.
Il y a pas mal de limitations dans Emscripten. La liste des anomalies (https://github.com/kripken/emscripten/issues) donne déjà le sentiment qu'on n'en est qu'au début du projet.
# Il manque quelques infos
Posté par reno . Évalué à -2.
Puisque asm.js est soi-disant portable puisque du Javascript, ce serait intéressant de connaitre si cette démos tourne sur Chrome et IE et à quelle vitesse..
Soit dit en passant si ni Chrome ni IE n'implémentent asm.js, je ne vois pas trop la différence entre asm.js et NativeClient: dans les 2 cas en pratique c'est du "browser-spécifique".
[^] # Re: Il manque quelques infos
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
asm.js, c'est un sous-ensemble de javascript…
"La première sécurité est la liberté"
[^] # Re: Il manque quelques infos
Posté par devnewton 🍺 (site web personnel) . Évalué à 0.
Et en pratique, soit tu fais un dev spécifique, soit tu as un jeu si lent qu'il est inutilisable?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Il manque quelques infos
Posté par Nicolas Boulay (site web personnel) . Évalué à 10. Dernière modification le 03 avril 2013 à 18:00.
Tu es bien le dev d'un petit jeu 2D, tu va pas me faire croire que 3 sprites qui se batte duel ont besoin de 10 giga opération par seconde pour être fluide. Surtout que la partie graphique est native !
asm.js est simplement un moyen d'écrire du javascript qui sera correctement optimisé car typé (entre autre).
On parle tout de même d'unreal engine 4 (c++) qui tourne à 50 fps !
"La première sécurité est la liberté"
[^] # Re: Il manque quelques infos
Posté par devnewton 🍺 (site web personnel) . Évalué à 6.
Je cherche du monde pour m'aider à le porter sur d'autres plateformes, si tu veux essayer d'en faire une version html5, je fournirais toute l'assistance nécessaire!
Sur quelle machine?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Autre avis.
Posté par Gof (site web personnel) . Évalué à 9.
À lire aussi cet article qui parle en mal de asm.js:
http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html
En gros, essayer de rendre performant un pseudo-subset de javascript serait sous optimal comparé à d'autre alternative qui serait de remplacer javascript par un langage plus performant sur les navigateurs.
[^] # Re: Autre avis.
Posté par barmic . Évalué à 7.
Merci captain obvious !
Maintenant la question c'est est ce que dart ou typescript ont l'air d'avoir du succès ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Autre avis.
Posté par claudex . Évalué à 10.
Et d'ici à ce que tout le monde ce mette d'accord sur le langage et ses spécifications, on en sera à Firefox 42 000. Alors qu'asm.js tourne déjà aujourd'hui sur tous les navigateurs.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Autre avis.
Posté par devnewton 🍺 (site web personnel) . Évalué à -8.
Seulement ceux qui le prenne en charge ou alors ça doit être inutilisable.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Autre avis.
Posté par claudex . Évalué à 10.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Autre avis.
Posté par Gof (site web personnel) . Évalué à 4.
Pareil avec dart par exemple, puisque dart peut être transformé en javascript pour les browser qui ne le supportent pas en natif.
[^] # Re: Autre avis.
Posté par claudex . Évalué à 3.
Il doit même être possible d'adapter Dart pour sortir de l'asm.js mais ça ne devient différent à utiliser Emscripten.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Autre avis.
Posté par Ontologia (site web personnel) . Évalué à 5.
Certes, mais la masse de code de JS étant ce qu'elle est, je pense que c'est trop tard maintenant. C'est un risque trop gros de passer à un autre langage, surtout avec les années de maturation que ça va nécessiter et sans parler des problèmes de compatibilité entre navigateurs…
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Je viens de tester avec Firefox 19.0.2
Posté par Pierre . Évalué à 8. Dernière modification le 03 avril 2013 à 20:01.
Je viens de lancer le jeux sur une machine raisonnable (pour moi) : archlinux à jour, I5 2.9Ghz et une carte nvidia GT 530 avec le pilote Nouveau.
J'ai utilisé la config par défaut du jeux en basse résolution (800x600) et un bot, j’obtiens 15à 20fps donc c'est à peu près utilisable contre un bot mais surement pas contre un humain, j'ai essayé brièvement en 1600x1200 ca variait entre 5 et 9 fps.
Puis j'ai joué à Sauerbraten en 1600x1200 et beaucoup plus d'effets activé sur une carte plus grande avec beaucoup de bots j'ai toujours plus de 100 fps.
Ça ne se compare pas encore au jeu d'origine, mais c'est quand même très loin devant ce qu'un jeu flash peu faire.
[^] # Re: Je viens de tester avec Firefox 19.0.2
Posté par Benoit Jacob (site web personnel) . Évalué à 6. Dernière modification le 03 avril 2013 à 20:24.
Sous X11 pour avoir des perfs correctes dans Firefox, il faut activer l'accélération matérielle du compositeur: va dans about:config et mets layers.acceleration.force-enabled à true.
Bien sûr l'idée est qu'on aura activé ça par défaut d'ici que les jeux Web se répandent. C'est déjà activé sur toutes les autres plateformes, mais sous X11 on a des problèmes compliqués, voir https://wiki.mozilla.org/Platform/GFX/X11GLLayers
D'autre part Firefox 19.0 n'a pas encore les optimisations asm.js. Pour ça il faut Firefox 22 (en Nightly pour le moment)
[^] # Re: Je viens de tester avec Firefox 19.0.2
Posté par Pierre . Évalué à 5.
Effectivement avec l'option layers.acceleration.force-enabled à true, j'ai une légère accélération , le jeu tourne entre 20 et 25 fps, 25% de gain en fps c'est pas mal.
[^] # Re: Je viens de tester avec Firefox 19.0.2
Posté par Benoit Jacob (site web personnel) . Évalué à 5.
Voila, maintenant tu dois être CPU-bound, alors essaye Firefox Nightly et là avec asm.js les perfs devraient être vraiment bonnes.
[^] # Re: Je viens de tester avec Firefox 19.0.2
Posté par claudex . Évalué à 5.
Le pilote (Nouveau) ne risque pas aussi d'être une source de ralentissement ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Je viens de tester avec Firefox 19.0.2
Posté par Benoit Jacob (site web personnel) . Évalué à 3.
peut-être, mais là Pierre semble indiquer que le même jeu tourne nettement plus vite en natif qu'en Web sur la même machine.
[^] # Re: Je viens de tester avec Firefox 19.0.2
Posté par claudex . Évalué à 4.
Je ne sais pas si le jeu natif utilise les mêmes instructions opengl.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Je viens de tester avec Firefox 19.0.2
Posté par Benoit Jacob (site web personnel) . Évalué à 3.
Le jeu natif utilise un mélange de OpenGL 1 et 2. Le jeu Web n'utilise bien entendu que WebGL, ce qui est une traduction assez directe pour les appels OpenGL 2, et une traduction plus compliquée pour les appels OpenGL 1. Si, sur le pilote nouveau, les appels OpenGL 1 sont beaucoup plus rapides que leur traduction WebGL faite par Emscripten, alors oui ça pourrait expliquer une différence. Mais je ne crois pas à priori que ce soit le cas, et aussi, je crois (sans en être certain) que Sauerbraten n'utilise des appels OpenGL 1 que pour l'interface utilisateur, qui ne devrait pas représenter une part importante du rendu.
[^] # Re: Je viens de tester avec Firefox 19.0.2
Posté par mackwic . Évalué à 1.
Je ne comprend pas pourquoi se limiter a OpenGL <=2 alors que OpenGL 4 est supporté depuis bien longtemps par tout le monde et qu'il apporte des features indispensables d'un point de vue performance. On parle d'un moteur 3D professionnel, pas d'Ogre3D ou de XNA !
Comment WebGL peut-il se permettre de se limiter a OpenGl 2 ?
EDIT: Ah, c'est OpenGL ES 2.
[^] # Re: Je viens de tester avec Firefox 19.0.2
Posté par claudex . Évalué à 4.
J'ai un doute là-dessus, il faut déjà une carte AMD ou nVidia, ou une Intel récente sous Windows pour le desktop, et pour le mobile, je ne suis pas sûr qu'il ait grande chose de compatible. Le but, ce n'est pas d'avoir des sites web accessible à 5% de la population.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Je viens de tester avec Firefox 19.0.2
Posté par Olivier Serve (site web personnel) . Évalué à 3.
Genre Mesa (donc pilotes intel, AMD & nVidia libres) qui ne gère pas encore OpenGL 3.2…
[^] # Re: Je viens de tester avec Firefox 19.0.2
Posté par Pierre . Évalué à 4.
Je viens de retester avec la version Nightly 23.0a1 , toujours dans les mêmes conditions de jeu,c'est maintenant à 30-35 fps. C'est encore 3 fois moins rapide que Sauerbraten mais ça a doublé par rapport au 1er essais.
Puis j'ai changé de carte , je suis passé sur 2 tower (pour admirer les reflets sur l'eau), qui est beaucoup plus grande , et dans ce cas la je fus surpris de voir les fps augmenter à 40-45 , ce qui est parfaitement jouable, le fait d'activer les effets (même ceux marqué comme lent) ne change pas grand chose à la vitesse du jeu, j'ai donc ajouté plusieurs bots et là j'ai vu des ralentissements des que les bots étaient proche de moi, ça passait a 30 fps voir un peu moins.
[^] # Re: Je viens de tester avec Firefox 19.0.2
Posté par zebra3 . Évalué à 2.
J'ai pas tout compris : je pensais qu'asm.js permettait des optimisations qui marchaient sur tous les navigateurs. Mais à ce que je lis de ton commentaire, il faut aussi que le navigateur le prenne en compte ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Je viens de tester avec Firefox 19.0.2
Posté par claudex . Évalué à 6.
asm.js permet des optimisations sur tous les navigateurs. Mais prendre en compte asm.js permet d'être beaucoup plus performant.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Je viens de tester avec Firefox 19.0.2
Posté par Gof (site web personnel) . Évalué à 5.
Si c'était le cas, il n'y aurais pas besoin d'asm.js.
rajouter des |0 ou autre pour annoter des types est une astuce qui existait déjà avant asm.js, depuis que V8 fait de la détection de type.
asm.js consiste à implémenter un compilateur spécial qui reconnait un dialecte spécial de javascript.
Quelqu'un d'autre aurais pu faire la même chose. mais si ils prennent d'autre convention alors asm.js est inutile.
Par exemple, a|0 est choisis par asm.js pour spécifier un entier, mais ils auraient pu prendre ~~a ou a&0xffffffff.
Ils ont aussi ajouté une fonction "imul" dans leur stdlib. Quelqu'un d'autre aurait pu choisir "integer_multiplication" comme nom.
Si dans du code asm.js on commet une seule erreur et utilise quelque chose qui n'est pas valide asm.js, alors le compilateur asm.js n'est pas utilisé et le compilateur javascript normal est utilisé.
Bref, asm.js est un nouveau langage.
# Quelques points en vrac
Posté par kursus_hc . Évalué à 10.
C'est très impressionnant, bravo, j'ai eu l'impression de voir s'écrire une petite ligne de l'histoire du web.
A Mozilla : Merci de vous prendre la tête pour continuer la bataille du web ouvert; à l'heure où certains pensent sincèrement qu'une hégémonie de webkit simplifierait bien les choses, l'histoire de Native Client et son API maison rappelle un peu "les heures sombres de l'histoire du web". La tentation sera de toute façon toujours là, c'est un travail de Pénélope et ça rend la lutte encore plus noble. Alors merci de garder cette cohérence dans vos principes, vous êtes les seuls qui méritez ma confiance.
Ca tourne beaucoup mieux sur Chromium que sur Firefox chez moi (même avec l'accéleration). En fait de manière générale, la différence de vitesse entre le moteur js de Chrome et celui de FF me saute aux yeux à chaque demo utilisant intensivement le javascript. D'où mes questions : Suis-je le seul à voir ça ? Quelle est la position de Mozilla sur la question ? Est-ce que ce nouveau projet sera l'occasion d'améliorer le moteur ?
Ha ouais ?! Et "Move with WASD" c'est portable ça ?! ;)
(J'en rigole mais c'est un vrai problème, si quelqu'un a une solution..)
[^] # Re: Quelques points en vrac
Posté par Benoit Jacob (site web personnel) . Évalué à 7.
La position de Mozilla sur ça c'est que c'est la beauté du Web que nos propres démos marchent mieux sur un navigateur concurrent, et qu'on doit continuer de travailler à améliorer les perfs :-) Ensuite, si tu essayes Firefox 22 (Nightly) ça devrait quand même être nettement plus rapide que la version stable actuelle.
Pour WASD, je n'ai pas de clavier Azerty ici pour tester, je pensais naivement que le jeu utiliserait des keycodes insensibles à la disposition du clavier… en tout cas, il devrait. A ce moment là il suffirait d'ajouter une API pour savoir à quel caractère correspond un keycode, si ça n'existe pas déjà.
[^] # Re: Quelques points en vrac
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Ou juste permettre de configurer les touches…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Quelques points en vrac
Posté par Benoit Jacob (site web personnel) . Évalué à 2.
C'est déjà possible non? Touche en dessous de Echap pour afficher le menu du jeu… (je ne peux pas tester maintenant).
[^] # Re: Quelques points en vrac
Posté par barmic . Évalué à 2.
Oui avec 0
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# syntaxe asm.js
Posté par lendemain . Évalué à 2.
Pourquoi asm.js à choisie une syntaxe avec des opérateurs sur les bits, plutôt que des annotations dans des commentaires pour définir le typage?
[^] # Re: syntaxe asm.js
Posté par Benoit Jacob (site web personnel) . Évalué à 8. Dernière modification le 03 avril 2013 à 23:55.
Je ne suis sûr de rien parce que ce n'est pas mon domaine, mais je crois que c'est parce que asm.js opère sous la contrainte qu'il doit rester un sous-ensemble du JavaScript, et non un sur-ensemble: il ne peut pas rajouter de nouvelle syntaxe pour spécifier les informations de typage. Des annotations en commentaire reviendraient à une extension du langage. Donc il doit ruser en utilisant des aspects peu connus de JavaScript, tels que le fait que l'opérateur | (le OU bit-à-bit) a toujours une sémantique «entier 32 bits» et donc que (x|0) sera toujours un entier sur 32 bits quel que soit x.
[^] # Re: syntaxe asm.js
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
C'est surtout qu'un autre compilo javascrit optimisant qui n'a jamais entendu parler de asm.js fera aussi du code plus rapide qu'avec du code classique.
"La première sécurité est la liberté"
# Les jeux oui, mais pas que
Posté par Goffi (site web personnel, Mastodon) . Évalué à 6.
Ce projet est assez excitant. Je comprends bien l'intérêt de poser la carte des jeux, mais il y a un potentiel assez énorme quand on voit qu'un projet comme Qt, ou Kate on été compilés, malgré les nombreuses dépendances Kde pour le deuxième.
Il y aussi un exemple avec sqlite compilé sur le site. Vu la masse de code libre disponible en C/C++, le butineur devrait devenir une sorte de VM très intéressante. Même si je suis partisan des applications natives, je suis ça avec intérêt, et c'est une très bonne chose que Mozilla arrive encore à mener la danse. Bravo pour les idées et le boulot réalisé.
Le premier effet visible va probablement être la fin définitive du Flash, il n'a plus aucune raison d'être avec ça (enfin pratiquement, pour les visioconférences par exemple est-ce que l'accès aux webcams est faisable en l'état en JS/HTML 5 ?).
Je verrais bien les bibliothèques Python basées sur du C utilisables avec Pyjamas aussi :). Pygame dans un navigateur ?
[^] # Re: Les jeux oui, mais pas que
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Ca doit être faisable, emscripten gère la SDL sur laquelle est basé pygame.
Ca veut dire faire interpréter du python par du javascript après compilation en C++.
Mince, un détecteur de WTF tout neuf!
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Les jeux oui, mais pas que
Posté par Goffi (site web personnel, Mastodon) . Évalué à 4.
Ce n'est somme toute pas très différent de faire interpréter du Python par une VM après compilation en Java (genre comme Jython quoi).
[^] # Re: Les jeux oui, mais pas que
Posté par Jean B . Évalué à 4.
Oui, c'est encore assez expérimental, mais même IE à prévu de l'implémenter, donc ça se profile pas mal.
[0] http://www.html5rocks.com/en/tutorials/getusermedia/intro/?redirect_from_locale=fr
[1] https://developer.mozilla.org/en-US/docs/WebRTC/navigator.getUserMedia
[2]http://blogs.msdn.com/b/ie/archive/2011/12/09/media-capture-api-helping-web-developers-directly-import-image-video-and-sound-data-into-web-apps.aspx
[^] # Re: Les jeux oui, mais pas que
Posté par kursus_hc . Évalué à 4.
Une seule : l'obscurantisme. Et manque de pot ça intéresse pas mal de monde.
[^] # Re: Les jeux oui, mais pas que
Posté par Larry Cow . Évalué à 4.
Même pas : un code asm.js n'est pas ce qu'il y a de plus lisible (déjà qu'un code .js généré par Emscripten est rarement bitable…). Concrètement, l'intérêt de promouvoir l'opensource va devenir d'autant plus fort : beaucoup de gens prennent encore le fait d'avoir accès au code source (libre ou non) comme un acquis, dès qu'on parle de Web.
[^] # Re: Les jeux oui, mais pas que
Posté par freem . Évalué à 2.
Mais l'open source, ça sert à rien si ta source est illisible.
Côté obscurantisme, on peut très facilement rendre illisible n'importe que code source, et à ce que j'ai cru comprendre des rumeurs du net, les entreprises ne s'en privent pas quand on parle de JS…
[^] # Re: Les jeux oui, mais pas que
Posté par groumly . Évalué à 2.
Des rumeurs comme quoi des entreprises obfusqueraient du js? Spapossible, j'le crois pas!
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Les jeux oui, mais pas que
Posté par freem . Évalué à 1.
J'ai parlé de rumeurs pour éviter qu'on me demande une source :D
# pourquoi pas du js converti en asm.js
Posté par fabien . Évalué à 2.
Salut,
Ouais c'est super de prendre du C++ pour le passer sur asm.js
mais dans quelle mesure serait-il capable de prendre du javascript tout lent et de le convertir en asm.js et le tout à la volé,
En gros, baser le moteur de javascript sur asm.js
On ameliorerait ainsi instentanement toutes les pages web ayant du js, bref 99% des pages quoi…
[^] # Re: pourquoi pas du js converti en asm.js
Posté par Zenitram (site web personnel) . Évalué à 3.
Et comment asm.js connait ce qui manque? relit bien… asm.js se base sur des informations en plus, que tu ne fournis pas en JS. Pour convertir, il faut les informations. Sans compter qu'il faut supporter JS (et non, asm.js ne supporte pas JS, puisque c'est un sous-ensemble!).
Bref, ben tout ce qui est possible de faire en JS est déjà dans le moteur JS…
[^] # Re: pourquoi pas du js converti en asm.js
Posté par fabien . Évalué à 2. Dernière modification le 04 avril 2013 à 15:35.
Heu… J'ai pas du tout dis ca…
Bon, ok, c'est clair que je n'ai peut être pas tout compris,
mais là actuellement on aurait :
source C++ ==[bananaBread]==> code en "sous ensemble js" ==> interpreté par asm.js (qui lui est optimisable)
alors qu'en parallele, on a ça :
code source javascript ===> interpreté par le moteur traditionel (peu optimisé)
et je me dit que si on est capable de faire un bananaBread pour tranformer du C++ en sous ensemble js, ont doit pouvoir le faire pour transformer du js en ce même sous ensemble (et le tout de manière automatique, à la volé…)
code source javascript ==[quicheBread]==> code en "sous ensemble js" ==> interpreté par asm.js (qui lui est optimisable)
oui mais il se traine… alors que l'autre il est rapide.
[^] # Re: pourquoi pas du js converti en asm.js
Posté par claudex . Évalué à 4.
Un des gros avantages d'asm.js, c'est le typage qui n'existe pas en JS. Si tu veux transformer du JS en asm.js, il va falloir typer tes variables, or, ce n'est pas possible en JavaScript.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: pourquoi pas du js converti en asm.js
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Non, ce n'est pas possible car la sémantique de base de JS est trop pauvre.
"La première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: pourquoi pas du js converti en asm.js
Posté par daeldir . Évalué à 3.
On peut aussi dessiner la chaîne de cette manière :
Ce que tu proposes :
Javascript => asm.js => code machine
Ce qui se fait actuellement :
Javascript => Code machine
Il ne faut pas oublier que le javascript est déjà compilé, de nos jours (avec le JIT).
asm.js et emscripten sont utiles pour compiler d'autres langages en Javascript. Vouloir transformer du javascript en asm.js va demander des cabrioles pour contourner les types de asm.js (puisque Javascript n'est pas typé), ce qui limite vachement l'intérêt de asm.js, non ?
Pour la même raison, compiler des langages dynamiquement typés en asm.js plutôt qu'en Javascript peut-être moins intéressant. Les projets comme Pyjamas, Lua.js, et même go2js transforment leur code directement en Javascript, en réutilisant les types dynamiques de Javascript. Réimplémenter un nouveau système de typage et d'objets alors qu'il en existe déjà un (optimisé par la compilation JIT, qui plus est) semble moins efficace, à vue de nez. (Vous vous imaginez, on aurait un code qui ressemble aux GObjects, mais en Javascript…)
Compiler l'interpréteur Python avec emscripten fera tourner le code Python à 50% de sa vitesse (pour le moment), compiler le code Python en javascript avec Pyjamas le fera tourner à la vitesse de Javascript (On va donc dire, à la même vitesse que le code Python d'origine, parce que ce sont deux langages dynamiques. C'est sans prendre en compte que le Javascript peut être plus rapide que le Python, ou pas, j'ai pas fait de tests ;-))
[^] # Re: pourquoi pas du js converti en asm.js
Posté par freem . Évalué à 2.
Ca limite, oui, c'est sûr… Mais dans la catégorie des "il ne faut pas oublier", j'invoque la quantité de code non négligeable qui existe en C et C++, qui deviendra d'un coup accessible aux utilisateurs de JS.
[^] # Re: pourquoi pas du js converti en asm.js
Posté par daeldir . Évalué à 1.
Ça limite l'intérêt de compiler le javascript en asm.js !
Bien sûr que asm.js et emscripten ont un intérêt (celui que tu cite).
Aurais-tu la mémoire courte et oublié le contexte de mon post ? ;-)
[^] # Re: pourquoi pas du js converti en asm.js
Posté par Yakulu . Évalué à 2.
Comme répondu ailleurs, ce n'est pas possible en l'état.
En revanche, il est possible d'utiliser un langage intermédiaire comme LLJS. Des travaux sont en cours pour permettre une compilation vers asm.js.
Voir aussi ce billet assez complet sur asm.js où il est en partie question de LLJS. Je cite :
# Je me contenterais d'un bravo !
Posté par maboiteaspam . Évalué à 2.
oui, juste Bravo !
Avoir réussit à bluffer comme ça l'industrie c'est quand même beau : )
# Bravo à Mozilla
Posté par n05f3ra1u . Évalué à 1.
J'ai testé EPIC Citadel sur Firefox (en natif bien sur) et j'avoue avoir été impressionné de pouvoir faire tourner un jeu pareil dans un navigateur web avec des performances plus que correctes.
Alors pour ceux qui ne seraient pas convaincu : http://www.unrealengine.com/html5/
(Par contre prenez une version nightly de Firefox sinon le jeu risque de ne pas se lancer correctement.)
A terme cela augurera peut être un web plus dynamique avec des pages 3D ou animée et des jeux natifs.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.