Interview de Thibault Imbert chez Adobe à San Francisco

Hello développeuses et développeurs,

Je vous propose une interview de l'expert en Développement Web : Thibault Imbert.

Dans cette vidéo, vous allez découvrir :

• son parcours : comment un Français se fait embaucher chez Adobe aux Etats-Unis ;
• son métier actuel et les sujets sur lesquels il travaille (Image IPB) ;
• l’avenir du web et du développement dans les prochaines années ;
• trois conseils à appliquer dès maintenant dans votre programmation pour progresser !

Cliquez ci-dessous pour voir l'interview en vidéo sur Développement-Facile :
www.programmation-facile.com/thibault-imbert-adobe-san-francisco/

http://www.programmation-facile.com/...028-215759.jpg

A bientôt,

Matthieu

Des propos intéressants, mais une véritable "torture" pour les oreilles.

Désolé pour le son, c'est une interview improvisée.
J'ai fait de mon mieux avec les moyens du bord
(un iPad mini pour filmer et la prise de son).

torture quand même pas. c'est sur si c'est écoute avec des hp restituant un basse qualité les oreilles ne doivent pas trop aimer.

Ce sont trois très bons conseils, bien trouvé pour un live :ccool:

Un ingénieur d’Adobe discutant des techniques de parallélisassions pour le développement Web 8O

Est-il au courant qu’Adobe avait sa propre technologie nommé Pixel Bender ?

Est-il au courant que les décisionnaires d’Adobe ont supprimé le runtime de Pixel Bender, comme ça sur un coup de tête et sans prévenir personne, depuis la mise à jour de Flash Player 11.8 , pour le remplacer par une médiocre VM qui sature la charge de tous les cœurs CPU.

Adobe, oblige ainsi, les utilisateurs de Pixel Bender à changer, dans l’urgence, de techno ! Merci Adobe :mur:

Le problème est que les alternatives ne sont pas nombreuses :

• Alternative WebCL : n’est, à ma connaissance, implémentée sur aucun navigateur
• Alternative RiverTrail : qui soit dit en passant n’utilise pas le GPU, contrairement à ce qu’affirme l’interviewé de la vidéo, mais les jeux d’instructions SSE sur les architectures x86. RiverTrail, semble être destiné à être utilisé en adéquation avec WebGL à l’écriture de moteur graphique vectoriel, afin de paralléliser les opérations trigonométriques de changement de repère coté CPU. J’ai du mal à concevoir d’autre utilisation de cet API.
• Alternative WebGL : une alternative valable a Pixel Bender, mais contraint le résultat d’un traitement parallélisé à son affichage graphique. Si accélération GPU est bien plus performante que l’accélération CPU il faut ajouter le cout des transferts RAM -> VRAM
• Alternative Stage 3D : la réponse d’Adobe a WebGL, avec une API plus moderne. Disponible depuis la version 11 de Flash Player mais pour combien de temps …

Bref il serait temps que les choses bougent sur ce sujet, l’accélération hardware est disponible depuis plus de 10 ans mais les outils/technos software sont toujours aux stades expérimentale…
Malheureusement les développeurs web, attendant beaucoup de ces technos sont très minoritaires …dommage.

@p3ga5e: Tes propos sont peut être justes, mais sont hors-sujet par rapport au contenu de l'interview. Pourquoi Thibault Imbert n'aurait pas le droit de parler de multithreading en JavaScript ? Sous prétexte qu'il bosse chez Adobe ? Il me semble qu'on s'intéresse plus à la personne qu'à l'entreprise ici..

Pourquoi hors sujet ? Le parallélisme (à ne pas confondre avec le multi-threading :aie: ) est un des sujets principaux de la première partie de la vidéo !

Ensuite je encourage toute personne à promouvoir les techniques de parallélisassions autour de JavaScript ( de préférence WebCL ) , d’autant plus si cet personne dispose d’une certaine notoriété , ce qui semble être le cas ici, je n’ai donc aucune antipathie à l’égard de Mr Imbert , mais j’ai de réel questions sur l’avenir des technos et de la politique mené par Adobe.

Le runtime de Pixel Bender de Flash était une excellente techno de parallélisassions et qui, à l’heure actuel, ne possèdent aucune alternative. Alors même si Mr Imbert s’intéresse au parallélisme à titre privé , il doit forcément connaitre la réel raison de cet abandon !

Je cite :

Citation:

---

-Le truc qui m'intéresse particulièrement, c'est tout ce qui est parallélisme en JavaScript
-Ah oui, lancer des threads en parallèle
-Voilà, donc comment utiliser le hardware et le multi-core. Aujourd'hui JavaScript est vraiment single-threaded, simple processus. Si on veut paralléliser des tâches, ce n'est pas du tout adapté pour ça. Il y a ce qu'on appelle les Web Workers (...) mais on utilise pas vraiment le multi-coeur.

---

S'il ne parle pas de multi-threading, je m'achète un chapeau pour le manger... Le multi-threading est un moyen de faire du parallélisme de calculs, tout comme l'utilisation du GPU. Il n'y a pas de confusion entre les termes, l'un est l'objectif, l'autre le moyen.

