Bon, je dois l'admettre étant data scientist, cela m'a un peu piqué…
Après, vu que le nom reste un peu récent, beaucoup dans ce métier ont oublié la partie "science" et il y a peu de senior avec des bonnes pratiques.
A chaque nouveau, on doit expliquer qu'intégrer une dépendance nécessite a minima de valider le risque d'abandon, la licence, la maintenance…
Sinon ce qui m'étonne dans ton analyse, c'est qu'à part sur le bash (conda…), la plupart des remarques ne sont pas sur la gestion des dépendances mais plus sur les mauvaises pratiques de ceux qui l'utilise. En tant que dev C++, j'imagine que tu vois la séparation entre avoir la possibilité et le faire.
Pour ma part, conda me permet de gérer le python et je reste sur les outils classiques pip/pipx and co (en fait ce qui est dans pypa), ma gestion avec le pyproject.toml et cela marche plutôt bien (même les dépendances avec la pep 621 car je pense pas qu'on aura la 582).
Donc en restant sur du clean et des bonnes pratiques, le seul bémol que je vois c'est le poids de la stack python pour un cli et parfois la lenteur…
A l'époque où j'avais codé OpenscalesGL avec un ami (il y a plus de 5 ans maintenant), nous avions été obligé de tout faire directement dans le javascript (avec un arbre de résolutions plutôt élaboré), sinon ca rame pas mal dans les smartphones. De plus, tu pouvais utiliser les protocoles classiques de la 2d sans modification pour faire la 3d y compris pour les bâtiments et élévations de terrain (WMS,WMTS,TMS etc…) tout en optimisant le stockage et la bande passante.
Maintenant, avec asm.js (qui en plus va être aussi intégré dans IE), t'as pas peur que x3dom devienne un boulet pour ce que tu veux faire?
C'est pas que je n'aime pas x3dom, c'est simplement que je suis surpris que ce soit adapté :) (et tant mieux si je me trompe car c'est comme ca qu'on apprends ;)
Je pense qu'il y a une erreur dans le journal, les websockets sont de la communication asynchrone (socket TCP) entre le serveur et le naviagateur, c'est WebRTC qui fait du p2p entre les navigateurs. Le serveur/site web fait la mise en relation (annuaire).
Emacs/vim requierent de tout faire a la mano, ou se coltiner un travail de creation de l'environement (build system + debugger + editeur +…) soi-meme qui est une perte de temps inimaginable.
Comme les plugins eclipse, netbeans, codeblocks, visual…
Alors oui Emacs c'est flexible, c'est super en LISP et ca fait le cafe. Mais ca fait le cafe apres avoir passe 300 jours a le configurer pour. Je preferes utiliser une machine a cafe a ce prix la.
Pour vim, il m'a fallu une demi journée la première fois.Maintenant, le vimrc étant fait avec vundle, plus rien. Mais oui, ca nécessite un temps d'apprentissage. Comme le shell,hg/git,C++…
A noter que quand je faisais du JEE, le temps passé a configurer eclipse n'était pas si inexistant (plugins,builds, import de vieux projets,maven etc…)!
Laisse moi rire… Ca s'appelle "ne pas vouloir changer ses habitudes", et rien d'autre. Pour avoir vecu dans les 2 mondes (et oui, je m'amusais a editer des extensions en LISP), il n'y a juste pas photo du tout.
C'est vrai seul vim/emacs permet d'être productif dans certain cas ;-). Je ne peux parler que de vim mais concrètement, il n'a pas a rougir pour le C++ (pour le java, c'est autre chose). La transparence pour avoir la doc derrière, les onglets + splits, l’auto-complétion sémantique ou par mots présents, et j'en passe… Venant de qtcreator et avant kdevelop (alors que je ne fait pas de QT), je suis donc je suis dans "ne pas vouloir changer ses habitudes, et rien d'autre", il n'y a pas un problème ?
A noter qu'eclipse et netbeans se plantent avec les gros projets C++ mais pour java, ils vont parfaitement. Pour le JS, vim ou netbeans font très bien l'affaire.(->Et là autant d'avis que de techno et d'utilisateurs)
Ce n'est que mon expérience mais elle est vraiment différente de ce que tu dis.
High Performance Computing refers to the practice of aggregating computing power in a way that delivers much higher performance than one could get out of a typical desktop computer or workstation in order to solve large problems in science, engineering, or business.
Et l'(Quasi-)Opportunistic Supercomputing en fait partie!
Si ca n'était pas du HPC pourquoi on le retrouve dans les conférences sur le HPC ?(regarde les papier dans HiHPC!!!)
Je m'excuse si je m'emporte mais c'est bien l'idée que j'essaie de combattre, le reste du monde a une autre définition… Ca va dans les deux sens, j'ai un autre à la maison avec son "mais le grid c'est pas du HPC, il y a pas de problème, ils utilisent pour de la simulation sur des données structurées et facilement découpables! Il y a rien à faire…" sur qui je m'énerve (et vais bientôt commettre un meurtre), alors quand je vois l'opposé, ben j'ai envie de boire de la javelle en récitant des sumériens.
Toi, tu parles de Grid,Distributed and Parallel Computing mais ce n'est pas la même chose, une sous partie seulement, le HPC est plus grand (Optimizing Data Movement etc…).
Ah bah oui c'est vrai que ceux qui font du Hadoop pensent faire du HPC…
A je l'ai loupé ce commentaire :-)
<_Mode mauvaise fois on_>
Ha oui,toi tu parles du truc à scheduler statique dans la grille du genre: j'ai une voiture qui va à 200 km/h mais pour l'utiliser tu dois me prévenir 3 jours à l'avance et seulement pour sur la a46… Donc prends la 2 chevaux tu iras plus vite pour paris - lyon…
Et dire que ca pense faire du HPC…(pouvant être remplacer par web 2.0/ cloud ….)
<_Mode mauvaise fois off_>
Plus sérieusement, Hadoop est un framework et tu peux faire en mode flux (troll retour: "et utile pour les vrais gens")(storm) qui est quasi impossible sur le manière dont on manage les grilles aujourd'hui. Le but c'est d'être constructif sinon on troll sur tout!
Soit tu considères que les personnes qui n'ont pas les même besoin peuvent t'apporter des choses et vice versa, soit tu es comme certains chercheurs (heureusement une minorité) qui dès que ca dépasse leur domaine de recherche stricte considèrent que tout est débile. Moi je suis dans le premier cas :-)
PS: je ne fait pas de hadoop car je suis en basse latence pour mes calculs
Si tu regardes tous les framework Python au dessus d'Hadoop et que tu restes sur des traitements simples, favorable à Python donc, tu prends un facteur entre 3 et 10.
Quand tu parle de python, tu parles bien de python sans cython/pythran and co?
Mais dire que t'es IO bound et que Python ne change rien faut pas déconner. Sur les vrais jobs on bosse le design mais aussi énormément l'optimisation des implémentations de bas niveau ce qui donne des gains très significatifs.
On est d'accord que si l'algo et l'implémentation sont dégueulasses ca ne marchera pas. Mais on parle de développeur dont c'est le métier, on sait tous parfaitement faire des caches intermédiaire pour pas tout recalculer ou utiliser des patterns aux bon endroit quand il y a un point bloquant.
Je m'excuse si je passe à côté de quelque chose et je peux avoir tord mais ici j'arrive pas à voir ce que je manque: j'ai toujours cette vision de la compression de maillage 3d basé sur un octree et un ordre de morton où python me tue les performances par rapport au C++ (simd etc…)
Pour moi c'est un IO, tout comme la lenteur de la global memory d'OpenCL ou de la ram par rapport au cache mais le mot est peut être mal employé, désolé.
De plus, j'ai l'impression que tu parles de grilles de calculs là où je parle de clusters plutôt orienté statistiques/données, ce qui n'est vraiment pas la même chose:avec la simulation on arrive tout de suite sur le micro HPC couplé au macro
Je suis d'accord avec toi, le HPC dans nos tête c'est la ferme de serveur…
Même si ce n'est pas visible dans le titre, j'ai bien essayé de parler de macro HPC (distribué sur des milliers de nœuds) et micro (travail parallèle sur une même machine). Cependant les concepts restent les mêmes: je parallélise mon calcul que ce soit entre les machines ou les cœurs du processeur.
C'est pour ca que j'ai omis MPI, j'avais peur que cela embrouille le lecteur entre ce qui est distribué et ce qui ne l'ai pas.
Enfin, dernière petite remarque : je trouve que nous avons tendance à trop nous concentrer sur le matériel (j’ai aussi ce travers, bien que j’essaie de corriger), alors que bien souvent chercher un algorithme plus performant amène d’excellents résultats.
Complètement d'accord, je pense que la raison vient du fait que c'est plus simple de communiquer sur une innovation matérielle qui touche tout le monde que sur son algo lock-free dont le parallélisme varie linéairement avec la taille du tableau (et qui solutionne un problème précis comme la compression d'image de radio médicale)
Pour python, je dirais plutôt que dans la majorité des cas du macro HPC, les performances sont largement suffisantes car le goulot d'étranglement sont les IOs (disques/réseaux) donc il n'est pas utile de se prendre la tête.
Même l'actor model? Pour le map/reduce (et hadoop en générale) je comprend qu'il y a toujours des galères dans le cluster mais j'étais certain que les acteurs marchaient très bien quand ils étaient utilisés au bon endroit…
Au passage, pourquoi veux-tu faire du HPC dans le navigateur web ?
Un papier scientifique où l'implémentation de référence serait dans le navigateur ou encore , un truc complètement fou, faire un VLC dans firefoxOS! Je vois plein de raison et en plus ça m'amuse :-)
Côté plus terre à terre, si je suis capable de le faire côté client , je pourrais alors offrir la même chose côté serveur et mutualiser les ressources entre plusieurs utilisateurs sans provoquer de problèmes de sécurité (si mon serveur possède un GPU pour accélérer les calculs par exemple, sans devoir acheter du matérielle spécialisé).
Pour WebCL, je participe un peu à la définition donc, même si j'essaie d'être impartial, je dois probablement être biaisé quand j'en parle… j'ai un google doc de 5 pages sur des tests de codes, des critiques de webCL,asm.js,dart etc et j'hésite à en faire (encore) un journal car c'est vraiment technique et spécifique.
Pour l'aspect distribué, ce qui serait marrant c'est de voir en quoi le navigateur comme nœud influence le scheduler qui distribue les jobs, mais là j'ai pas regardé et il me manque de la lecture sur les papiers…
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.
mozCorp appartenant 100 % à la fondation, là c'est de la technique fiscale, tu ne penses pas?
De toute façon, est ce que cela change quelque chose? Intellectuellement, séparer les deux pour amoindrir les responsabilités de chacun, c'est un peu facile… Mais comme dit dans le titre du commentaire, il y a peut être quelque chose qui m'échappe.
Je suis plutôt pro firefox et le fait que mozilla soit capable de passer outre le dogme pour répondre à un besoin, je peux comprendre…
Mais se réjouir d'une des défaites du web ouvert!
En plus, ce qui me gêne c'est que se soit quelqu'un de mozilla et non une contribution externe car ca veut dire que les dons (aussi infime que cela représente) ont aussi servi à légitimer des patents!
Je ne suis pas sûr de comprendre la remarque. On a un code dont la représentation me permet de créer un IR vraiment proche de ce que tu aurais avec du code C bas niveau généré par clang . Du coups, je ne vois pas en quoi le langage est un problème ici…
Les cas que je vois sont par rapport au C/C++, lorsqu'on utilise des fonctionnalités bas niveaux (comme SSE…). Sauf qu'avec ces optimisations, tu n'es plus portable, c'est à dire plus dans le navigateur.
au prix d'un code source dans la page peu lisible
Tu peux aussi voir asm.js comme un tout nouveau langage dédié à l’efficacité, une sorte de bytecode du web. Partant de ce constat, je le trouve vraiment très très lisible comme représentation intermédiaire (comparé à llvm IR, le bytecode java…).
Il est peut être temps de trancher dans le vif et de pouvoir enfin écrire quelque-chose comme:
Ici, on parle d'avoir des performances. Avec Rust ( ou même dart/java/C++ ), si tu veux des performance, tu vas définir un sous ensemble à utiliser.Pourquoi ne pas simplement le faire directement dans le langage déjà utilisé ?
Depuis des années, on a bidouillé une plateforme faite pour servir des documents en sandbox d'applications.
Depuis des années, on améliore un produit plutôt que d'écrire des pseudo révolutions toutes les 5 minutes. C'est plutôt un bonne chose de mon point de vue. Finalement, je ne suis pas d'accord que ce soit un problème, mais je n'ai pas d'argument vraiment pertinent donc, je vais considérer que je me trompe.
Maintenant, je ne suis pas chez mozilla, mais personnellement, je ne vois Rust comme une solution viable et intégrable rapidement pour répondre aux problème de performance, je préfèrerai avoir directement du C sandboxé.
Bon tu vas peut être me taper dessus aussi mais je ne suis pas sûr que tu vois tout le tableau ( je connais peu ces specs là mais j'ai un peu d'expérience dans les groupes de standardisation):
- Soit tu fais une spec rapide, tout en sachant qu'elle est vraiment moyenne mais en te disant qu'avec le temps tu vas l'améliorer car on peut pas tout prendre en compte en même temps => les gens se plaignent que tu es nul
- Soit tu prends tout ton temps et tu mets 2 à 5 ans pour sortir ta spec et… ben au bout de 5 ans, l'environnement et le besoin ont évolué!
Le plus grand problème, généralement, c'est surtout le manque de moyen et du coups, ca se ressent au niveau des prototypes, tu ne penses pas?
Bon après, j'avoue que parfois l'aspect politique pourrit souvent des drafts et implémentations.
Je suis un peu gêné par tes propos car tu exposes un problème générale comme si ca provenais de WebGL.
Tu peux réaliser du DoS avec un peu n'importe quoi... Ca à déjà été fait avec les décodeurs jpeg, j'en avais même trouvé un dans le format WebP alors que je ne me considère pas comme un codeur fou (et pour mon plus grand malheur avait déjà été reporté :) ou le javascript lorsque l'interpréteur ou le compilateur JIT à des bugs!
OpenGL n'a jamais été conçu dans un contexte Web
Vous rencontrez des problèmes spécifiques à la spec OpenGL
WebGL est une adaptation d'OpenGL ES pour le web, je ne vois pas le problème. Ca reviendrait à dire que le java ne peut pas être intégré comme langage web (quoi dart? ;) ou que le JS ne peut pas faire du serveur (nodejs). Bien sûr, il faut ajouter ou enlever quelques fonctionnalités et le résultat sera plus ou moins adapté, mais c'est toujours possible.
Vous exposez de nouvelles API qui interagissent avec le matos, plus difficilement contrôlable par l'OS,
Si c'est difficile et ajoute un risque, on ne doit rien faire? Dans ce cas les compilateurs JIT des moteurs javascript ne devraient pas exister. D'autant plus que, si j'ai bien compris, le vrai problème ne se situe pas vraiment au niveau de l'OS mais des drivers mal fait, drivers qui sont blacklisté et désactive WebGL. On a déjà vue pire pour des drivers réseaux et c'est hautement plus crucial car faire planter serveur ca n'a pas le même impact qu'un poste client. Du coups, je débranche internet?
A noter que les sources de WebGL (les shaders) sont aussi compilé à la volé, un peu comme le javascript donc il est possible de le rendre parfaitement sécurisé, soit en faisant des vérifications formelles soit en ajoutant des watch sur les opcodes bas niveau ou un mix des deux. Le problème, j’imagine, c'est que les fabricants doivent préférer le faire eux même car ca impacte beaucoup les performances. Je crois qu' ANGLE* fait une partie de ces vérifications (*la lib ajoutant OpenGL ES au dessus de directX)
bref, vous élargissez l'exposition en terme de sécurité.
C'est le cas pour toutes nouvelles fonctionnalités et pas seulement dans le monde du navigateur mais aussi dans le kernel, les solutions de virtualisations (oui je triche, un navigateur c'est un OS virtualisé pour moi)...
Je ne sais pas si j'ai été clair et je m'excuse si ce n'est pas le cas : j'ai tendance à m'égarer dans mes propos.
Ceci étant dis, je lis les journaux de Patrick_G tout comme toi!
Cependant faire des commit dans le noyau,c'est moins chère que d'appliquer les patchs à chaque fois pour que tes produits fonctionnent mieux: C'est une vérité économique que je connais et c'est aussi ça, l'open source d'entreprise... mais seulement le premier niveau!
Ce que je sais c'est qu'Oracle est capable de tuer un projet+ communauté très rapidement si il pense que du cash facile est derrière (je pense que c'est un mauvais choix à moyen terme, mais après tout ...).
Je sais AUSSI que les gens d'Oracle ont aidé Linux, de façon déterminante dans les années 90 et qu'ils ont un très bon produit de haute dispo basé dessus etc...
Mais faire de l'open source et en avoir une culture, ça n'est pas juste des logiciels ou des commits, c'est aussi animer une communauté pour que la réalisation soit la meilleur possible (cercle vertueux servant aussi l'entreprise qui pourra vendre plus facilement du support, des évolutions, des nouveaux besoins... )
Ce que je leur reproche, c'est qu'ils traitent la communauté comme des employés qu sont bénévoles et remplaçable et donc qui n'ont pas leur mot à dire dans l'évolution des logiciels. Contrairement à ce qu'il semble** se passer chez oracle, dans les communautés open sources, on ne marche pas à la hiérarchie mais plutôt à la méritocratie! (tu ne dira pas de mal sur les marketeux, non, non ,NON). Je sais que ce principe là peux souvent engendrer pas mal de discussion (et trolls), mais c'est, AMHA, un petit prix face au bénéfice. Maintenant avec tout les départs de la société et les problèmes avec les communautés, je confirme ce que j'ai dit :
Après, je n'arrive pas à savoir si oracle a de bonnes intentions mais que l'open source n'est vraiment pas dans la culture de l'entreprise ou simplement qu'ils considèrent ça comme un sous produit qui fait perdre de l'argent sur le dos des vaches à lait que nous sommes. ..
J' ajouterai seulement sur certains marchés
Maintenant si tu as des éléments que je ne connais pas, ou comprend pas, et si tu souhaites les partager avec nous, je serais ravi de changer d'avis.
**j'insiste vraiment sur le semble car les grosses boîtes, c'est particulier)
Ou avoir un gestionnaire de package plus souple ou facile d'accès.
Sous arch, je suis en nightly pour pas mal de truc (gnome,vala, chromium, firefox...) car c'est très facile de faire en sorte d'utiliser les sources ou les repos (en plus yaourt, une surcouche au package manager, permet de faire les updates automatiquement si ton repo est un svn,git ou hg :)
Je fais donc des packages même sur ce que je code et sincèrement, quand tu fais du dev, ca permet de garder une distribution propre et c'est pas plus mal.
La différence c'est que là, tu peux proposer un patch, utiliser ta version patchée etc... Sous windows, si il y a un gros bug qui est vraiment bloquant pour toi et qu'ils ne veulent corriger, ben...heu... tu changes de systèmes?
En pleurant, les majors ont bien réussi à avoir la taxe pour la copie privée (avec DRM pour qu'elle soit pas possible en plus) et hadopi et j'en passe... Donc ils essaient de nous faire la même chose (surtout que free a besoin d'argent pour ces investissements mobiles et fibre).
C'est plutôt ces principes de rentes qu'on devrait interdire et encourager la création (industrielle,artistique ou de services)
Ce qu'il faut savoir, c'est qu'il y a pas longtemps encore, la PS3 était vendu à perte (je ne sais pas si c'est encore le cas). Donc vendre une machine qui ne sera pas utilisée pour acheter des jeux,jeux sur lesquels ils gagnent l'argent, c'est pas top...
J'ai pas regardé depuis longtemps mais maven n'était pas très fort pour le C et les autres langages compilés.
C'est d'ailleurs un manque, à mon avis, quand on code en C: un waf/scons avec un système de plugin et une gestion des dépendances (par les sources :) à la maven. On a bien jhbuild de gnome mais c'est pas encore la panacée ( même si le sujet reviens souvent: http://mail.gnome.org/archives/vala-list/2010-March/msg00049(...)
# Vision Data scientist ?
Posté par tallion . En réponse au journal La cochonnerie en boite que sont les systèmes de dépendances. Évalué à 5.
Bon, je dois l'admettre étant data scientist, cela m'a un peu piqué…
Après, vu que le nom reste un peu récent, beaucoup dans ce métier ont oublié la partie "science" et il y a peu de senior avec des bonnes pratiques.
A chaque nouveau, on doit expliquer qu'intégrer une dépendance nécessite a minima de valider le risque d'abandon, la licence, la maintenance…
Sinon ce qui m'étonne dans ton analyse, c'est qu'à part sur le bash (conda…), la plupart des remarques ne sont pas sur la gestion des dépendances mais plus sur les mauvaises pratiques de ceux qui l'utilise. En tant que dev C++, j'imagine que tu vois la séparation entre avoir la possibilité et le faire.
Pour ma part, conda me permet de gérer le python et je reste sur les outils classiques pip/pipx and co (en fait ce qui est dans pypa), ma gestion avec le pyproject.toml et cela marche plutôt bien (même les dépendances avec la pep 621 car je pense pas qu'on aura la 582).
Donc en restant sur du clean et des bonnes pratiques, le seul bémol que je vois c'est le poids de la stack python pour un cli et parfois la lenteur…
[^] # Re: PyPy-STM
Posté par tallion . En réponse à la dépêche Instantané sur le parallélisme et le code. Évalué à 2.
En même temps, si j'ai bien compris STM va permettre d'enlever le GIL dans pypy (il y a même une référence dans la faq ).
Quelque part, j'ai envie de dire que c'est encore plus intéressant!
# x3dom et performance
Posté par tallion . En réponse au journal Open Earth View. Évalué à 4.
Bonjour,
A l'époque où j'avais codé OpenscalesGL avec un ami (il y a plus de 5 ans maintenant), nous avions été obligé de tout faire directement dans le javascript (avec un arbre de résolutions plutôt élaboré), sinon ca rame pas mal dans les smartphones. De plus, tu pouvais utiliser les protocoles classiques de la 2d sans modification pour faire la 3d y compris pour les bâtiments et élévations de terrain (WMS,WMTS,TMS etc…) tout en optimisant le stockage et la bande passante.
Maintenant, avec asm.js (qui en plus va être aussi intégré dans IE), t'as pas peur que x3dom devienne un boulet pour ce que tu veux faire?
C'est pas que je n'aime pas x3dom, c'est simplement que je suis surpris que ce soit adapté :) (et tant mieux si je me trompe car c'est comme ca qu'on apprends ;)
[^] # Re: Et un standard de plus
Posté par tallion . En réponse à la dépêche pkgsrc 2014Q4 est disponible. Évalué à -1.
Quand on parle de fusionner les standards, ça me fait penser à ça
# Ah, WebSocket ou WebRTC?
Posté par tallion . En réponse au journal SyncNet, navigateur peer-to-peer. Évalué à 8.
Je pense qu'il y a une erreur dans le journal, les websockets sont de la communication asynchrone (socket TCP) entre le serveur et le naviagateur, c'est WebRTC qui fait du p2p entre les navigateurs. Le serveur/site web fait la mise en relation (annuaire).
[^] # Re: Ceux qui bossent ?
Posté par tallion . En réponse au journal Wync, un client Lync pour Linux !. Évalué à 6.
Comme les plugins eclipse, netbeans, codeblocks, visual…
Pour vim, il m'a fallu une demi journée la première fois.Maintenant, le vimrc étant fait avec vundle, plus rien. Mais oui, ca nécessite un temps d'apprentissage. Comme le shell,hg/git,C++…
A noter que quand je faisais du JEE, le temps passé a configurer eclipse n'était pas si inexistant (plugins,builds, import de vieux projets,maven etc…)!
C'est vrai seul vim/emacs permet d'être productif dans certain cas ;-). Je ne peux parler que de vim mais concrètement, il n'a pas a rougir pour le C++ (pour le java, c'est autre chose). La transparence pour avoir la doc derrière, les onglets + splits, l’auto-complétion sémantique ou par mots présents, et j'en passe… Venant de qtcreator et avant kdevelop (alors que je ne fait pas de QT), je suis donc je suis dans "ne pas vouloir changer ses habitudes, et rien d'autre", il n'y a pas un problème ?
A noter qu'eclipse et netbeans se plantent avec les gros projets C++ mais pour java, ils vont parfaitement. Pour le JS, vim ou netbeans font très bien l'affaire.(->Et là autant d'avis que de techno et d'utilisateurs)
Ce n'est que mon expérience mais elle est vraiment différente de ce que tu dis.
[^] # Re: Et MPI ?
Posté par tallion . En réponse au journal Petit tour d’horizon de la haute performance et du parallélisme. Évalué à 0.
pour rappel:
Et l'(Quasi-)Opportunistic Supercomputing en fait partie!
Si ca n'était pas du HPC pourquoi on le retrouve dans les conférences sur le HPC ?(regarde les papier dans HiHPC!!!)
Je m'excuse si je m'emporte mais c'est bien l'idée que j'essaie de combattre, le reste du monde a une autre définition… Ca va dans les deux sens, j'ai un autre à la maison avec son "mais le grid c'est pas du HPC, il y a pas de problème, ils utilisent pour de la simulation sur des données structurées et facilement découpables! Il y a rien à faire…" sur qui je m'énerve (et vais bientôt commettre un meurtre), alors quand je vois l'opposé, ben j'ai envie de boire de la javelle en récitant des sumériens.
Toi, tu parles de Grid,Distributed and Parallel Computing mais ce n'est pas la même chose, une sous partie seulement, le HPC est plus grand (Optimizing Data Movement etc…).
[^] # Re: Et MPI ?
Posté par tallion . En réponse au journal Petit tour d’horizon de la haute performance et du parallélisme. Évalué à -1.
A je l'ai loupé ce commentaire :-)
<_Mode mauvaise fois on_>
Ha oui,toi tu parles du truc à scheduler statique dans la grille du genre: j'ai une voiture qui va à 200 km/h mais pour l'utiliser tu dois me prévenir 3 jours à l'avance et seulement pour sur la a46… Donc prends la 2 chevaux tu iras plus vite pour paris - lyon…
Et dire que ca pense faire du HPC…(pouvant être remplacer par web 2.0/ cloud ….)
<_Mode mauvaise fois off_>
Plus sérieusement, Hadoop est un framework et tu peux faire en mode flux (troll retour: "et utile pour les vrais gens")(storm) qui est quasi impossible sur le manière dont on manage les grilles aujourd'hui. Le but c'est d'être constructif sinon on troll sur tout!
Soit tu considères que les personnes qui n'ont pas les même besoin peuvent t'apporter des choses et vice versa, soit tu es comme certains chercheurs (heureusement une minorité) qui dès que ca dépasse leur domaine de recherche stricte considèrent que tout est débile. Moi je suis dans le premier cas :-)
PS: je ne fait pas de hadoop car je suis en basse latence pour mes calculs
[^] # Re: Et MPI ?
Posté par tallion . En réponse au journal Petit tour d’horizon de la haute performance et du parallélisme. Évalué à 2.
J'espère plus quand on voit ce que donne presto
Quand tu parle de python, tu parles bien de python sans cython/pythran and co?
On est d'accord que si l'algo et l'implémentation sont dégueulasses ca ne marchera pas. Mais on parle de développeur dont c'est le métier, on sait tous parfaitement faire des caches intermédiaire pour pas tout recalculer ou utiliser des patterns aux bon endroit quand il y a un point bloquant.
Je m'excuse si je passe à côté de quelque chose et je peux avoir tord mais ici j'arrive pas à voir ce que je manque: j'ai toujours cette vision de la compression de maillage 3d basé sur un octree et un ordre de morton où python me tue les performances par rapport au C++ (simd etc…)
[^] # Re: Et MPI ?
Posté par tallion . En réponse au journal Petit tour d’horizon de la haute performance et du parallélisme. Évalué à -1.
Pour moi c'est un IO, tout comme la lenteur de la global memory d'OpenCL ou de la ram par rapport au cache mais le mot est peut être mal employé, désolé.
De plus, j'ai l'impression que tu parles de grilles de calculs là où je parle de clusters plutôt orienté statistiques/données, ce qui n'est vraiment pas la même chose:avec la simulation on arrive tout de suite sur le micro HPC couplé au macro
[^] # Re: Et MPI ?
Posté par tallion . En réponse au journal Petit tour d’horizon de la haute performance et du parallélisme. Évalué à 1.
Je suis d'accord avec toi, le HPC dans nos tête c'est la ferme de serveur…
Même si ce n'est pas visible dans le titre, j'ai bien essayé de parler de macro HPC (distribué sur des milliers de nœuds) et micro (travail parallèle sur une même machine). Cependant les concepts restent les mêmes: je parallélise mon calcul que ce soit entre les machines ou les cœurs du processeur.
C'est pour ca que j'ai omis MPI, j'avais peur que cela embrouille le lecteur entre ce qui est distribué et ce qui ne l'ai pas.
Complètement d'accord, je pense que la raison vient du fait que c'est plus simple de communiquer sur une innovation matérielle qui touche tout le monde que sur son algo lock-free dont le parallélisme varie linéairement avec la taille du tableau (et qui solutionne un problème précis comme la compression d'image de radio médicale)
Pour python, je dirais plutôt que dans la majorité des cas du macro HPC, les performances sont largement suffisantes car le goulot d'étranglement sont les IOs (disques/réseaux) donc il n'est pas utile de se prendre la tête.
[^] # Re: Finalement
Posté par tallion . En réponse au journal Petit tour d’horizon de la haute performance et du parallélisme. Évalué à -1.
Même l'actor model? Pour le map/reduce (et hadoop en générale) je comprend qu'il y a toujours des galères dans le cluster mais j'étais certain que les acteurs marchaient très bien quand ils étaient utilisés au bon endroit…
[^] # Re: Intéressant
Posté par tallion . En réponse au journal Petit tour d’horizon de la haute performance et du parallélisme. Évalué à 2.
Merci pour la clarification/complément :-)
Un papier scientifique où l'implémentation de référence serait dans le navigateur ou encore , un truc complètement fou, faire un VLC dans firefoxOS! Je vois plein de raison et en plus ça m'amuse :-)
Côté plus terre à terre, si je suis capable de le faire côté client , je pourrais alors offrir la même chose côté serveur et mutualiser les ressources entre plusieurs utilisateurs sans provoquer de problèmes de sécurité (si mon serveur possède un GPU pour accélérer les calculs par exemple, sans devoir acheter du matérielle spécialisé).
Pour WebCL, je participe un peu à la définition donc, même si j'essaie d'être impartial, je dois probablement être biaisé quand j'en parle… j'ai un google doc de 5 pages sur des tests de codes, des critiques de webCL,asm.js,dart etc et j'hésite à en faire (encore) un journal car c'est vraiment technique et spécifique.
Pour l'aspect distribué, ce qui serait marrant c'est de voir en quoi le navigateur comme nœud influence le scheduler qui distribue les jobs, mais là j'ai pas regardé et il me manque de la lecture sur les papiers…
[^] # Re: Mauvais langage, changer de langage?
Posté par tallion . En réponse au journal HTML 5 : geometry, encore une API?. É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: Quelque chose m'échappe
Posté par tallion . En réponse au journal Ayé, Firefox sait utiliser GStreamer pour décoder H264, AAC et MP3. Évalué à 4.
mozCorp appartenant 100 % à la fondation, là c'est de la technique fiscale, tu ne penses pas?
De toute façon, est ce que cela change quelque chose? Intellectuellement, séparer les deux pour amoindrir les responsabilités de chacun, c'est un peu facile… Mais comme dit dans le titre du commentaire, il y a peut être quelque chose qui m'échappe.
# Quelque chose m'échappe
Posté par tallion . En réponse au journal Ayé, Firefox sait utiliser GStreamer pour décoder H264, AAC et MP3. Évalué à 2.
Je suis plutôt pro firefox et le fait que mozilla soit capable de passer outre le dogme pour répondre à un besoin, je peux comprendre…
Mais se réjouir d'une des défaites du web ouvert!
En plus, ce qui me gêne c'est que se soit quelqu'un de mozilla et non une contribution externe car ca veut dire que les dons (aussi infime que cela représente) ont aussi servi à légitimer des patents!
[^] # Re: Bidouille
Posté par tallion . En réponse au journal Réflexion sur ASM.js ou quand le javascript deviens enfin performant :. Évalué à 9.
Merci pour les retours.
Je ne suis pas sûr de comprendre la remarque. On a un code dont la représentation me permet de créer un IR vraiment proche de ce que tu aurais avec du code C bas niveau généré par clang . Du coups, je ne vois pas en quoi le langage est un problème ici…
Les cas que je vois sont par rapport au C/C++, lorsqu'on utilise des fonctionnalités bas niveaux (comme SSE…). Sauf qu'avec ces optimisations, tu n'es plus portable, c'est à dire plus dans le navigateur.
Tu peux aussi voir asm.js comme un tout nouveau langage dédié à l’efficacité, une sorte de bytecode du web. Partant de ce constat, je le trouve vraiment très très lisible comme représentation intermédiaire (comparé à llvm IR, le bytecode java…).
Ici, on parle d'avoir des performances. Avec Rust ( ou même dart/java/C++ ), si tu veux des performance, tu vas définir un sous ensemble à utiliser.Pourquoi ne pas simplement le faire directement dans le langage déjà utilisé ?
Depuis des années, on améliore un produit plutôt que d'écrire des pseudo révolutions toutes les 5 minutes. C'est plutôt un bonne chose de mon point de vue. Finalement, je ne suis pas d'accord que ce soit un problème, mais je n'ai pas d'argument vraiment pertinent donc, je vais considérer que je me trompe.
Maintenant, je ne suis pas chez mozilla, mais personnellement, je ne vois Rust comme une solution viable et intégrable rapidement pour répondre aux problème de performance, je préfèrerai avoir directement du C sandboxé.
[^] # Re: Gentil
Posté par tallion . En réponse au journal Comment Freedesktop divise le desktop. . Évalué à 2.
Bon tu vas peut être me taper dessus aussi mais je ne suis pas sûr que tu vois tout le tableau ( je connais peu ces specs là mais j'ai un peu d'expérience dans les groupes de standardisation):
- Soit tu fais une spec rapide, tout en sachant qu'elle est vraiment moyenne mais en te disant qu'avec le temps tu vas l'améliorer car on peut pas tout prendre en compte en même temps => les gens se plaignent que tu es nul
- Soit tu prends tout ton temps et tu mets 2 à 5 ans pour sortir ta spec et… ben au bout de 5 ans, l'environnement et le besoin ont évolué!
Le plus grand problème, généralement, c'est surtout le manque de moyen et du coups, ca se ressent au niveau des prototypes, tu ne penses pas?
Bon après, j'avoue que parfois l'aspect politique pourrit souvent des drafts et implémentations.
[^] # Re: ca fait peur
Posté par tallion . En réponse au journal Quelques aspects de la securite qui n'ont rien a voir avec le "Sandboxing" . Évalué à 3.
Je suis un peu gêné par tes propos car tu exposes un problème générale comme si ca provenais de WebGL.
Tu peux réaliser du DoS avec un peu n'importe quoi... Ca à déjà été fait avec les décodeurs jpeg, j'en avais même trouvé un dans le format WebP alors que je ne me considère pas comme un codeur fou (et pour mon plus grand malheur avait déjà été reporté :) ou le javascript lorsque l'interpréteur ou le compilateur JIT à des bugs!
WebGL est une adaptation d'OpenGL ES pour le web, je ne vois pas le problème. Ca reviendrait à dire que le java ne peut pas être intégré comme langage web (quoi dart? ;) ou que le JS ne peut pas faire du serveur (nodejs). Bien sûr, il faut ajouter ou enlever quelques fonctionnalités et le résultat sera plus ou moins adapté, mais c'est toujours possible.
Si c'est difficile et ajoute un risque, on ne doit rien faire? Dans ce cas les compilateurs JIT des moteurs javascript ne devraient pas exister. D'autant plus que, si j'ai bien compris, le vrai problème ne se situe pas vraiment au niveau de l'OS mais des drivers mal fait, drivers qui sont blacklisté et désactive WebGL. On a déjà vue pire pour des drivers réseaux et c'est hautement plus crucial car faire planter serveur ca n'a pas le même impact qu'un poste client. Du coups, je débranche internet?
A noter que les sources de WebGL (les shaders) sont aussi compilé à la volé, un peu comme le javascript donc il est possible de le rendre parfaitement sécurisé, soit en faisant des vérifications formelles soit en ajoutant des watch sur les opcodes bas niveau ou un mix des deux. Le problème, j’imagine, c'est que les fabricants doivent préférer le faire eux même car ca impacte beaucoup les performances. Je crois qu' ANGLE* fait une partie de ces vérifications (*la lib ajoutant OpenGL ES au dessus de directX)
C'est le cas pour toutes nouvelles fonctionnalités et pas seulement dans le monde du navigateur mais aussi dans le kernel, les solutions de virtualisations (oui je triche, un navigateur c'est un OS virtualisé pour moi)...
Je ne sais pas si j'ai été clair et je m'excuse si ce n'est pas le cas : j'ai tendance à m'égarer dans mes propos.
[^] # Re: Modération
Posté par tallion . En réponse au journal Quand Oracle parle à Hudson. Évalué à 2.
...
désolé.
Pour le vache à lait, c'était en référence à http://www.marketing-strategique.com/Matrice-BCG.htm
Ceci étant dis, je lis les journaux de Patrick_G tout comme toi!
Cependant faire des commit dans le noyau,c'est moins chère que d'appliquer les patchs à chaque fois pour que tes produits fonctionnent mieux: C'est une vérité économique que je connais et c'est aussi ça, l'open source d'entreprise... mais seulement le premier niveau!
Ce que je sais c'est qu'Oracle est capable de tuer un projet+ communauté très rapidement si il pense que du cash facile est derrière (je pense que c'est un mauvais choix à moyen terme, mais après tout ...).
Je sais AUSSI que les gens d'Oracle ont aidé Linux, de façon déterminante dans les années 90 et qu'ils ont un très bon produit de haute dispo basé dessus etc...
Mais faire de l'open source et en avoir une culture, ça n'est pas juste des logiciels ou des commits, c'est aussi animer une communauté pour que la réalisation soit la meilleur possible (cercle vertueux servant aussi l'entreprise qui pourra vendre plus facilement du support, des évolutions, des nouveaux besoins... )
Ce que je leur reproche, c'est qu'ils traitent la communauté comme des employés qu sont bénévoles et remplaçable et donc qui n'ont pas leur mot à dire dans l'évolution des logiciels. Contrairement à ce qu'il semble** se passer chez oracle, dans les communautés open sources, on ne marche pas à la hiérarchie mais plutôt à la méritocratie! (tu ne dira pas de mal sur les marketeux, non, non ,NON). Je sais que ce principe là peux souvent engendrer pas mal de discussion (et trolls), mais c'est, AMHA, un petit prix face au bénéfice. Maintenant avec tout les départs de la société et les problèmes avec les communautés, je confirme ce que j'ai dit :
Après, je n'arrive pas à savoir si oracle a de bonnes intentions mais que l'open source n'est vraiment pas dans la culture de l'entreprise ou simplement qu'ils considèrent ça comme un sous produit qui fait perdre de l'argent sur le dos des vaches à lait que nous sommes. ..
J' ajouterai seulement sur certains marchés
Maintenant si tu as des éléments que je ne connais pas, ou comprend pas, et si tu souhaites les partager avec nous, je serais ravi de changer d'avis.
**j'insiste vraiment sur le semble car les grosses boîtes, c'est particulier)
[^] # Re: N'oubliez pas de tester !
Posté par tallion . En réponse à la dépêche Firefox 4 bêta disponible pour tests (et plus si affinités). Évalué à 3.
Sous arch, je suis en nightly pour pas mal de truc (gnome,vala, chromium, firefox...) car c'est très facile de faire en sorte d'utiliser les sources ou les repos (en plus yaourt, une surcouche au package manager, permet de faire les updates automatiquement si ton repo est un svn,git ou hg :)
Pour s'en convaincre, il suffit de regarder le fichier permettant d'avoir les nightly de firefox:
http://aur.archlinux.org/packages/firefox-nightly/firefox-ni(...)
Je fais donc des packages même sur ce que je code et sincèrement, quand tu fais du dev, ca permet de garder une distribution propre et c'est pas plus mal.
[^] # Re: oui
Posté par tallion . En réponse au journal utf8 puxor. Évalué à 3.
[^] # Re: Solution
Posté par tallion . En réponse au journal Free.fr crie sa misère. Évalué à 3.
C'est plutôt ces principes de rentes qu'on devrait interdire et encourager la création (industrielle,artistique ou de services)
[^] # Re: une erreur?
Posté par tallion . En réponse à la dépêche Sony supprime définitivement l'OtherOs de la PlayStation 3. Évalué à -5.
# Un manque pour le C
Posté par tallion . En réponse à la dépêche Soirée Maven 3 à Grenoble. Évalué à 1.
C'est d'ailleurs un manque, à mon avis, quand on code en C: un waf/scons avec un système de plugin et une gestion des dépendances (par les sources :) à la maven. On a bien jhbuild de gnome mais c'est pas encore la panacée ( même si le sujet reviens souvent:
http://mail.gnome.org/archives/vala-list/2010-March/msg00049(...)