Journal HTML 5 : geometry, encore une API?

Posté par . Licence CC by-sa
10
8
nov.
2013

NB: je suis plus que faillible (comme le montre la quantité astronomique de fautes dans mon texte) merci de m’excuser si je fais des raccourcis ou omets des détails ou encore si je me trompe dans ma réflexion (et n’hésitez pas à me corriger!), le but étant d’échanger et partager:)

Présentation:

Récemment, j’ai reçu un mail me parlant d’une API pour la géométrie qui permettrait aux navigateurs d'être extrêmement rapide pour certains calculs courant pour la 3d ou autre. Je pense que l’idée est intéressante mais passe à côté du problème: en effet, le manque n’est pas une absence d’API en soit mais plutôt l’absence de performances suffisantes dans le navigateur pour certaines applications, applications qui requièrent généralement des calculs intensifs comme c’est le cas pour la 3D ou la vidéo.

Mon opinion

Les exemples qui me viennent à l’esprit sont le traitement sur des images ( reconnaissance de visages) ou la 3d (collisions, simplification de modèles 3D, simulations) et si on regarde de plus prêt les papiers publiés dans le domaine ainsi que les implémentations dans les bibliothèques spécialisées existantes, on s'aperçoit rapidement qu’avoir une simple API nous limite grandement…Même si par miracle l’API se transforme en un eigen et/ou un blas, le coût de développement et de maintenance restent conséquent pour un apport limité à quelques problèmes précis ou plutôt pour les conséquences d’un problème plus profond…

Il me semble plus pertinent de penser à un système global répondant au besoin de performance qui permettrait aux développeurs de fournir ces bibliothèques plutôt que d’essayer de créer une API pour chaque besoin… surtout qu’on est potentiellement capable de l'adresser en javascript si on omet simplement la rapidité d’exécution ou la consommation mémoire.

Alors l'API est elle inutile?

Aujourd'hui, elle est utile mais demain… J'espère que nous aurons d'autres solutions qui permettrons aux experts de chaque domaine d'avoir leurs librairies.

Tout n’est pas rose pour autant et avoir de la performance dans le navigateur n’est pas une simple copié collé de code: quand je parle de performance, nous pensons tous à asm.js (sous ensemble js pour la performance),dsp (api de calcul parallélisable) ou encore WebCL(GPGPU pour le navigateur ) pour combler ce vide, mais même si le deuxième serait une partie de la solution finale d’après moi, ni asm.js ni même WebCL n’apportent une réponse convenable aujourd’hui:

Ceux qui ont essayé asm.js savent que la communication entre le javascript classique et le code asm.js n’est pas optimal. En effet,le coût d’un appel vers le javascript classique rend parfois difficile la création de bibliothèque pour la simulation si l’on souhaites des performances rivalisant avec le natif*. A noter que le problème n’est pas l’idée mais l’implémentation et qu’avec quelques modifications (autovectorisation?gestion des threads?), on arrivera probablement à une solution convenable, bien que ma satisfaction ne soit pas complète (j'en parlerai dans un autre journal?).

Pour le WebCL, c’est légèrement différent, le langage C pour l’écriture du code se prête bien pour la haute performance (dans une certaine mesure), cependant la copie obligatoire entre le contexte javascript et le drivers OpenCL ajoute une latence non négligeable… Ainsi, sauf si il y a une réintroduction de la possibilité d'utiliser directement la mémoire du javascript (un mixe entre l’argument CL_MEM_USE_HOST_PTR d’openCL et le transferable html5 pour éviter les accès concurrents ), je ne vois pas comment ce dernier permettrait d’avoir des traitements 3d temps réels que le js d’aujourd’hui ne permet pas déjà.

Voilà mon petit journal/troll du jour :-) Je ne serai pas beaucoup disponible donc si je ne réponds aux commentaires que mardi, veuillez me pardonner mais je suis toujours content d’échanger avec toi chère journal.

*: En regardant rapidement, je pense que cela proviens de la manière dont la mémoire est protégée (sur x86, la mémoire est copié dans son propre process puis ils utilisent les memory segment), mais je n’ai pas effectué de tests approfondie pour savoir si c’est vraiment ca

  • # Mauvais langage, changer de langage?

    Posté par (page perso) . Évalué à 5.

    Javascript n'est pas fait pour les perfs, il lui manque trop de fritures. A mon avis il n'y a que deux approches pour changer cette situation, la bonne et la mauvaise.

    http://devnewton.bci.im

    • [^] # Re: Mauvais langage, changer de langage?

      Posté par (page perso) . Évalué à 3.

      C'est bien l’intérêt de ces API, non ?
      Au lieu d'implémenter en JS une lib pour la gestion de la géométrie, elle sera implémentée en C++ par le browser.

      • [^] # Re: Mauvais langage, changer de langage?

        Posté par (page perso) . Évalué à 1.

        Comme dit tallion< dans le journal:

        Il me semble plus pertinent de penser à un système global répondant au besoin de performance qui permettrait aux développeurs de fournir ces bibliothèques plutôt que d’essayer de créer une API pour chaque besoin…

        http://devnewton.bci.im

    • [^] # Re: Mauvais langage, changer de langage?

      Posté par . Évalué à 3.

      Même si j'ai beaucoup de reproches pour asm.js, je ne suis pas sûr qu'il soit si mauvais que ça. Il est vrai que, d'après moi, la syntaxe n'est pas la meilleur mais que l'idée même soit à jeter…
      Je pense que beaucoup souhaite un cython/pythran/Shed Skin pour javascript et asm.js est un premier pas qui montre que le besoin et la solution existent.

      Sinon pourquoi dart plutôt que typescript?

      • [^] # Re: Mauvais langage, changer de langage?

        Posté par . Évalué à 3.

        Il est vrai que, d'après moi, la syntaxe n'est pas la meilleur mais que l'idée même soit à jeter…

        devnewton pense lui que c'est le typage qui pose problème (et la spec d'asmjs semble lui donner raison).

        Sinon pourquoi dart plutôt que typescript?

        Parce que Google c'est mieux que M$ ⸮

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Mauvais langage, changer de langage?

        Posté par . Évalué à 1.

        TypeScript, comme CoffeeScript, se compile en JS.
        Aucun gain de performance à attendre de ce côté là, du coup.

        Par contre ce n'est pas le cas de Dart qui pourrait s'avérer prometteur.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.