Désolé qu'Adobe te mette en rogne ces temps-ci, mais ce n'est pas une raison pour te défouler dans le premier article où tu vois le nom d'Adobe passer. Si la vidéo ne mentionne pas Pixel Bender (et ne parle d'ailleurs pas spécifiquement de traitement vidéo), c'est parce que ce n'est pas le sujet.

C'est intéressant

Ca fait du bien d'entendre qu'il faille être ouvert et agnostique en terme de technos et de langage, sans religiosité.

Ce n'est pas tant le son qui m'a gêné, tout est bien audible, c'est plutôt que la caméra n'est pas fixe, et c'est assez désagréable. Plusieurs de tes vidéos Matthieu ne sont pas stabilisées il me semble, et tu gagnerais en qualité perçue à avoir même un simple APN doté d'une stabilisation optique.

Tu as fait une autre vidéo "sur la plus belle plage d'Europe" :mrgreen: où là c'est terrible pour le son. Un vrai micro avec une bonnette...


Bon voyage :)

PS : j'espère que tu as posé des CVs un peu partout puisque ça a l'air d'être ton rêve la Californie

Je cite ta citation ;)

Citation:

---

Voilà, donc comment utiliser le hardware et le multi-core. Aujourd'hui JavaScript est vraiment single-threaded, simple processus. Si on veut paralléliser des tâches, ce n'est pas du tout adapté pour ça. Il y a ce qu'on appelle les Web Workers (...) mais on utilise pas vraiment le multi-coeur.

---

Mr Imbert indique clairement, et ce à juste titre, que le model de programmation par Thread donne de très mauvais résultat en terme de parallélisassions multi-cœur.
Ensuite il cite à plusieurs reprises RiverTrail. Donc je ne suis pas hors-sujet, Mr Imbert fait bien référence à des technos de parallélisme à base de kernel et pipeline et ne conseille pas le multi-threading!

Et tu ne devrais pas limiter ces techniques aux traitements de la vidéo, car cela couvre des domaines d’application bien plus large : le traitement du signal en général (vidéo, audio, ou autre), la programmation graphique, la simulation physique, et même l’intelligence artificiel !
Si les domaines d’applications ne sont pas abordés dans la vidéo, la disponibilité de ces technos, afin de réduire la consommation du moteur JavaScript en utilisant correctement le hardware, et elles, sont bien abordées.

Désolé que mon ton te dérange, je ne trouve pas que je me défoule, je suis même plutôt sur la retenu, et je pense avoir le droit de critiquer, ici, la décision d’Abobe.
Je préférais réveiller en toi, l’intérêt a ces model de programmation, plutôt que nous quereller dessus :calim2:

Comme Sylvain je pense que tu es complètement hors-sujet à venir ici critiquer Adobe pour l'abandon d'une bibliothèque de traitement d'images, en saisissant l'opportunité de ce sujet sur l'interview d'un collaborateur Adobe.

Et il me semble bien avoir compris que ce qui intéresse le monsieur interviewé, ce sont les possibilités de parallélisation d'ordre général en profitant des possibilités offertes par les matériels actuels. Pourtant il me semble que l'interview est en français ?

Le blog de Thibault Imbert a l'air intéressant : http://typedarray.org/
Agréable à l'oeil en tout cas

Je vois des références sur les web workers, ce qui m'intéresse pour node.js. Tu trouveras peut être de quoi alimenter ta réflexion, il y a une entrée relative à WEBGL

Citation:

---

Et il me semble bien avoir compris que ce qui intéresse le monsieur interviewé, ce sont les possibilités de parallélisation d'ordre général en profitant des possibilités offertes par les matériels actuels.

---

Je pense que nous avons tous compris cela, maintenant cela n’autorise pas à faire amalgame entre le model de programmation par Thread et celui à base de Kernel.

Et tu as vus juste ! J’ai saisi l'opportunité de ce sujet pour mettre sur le tapi le problème de Pixel Bender , l’occasion été trop belle et surtout trop rare !

En tous cas si tu es curieux je t’invite également à regarder le model de parallélisme à base de Kernel avec WebGL, c’est très passionnant et très éloigné du model de multi-Threading !

Pour les WebWorker sous node ils sont plus ou moins nativement implementé par la gestion des processus

Non je ne crois pas que l'on parle de la même chose.

Sous node les workers, la notion tout du moins, apparaissent avec le module Cluster, qui est comme tu le verras encore au stade expérimental :

http://nodejs.org/api/cluster.html

je ne savais même pas que ça existait coté browser engine, je vais voir ce qu'il se dit dessus.

Le clustering sous node consiste bien à forker ton processus, tout en ce partageant le même port d’écoute afin de répartir la charge sur chaque cœur !

Les WebWorkers sur navigateur consistent, en gros, à instancier un nouveau moteur JavaScript qui ne partage rien avec son créateur, mais avec qui tu peux communiquer à coup sérialisation dé-sérialisation JSON, Donc cela se rapproche plus du système de communication inter-processus mise en place par node.

Chrome à implémenter les SharedWorker, un poil plus intéressant que les WebWorker, qui permet, entre autre, de faire communiquer plusieurs onglets.