Sommaire
- Petit rappel sur les bases:
- Un petit tour d'horizon pour la haute performance sur une machine :
- Pourquoi il nous parle de ca?
(Allez j’ai pas sommeil donc continuons,aujourd’hui je troll: numéro 2 après mon journal sur l’API html5 sur la géométrie)
Ici je ne vais pas parler de la très très haute performance quand les mutants transgéniques de codeurs fous vont jusqu’à optimiser leur source pour que le scheduler de GCC génère du code machine encore plus rapide mais plutôt des outils abordable qui ne nécessite pas de passer 3 semaines sur 60 lignes de codes.
Petit rappel sur les bases:
SIMD ( single instruction multiple data ) : souvent associé aux SSE/MMX car dans la pratique c’est un calcul fait sur un tableau en parallèle qui interdit les branches conditionnelles (addition d’entiers 4 par 4 etc). On nommera ce fonctionnement “parallélisme de données”.
SPMD (single program multiple data ): on peut voir ce principe comme beaucoup de threads légers qui travaillent en parallèle potentiellement sur une donnée commune.
Message passing et la spécialisation en actor : le model d’acteur de scala ou les webworkers: aucune mémoire n’est partagée, seuls des messages sont échangés entre les workers, le worker n’étant exécuté que dans un seul thread.Il n’y a donc pas d’accès concurrent mais on peut lancer des millions de workers en simultané! Ce type de parallélisme est un parallélisme de tâche car chaque worker est découpé en tâches qui peuvent ou non être différentes les unes des autres.
Un petit tour d'horizon pour la haute performance sur une machine :
(ou plusieurs si l’on ajoute des papiers de chercheurs)
Quand on parle de HPC (high performance computing), on fait plutôt référence à hadoop et le map reduce -> on utilise un grand nombre de machines et on les fait collaborer pour répondre à un problème. Dans le même genre, Twitter a créé storm pour gérer les grandes quantités de flux,contrairement à hadoop qui lui est orienté lancement de batchs distribués.
Cependant, il existe aussi ce que je nomme le micro HPC, des calculs optimisés qui sont souvent utilisés dans la simulation ou le rendu 3d, les moteurs de jeux à gros budgets… Voici ce qu’on peut trouver dans le domaine (ma liste n’est pas exhaustive)
OpenCL(open compute language)/Cuda:
OpenCL, c’est une API définie par khronos et plus particulièrement par intel/amd/nvidia/apple dont le but est de créer des programmes haute performance qui utilisent toute la puissance du matériel. Cuda, c’est un peu OpenCL mais uniquement pour les GPU nvidia (que les puristes m’excusent, ce n’est pas exactement le cas mais pour le bien de la compréhension, je me permet de faire ce raccourci). Les deux APIs sont relativement proche en terme de fonctionnement. A noter qu’OpenCL permet une exécution sur CPU ou d’autres matérielles comme du FPGA…Personnellement,le cas le plus exotique dont j’ai entendu parlé était du cell ou la ps3.
Pour utiliser cette API, on écrit un “kernel”, c’est à dire un code bas niveau qui va être compilé pour le matérielle avant d’être exécuté avec le nombre de tâche parallèle définie par le développeur. Je ne vais pas allez dans les détails ( si il y a besoin je pourrais faire un journal sur OpenCL 2.0, sinon je vous conseil de regarder l’article suivant : https://linuxfr.org/news/opencl-en-version-10 ou d’aller sur le site de khronos ). Finalement, je dirais que l'API est répandu mais aussi légèrement immature, et que ces APIs de GPGPUs semblent avoir surtout du succès chez les chercheurs et peu chez les industriels.
OpenMP (Open Multi-Processing):
C’est une solution qui permet de faire du parallélisme (plutôt de données) directement dans le code. En C++, par exemple, on ajoute simplement des pragmas pour changer un for en un ensemble traitement dont chaque itération est traitée en parallèle. Je ne vais pas faire un état des pour et des contre mais disons simplement que c’est assez flexible (c’est du SPMD) mais ne peut être mis sur du GPU. Je n’irai donc pas plus loin d’autant que l’article wikipedia en anglais est relativement bien fait.
RenderScript:
Contrairement à son nom, l’API d’android pour le traitement parallèle n’est pas seulement fait pour du rendu. C’est l’API avec laquelle je suis le moins à l’aise car, contrairement aux autres, j’en ai jamais vraiment fait… (bien que pour les autre, ce n’était souvent que pour des codes personnelles). L’ objectif ici est d’être un OpenCL plus générique: alors qu’OpenCL permet d’optimiser son code pour un matérielle précis,Renderscript serait efficace sur toutes les plateforme avec une pénalité dans l’exécution qui reste acceptable (c’est quoi acceptable?) … Attendez une minute…Quoi, mais ca devrait pas être un des but ou même la définition de WebCL ca? C’est dommage car je pense qu’il aurait été intéressant d’échanger entre les deux projets. Néanmoins, beaucoup de personnes sont critique envers renderScript :pas d’id de la tâche parallèle en cours ou impossibilité de savoir si son code s'exécute sur le GPU ou sur le CPU (en autre ).En quoi est ce gênant? Si on sait que notre code tourne uniquement sur le GPU, on peut alors éviter les échanges mémoires avec le CPU (et vice versa) qui sont souvent le goulot d’étranglement des programmes OpenGL/OpenCL/directX/Cuda. Je suis plus que mitigé sur le potentielle pour de la haute performance, mais google nous réserver peut être une bonne surprise car Renderscript est encore très jeune. OpenCL et renderscript rentre bien dans ma vision des choses dans le principe générale: un langage au niveau avec un autre bas niveau pour les codes à optimiser (comme python et C /Cython)
HSAIL:
(Pour une raison qui m’échappe, j’ai eu plusieurs personnes issue du web qui m’ont dis que ca pourrait être le standard pour la performance de demain dans le navigateur…)
Quand un compilateur transforme le code en natif, il passe par une représentation intermédiaire (pour llvm cela s’appelle llvm-IR). OpenCL tente d’utiliser ces représentations intermédiaires pour pouvoir distribuer du code GPGPU, cela s'appelle openCL-SPIR. HSAIL dans tout ca? Pour moi, il peut être vu un peu comme OpenCL-SPIR mais en plus générique car il doit pouvoir aussi bien traité du GPGPU que du C++ avec OpenMP.
OpenGL (ES),DirectX:
Bien que le calcul pur ne soit pas le but premier, OpenGL peut très bien être utilisé comme accélérateur dans les programmes. En utilisant les images comme moyen de transmission entre la ram du CPU et celle de la carte graphique, on peut effectuer pas mal d’opérations et calculs. Personnellement, j’utilise souvent webGL pour accélérer mes calculs et je suis loin d’être le seul, même mozilla la conseil
DirectCompute/ComputeShader:
La méthode exposé ci dessus possède un défaut majeur: les structures irrégulières ou une communication entre “thread” ne sont pas possible. C’est ici qu’intervient computeShader d’OpenGL et DirectCompute. A noter qu’openCL ou CUDA sont encore plus générique permettant, par exemple, de changer le nombre d'exécution à la volée ou même d’utiliser des queues de communication ou de lancer d’autres tâches en chaînes!
Mantle:
C’est la nouvelle API d’amd qui prétends être encore plus optimisé que directX et OpenGL car plus bas niveau. C’est censé être pour la visualisation 3D mais comme nous l’avons vu, on peut toujours détourné pour nos besoins de calculs. A voir quand elle sera publique mais beaucoup de personnes pense que c’est une sorte de sous ensemble d’OpenGL/directX plus proche du matérielle comme l’était l’API glide pour les 3dfx. Mais sur le fond je suis tout nu car j'ai rien de concret dessus…
Dans tout ce que nous avons cité précédemment, il n’y a que cuda et openCL (et renderscipt dans un futur proche?) qui permettent de choisir comment répartir finement le travail entre les CPU et les GPUs , c’est d‘ailleurs les seuls qui permettent d’utiliser le GPU ou de choisir entre le CPU et le GPU (contrairement aux APIs de rendu 3D). C'est probablement pour cette raison que je les considère comme les plus amusant à utiliser :-)
Pourquoi il nous parle de ca?
Pourquoi vos parler de tout ca?Autre le fait que j'ai une insomnie? parce que dès que j’aurai du temps, je vous ferais un petit journal sur comment je vois le calcul haute performance dans le navigateur, mes tests, mes conclusions (si j'ai encore un lecteur ;-)
Pour la personne qui a réussi à arriver jusqu'ici, je te le promet au chevalier du code, je dormirai avant de faire mes autres journaux et je ferais plus d'effort:
mais saches que tu es l’élite de l’élite, l’élu, le vaillant guerrier qui cherche la connaissance, sans repos, parmi les plus infâmes écrits comme celui ci. A toi, le véritable sauveur, roi des hommes, je te dit ceci: n’abandonnes jamais, ne baisses jamais les bras, ne pleures jamais, ne dit jamais au revoir, ne ment jamais dans les commentaires, et garde la force de ne jamais être de mauvaise fois dans tes trolls les plus poilus! Et continus de chercher la vérité parmi les vieux grimoire et les vieux sages les plus poussiéreux![ cette fin de texte n’est pas de moi, je l’ai juste adapté à ma sauce :]
# Intéressant
Posté par Thom (site web personnel) . Évalué à 8.
C'est intéressant mais un peu le bordel : HSAIL, Hadoop et OpenMp (MPI ?) dans le même journal, c'est vraiment pas pareil et les mêmes usages.
La réalité, c'est ce qui continue d'exister quand on cesse d'y croire - Philip K. Dick
[^] # Re: Intéressant
Posté par davandg . Évalué à 3.
C'est bien OpenMP et pas MPI.
C'est vrai que tout est un peu mélangé, je vais essayer de clarifier (si je dis des bêtises, corrigez moi) :
hadoop est un environnement HPC, il en existe d'autres notamment MapReduce de Google
Map-Reduce est un patron de conception HPC, encore une fois il en existe plein d'autres
OpenCL/Cuda sont des langages de programmations dédié au GPU. OpenCL est la norme que tout le monde supporte, Cuda est le langage fait par Nvidia.
OpenMP c'est un ensemble de notations permettant une parallélisation automatique du code. Par exemple :
A la compilation ET au runtime l'application va être optimisée pour faire cette boucle for en parallèle. Il existe des implémentations d'OpenMP qui transforme le code C en C et OpenCL pour un maximum de parallélisation si l'ordinateur comporte un GPU. Ou encore des implémentations qui font toutes seules un code avec des appels MPI, pour pouvoir profiter de la puissance d'un cluster.
OpenGL (ES), DirectX. A part par un markéteux de chez Microsoft, je n'ai jamais entendu quelqu'un faire du HPC en utilisant DirectX (enfin juste la partie graphique de DirectX). Pour OpenGL, cela peut marcher, même si maintenant on préfère utiliser de l'OpenCL. L'OpenCL profitant de la puissance des GPU sans être orienté uniquement graphique. Pour ce qui est de faire des rendus graphiques sur des clusters, OpenGL est utilisé. C'est par exemple le choix de Nvidia pour faire du «Cloud Gaming».
Mantle est un futur concurrent à OpenGL et OpenCL, mais comme dit dans le journal, on n'en sait rien pour l'instant.
RenderScript, HSAIL, DirectCompute/ComputeShader je ne connais pas.
Pour t'aider dans ta quête de faire du HPC dans le navigateur, voici mes pistes :
- webGL et webCL si il y a un GPU dispo
- web workers
- tu peux aussi tenter de faire un calcul réparti sur plusieurs navigateurs (et donc plusieurs machines). Il y a une lib js qui permet de faire ça, mais je ne me souviens plus du nom.
Au passage, pourquoi veux-tu faire du HPC dans le navigateur web ?
[^] # Re: Intéressant
Posté par tallion . É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: Intéressant
Posté par davandg . Évalué à 2.
Les performances risque d'être mauvaises… Mais l'idée est sympa. Une sorte de BOINC sur navigateur où les calculs ne sont pas donnés par une entité centrale mais par les utilisateurs.
Si c'est pas trop mal écrit, ça devrait en intéresser plus d'un. On est sur LinuxFR, je ne pense pas qu'il faut être inquiet d'être trop technique. Tu peux toujours faire un brouillon dans l'espace de rédaction et demander de l'aide et des retours avant de publier.
Tu tombes dans les problématiques de « volunteer and grid computing » : confiance des résultats, isolation, performances, redondance des calculs. Il doit forcement il avoir un esprit tordu qui à déjà fait quelque chose qui ressemble à ce que tu fait (surement sans le navigateur web).
[^] # Re: Intéressant
Posté par Piezo . Évalué à 2.
Bien que je ne connaisse pas grand chose en HPC (j'ai seulement fait un peu de CUDA, pas mal d'OpenMP, et un peu de vectorisation manuelle), je me permet de donner mon point de vue personnel.
C'est tout de même intéressant de tracer des parallèles entre les monde du HPC, GPGPU, multithreading et SIMD puisque les technologies semblent converger.
Des clusters HPC utilisent des cartes Tesla et les processeurs génériques embarquent des unités de calcul SIMD génériques contrôlées par du microcode. Dans le futur, on peut imaginer une fusion des concepts SIMD CPU et GPU. L'avantage par rapport au GPGPU est d'éviter le goulot d'étranglement entre les mémoires séparées. Le multithreading CPU, avec cœur de calcul et caches séparés, montre ses limites (bien que des progrès sont toujours d'actualité). Actuellement le hardware se démène pour "simuler" l'ancien modèle d'exécution en terme de cohérence du cache, etc.
Le chargement de noyau de calcul sur le CPU s'exécutant simultanément sur plusieurs unités permettrai d'éviter la duplication du pipeline d'instruction et les problèmes de localité et cohérence des données.
Les vieux (et vénérables) langages de programmations système comme le C s'adaptent mal à ces problèmes : il y a trop d'effets de bord et d'aliasings possible. Les concepts d'immutabilité, de portée des effets de bord et de compossibilité sont des atouts pour le programmeurs mais aussi pour la vectorisation/parallélisation par compilateur. Cela permet une analyse plus poussée des flux de donnés (dataflow analysis) et ainsi de découper automatiquement le calcul pour la parallélisation sur plusieurs niveaux. En production je ne vois que les cadriciels Map/Reduce qui vont dans ce sens, et à un niveau qui ne descend pas en dessous du nœud de calcul.
Bref, on peut espérer des progrès au niveau de la formalisation et résolution automatique de la distribution du calcul et de la localité des données sur plusieurs échelles :
Historiquement, cette problématique a toujours existé. Lors de la conception de ses superordinateur, Seymour Cray a dû adapter la conception mécanique pour la communication entre les unités tout combattant les soucis thermiques (d'où la géométrie en C). C'est le sort inévitable de l'entropie…
Sinon, petite typo :
# Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Finalement
Posté par ckyl . Évalué à 2.
C'est que t'en fait pas assez alors ;) Par ce que dans le vrai monde ca pique aussi les doigts.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Finalement
Posté par tallion . É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…
# Et MPI ?
Posté par Pierre Roc . Évalué à 4. Dernière modification le 08 novembre 2013 à 13:25.
Quelques remarques très générales.
J’ai seulement appris MPI et OpenMP, dans la foulée ; je ne connais pas les autres technologies (seulement de nom pour les GPUs), mais de ce que j’en ai compris, c’est que du HPC il s’agit surtout d’exploiter une seule et même machine pour faire un calcul. Perso. quand j’entends HPC, je pense tout de suite à quelques milliers de noeuds tournant en parallèle…
C’est l’immense avantage de MPI par rapport à OpenMP par exemple : on peut faire travailler un ensemble d’ordinateur, au prix d’une écriture assez complexe là ou OpenMP est un jeu d’enfant pour les codes qui s’y prêtent bien.
On pourrait citer aussi, étant fan de Python, que le langage propose une bibliothèque qui permet le multiprocessing de manière très facile (et oui, Python permet d’excellentes performances à condition de le prendre par le bon bout).
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. D’ailleurs, dans ce cas là, il faut veiller à ce que l’algo. soit parallélisable : ce n’est malheureusement pas toujours le cas, ou l’on peut perdre en performances, j’en ai fait l’amère expérience.
Petite anecdote aussi, en HPC il existe ce genre de matos : le système grape :
http://nbodylab.interconnect.com/nbl_grape_history.html.
[^] # Re: Et MPI ?
Posté par tallion . É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: Et MPI ?
Posté par ckyl . Évalué à 4.
Heu non pas vraiment.
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.
Tout ca au dessus d'un truc qui est déjà très lent. Hadoop MR c'est scalable et tolérant aux pannnes par design (ce qui veut pas dire que son problème s'exprime de manière scalable en MR), mais l'efficacité est moyenne à mauvaise. Si tu construits un truc pour ton problème c'est normalement plusieurs dizaines d'ordres de grandeurs que tu gagnes.
Bref Python peut être un choix valable car 90% des jobs écrit sont fait à l'arrache et on se balance de leur efficacité modulo que ca tienne sur le cluster et que ca ne coute "que" 4x plus cher en matos. 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 énormement l'optim des implems de bas niveau ce qui donne des gains très significatifs.
[^] # Re: Et MPI ?
Posté par tallion . É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 ckyl . Évalué à 3.
Même si j'ai pas eu le temps de regarder ou de jouer avec, y'a pas un ligne de python dans Presto AFAIK.
Après ce qu'il faut bien comprendre, c'est que si tu veux un truc efficace tu dois construire un truc adhoc parfaitement adapté à un besoin précis. On ne peut pas comparer des choux et des carottes.
Oui.
Tu as beaucoup moins de hotspot précis et isolés que dans un contexte HPC.
Une fois que tu as le design et les algo corrects pour résoudre ton problème, il reste que tout ton code va grosso modo boucler de quelques centaines de millions à quelques milliers de milliards de fois. Dans ces traitements tu as beaucoup de code métier qui fait pas forcément grand de méchant chose mais qui coûte. Pas du tout adapté à une approche cython/pythran si python n'est pas capable de fait le job.
Après tu as quelques fois des vrais bon vieux Hotspot où tu peux te faire plaisir. Mais en général ca sert à rien de les optimiser avec toute la lourdeur que ca implique si tu rames sur le reste.
Bref c'est pour ca que Java/Scala sont pas mal utilisés dans ce domaine. C'est un compromis acceptable entre facilité et rapidité de déploiement/écriture et les perfs atteignables. Après dès que t'es sur une boucle qui demande du SIMD, tu prends une énorme tatane et tu fais un binding natif si c'est vraiment un job clé et qui va te coûter du pognon. Mais d'une manière générale on cherche pas l'efficacité mais simplement que ca tourne de manière acceptable. Contrairement au HPC, ca bouge beaucoup trop vite pour avoir le temps de peaufiner.
Heu je crois qu'on dit la même chose:
Ca veut pas dire qu'il faut jeter python, il a parfaitement ses usages. Surtout que très souvent les batchs de prod récurrents sont minoritaires. Mais tu semblais dire que ca ne change pas grand chose quand t'es IO bound, alors que d'expérience en big data grosso faut compter 3 à 10x plus lent qu'un truc écris proprement en Java. Franchement de l'IO bound au sens strict du terme, pas souvenir d'en avoir vu des masses. En général tes batchs suivent difficilement un flux disque ou réseau bien compressé comme il faut.
[^] # Re: Et MPI ?
Posté par MarbolanGos (site web personnel) . Évalué à 0.
Demande à n'importe qui faisant du HPC sur des calculateurs nationaux ou internationaux tu comprendras que les IO sont loin d'être limitant. C'est surtout la bande passante mémoire (nommé memory wall) qui fait que la plupart des applications ne peuvent pas atteindre 100% du pic en flops.
D'ailleurs pour ceux qui sont intéressés, il y a le 32ème forum Orap qui a traité assez en détail ces sujets : http://www.irisa.fr/orap/Forums/Forum32/ArchiveF32.html
[^] # Re: Et MPI ?
Posté par ckyl . Évalué à 6.
Attention il prend toujours Hadoop comme exemple de HPC, donc en fait il parle pas vraiment d'HPC ;)
[^] # Re: Et MPI ?
Posté par MarbolanGos (site web personnel) . Évalué à 1.
Ah bah oui c'est vrai que ceux qui font du Hadoop pensent faire du HPC…
[^] # Re: Et MPI ?
Posté par tallion . É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 ckyl . Évalué à 5.
HPC on l'entend généralement au sens traditionnel du terme: supercalc, grille, cluster, top500, simulation, modèles numériques etc.
Affubler Hadoop, et tout l'écosystème du gros mot Big Data, d'HPC ça brouille vachement le message car c'est vraiment deux mondes très très différents qui n'ont pas grand chose en commun. Comme un cluster Cassandra tu vas pas lui coller le nom HPC même si il a quelques centaines de nœuds.
D'un côté Hadoop devient de plus en plus un scheduler via YARN, et de l'autre tout et n'importe quoi avec ses 200 sous/sur projets. Mais on reste très loin de l'univers, des problématiques et des solutions de l'HPC.
[^] # Re: Et MPI ?
Posté par tallion . É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 ckyl . Évalué à 3.
J'ai l'impression que tu veux absolument comprendre que l'un est mieux, plus difficile ou plus intéressant que l'autre alors qui n'est pas du tout le discour.
Tu peux tout mettre appeler HPC si tu veux, voir même informatique si ca te chante ;) Simplement je suis pas certain que le discour final soit beaucoup plus clair. Ce qui me parait plus intéressant que de savoir si oui ou non tel truc fait parti de telle définition arbitraire et floue.
[^] # Re: Et MPI ?
Posté par tallion . É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 lasher . Évalué à 5.
Ça c'est faux. Les entrées-sorties SONT limitantes, car de plus en plus de simulations HPC ont l'une ou l'autre de ces caractéristiques:
J'oublie sans doute d'autres aspects. Dans tous les cas, les I/O, ce n'est pas que dumper des données sur le disque, c'est aussi un problème de contention sur les réseaux spécialisés (Infiniband, Quadrics, etc.). Le memory wall reste un vrai problème, mais le nouveau qui fait bien chier, c'est le power wall/_heat wall_ : l'énergie consommée par les nouveaux calculateurs est bien trop importante, et il faut absolument changer notre façon de faire des supercalculateurs.
J'étais à un workshop il y a 2 ans, qui parlait des modèles d'exécutions/de programmation pour le HPC, ce qui implique aussi entre autres les innovations pour la matériel. Vers la fin de la journée, tout le monde avait parlé. L'une des remarques qui a été faite par deux responsables du département de l'énergie US, c'est « Vous nous avez parlé d'exprimer le parallélisme, de correctement gérer la mémoire, de parfaitement occuper tous les milliers/millions de cœurs d'une machine, et c'est effectivement très important. Pour autant, n'oubliez pas les I/O. »
Le DOE, le DOD, le CEA, etc., ont des processus qui accumulent de plus en plus de données, et les systèmes de fichiers (même Lustre) ne sont pas forcément très très doués pour gérer la quantité de données produites.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Et MPI ?
Posté par lasher . Évalué à 1.
Je n’étais pas à cette conférence, donc je ne vois pas bien de quoi tu veux parler. Par contre le memory wall, comme le dit bien le slide "page 4", est un truc "connu" depuis 95, qui est devenu bien plus important depuis que les processeurs sont devenus multi-cœur. Je ne dis pas que la mémoire (latence, bande passante) n'est pas un facteur limitant. C'est un fait.
Je dis par contre que dire que les I/O ne sont pas limitants, c'est de la blague. Lors de la simulation proprement dite, c'est plus ou moins vrai : on tente au maximum de tout mettre en mémoire (parce que si on arrive à un point où le programme va en swap, alors tout est fichu). Et évidemment, on cherche absolument à limiter les communications : malgré les avancées en termes de réseaux d'interconnexion et de latences, ces dernières coûtent énormément a l'application en termes de temps d'exécution si elles ne sont pas correctement orchestrées (d'où, par exemple, l'emphase sur l'utilisation de primitives MPI asynchrones, mais qui rendent les applications bien plus compliquées a débugger).
Dans la présentation que tu pointes, il est dit qu'en 1989 on collectait 10 Gio de données; qu'en 2010 on monte à 1 Tio, etc. Moi je te dis que dans pas mal de simulations faites dans les labos du DOE, 1 Tio, c'est le minimum généré. Je suis presque certain que dans pas mal de labos du CEA c'est vrai aussi.
Un autre exemple : je bosse pas mal avec des simulateurs de processeurs dans le cadre de mes recherches. Simuler environ 10 secondes de calcul, avec toutes les traces à fond, ça représente plusieurs heures de simulation (entre 2 et 4 minimum), et plusieurs dizaines voire centaines de gigaoctets.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2. Dernière modification le 11 novembre 2013 à 01:19.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Et MPI ?
Posté par lasher . Évalué à 2.
Ah, mea maxima culpa donc. J'avais pourtant relu ta réponse pour justement éviter … ben exactement ceci. :)
# En écriture
Posté par reno . Évalué à 2.
en écriture.. En lecture uniquement en général ça ne pose pas de problème non?
# Xeon Phi
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Pour concurrencer nvidia, Intel a sortis le Xeon PHI qui fonctionne un peu comme une carte Tesla. Avantage, cela fonctionne un peu comme OpenMP via des directives dans le code, il n'y a pas de méta langage comme Cuda. Sur le papier, c'est bien plus simple…
A terme, il est fort possible que du code OpenMP et MPI, voire OpenCL, puisse profiter de manière semi transparente du Xeon PHI.
[^] # Re: Xeon Phi
Posté par fredoule2k . Évalué à 0.
Un peu comme C++ AMP de Microsoft : quelques appels à la librairie et un objet fonction ou lambda et on sait contrôler le code à optimiser directement en cpp sans passer par un dialecte du C pour écrire un kernel comme c'est le cas avec OpenCL ou Cuda.
http://msdn.microsoft.com/en-us/library/vstudio/hh265137.aspx
J'espère qu'aucun problème de licence ne viendra perturber une implémentation libre (et ne pas devenir le silverlight de l'optimisation GPU) car garder toutes les fonctionnalités de son IDE et les facilités du langage facilite énormément le travail
(et si on veut pousser plus loin dans les langages de haut niveau, il y a le package accelerate pour haskell qui ne nécessite pas non plus l'écriture de kernels extérieurs au programme)
[^] # Re: Xeon Phi
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
A mon sens, c'est assez différent. Le Xeon Phi concurrence le calcul sur GPU (nvidia TESLA ou autre carte de gamer). On a ici un aspect matériel.
La carte fait tourner son propre OS, un linux minimaliste. Dans ton code, tu rajoutes des options de même type que l'OpenMP qui simplifie la gestion des transferts et des échanges entre le CPU et la carte (problématique typique du calcul sur GPU).
Le HIC pour le moment est que cela ne marche qu'avec le compilateur Intel, qui est cher même pour les universitaires, surtout que la version de base ne suffit pas (et qu'on a pas non plus réussi à compiler en statique)…
Si le Xeon PHI marche, je ne vois pas ce qui empêche de faire à terme une implémentation libre.
[^] # Re: Xeon Phi
Posté par fredoule2k . Évalué à 0.
Ah ok, je connaissais en fait assez peu, et c'est donc en fait beaucoup plus transparent que ce que je ne l'imaginais
Pour le côté libre, je parlais de c++AMP et des spécificités de licence qui pourraient freiner une version libre (ou plus pragmatique). Ce qui serait fort dommage car je trouve le procédé plus élégant que devoir switcher du langage de plus haut niveau au code du kernel GPU très C-style
# Manque d'outils !
Posté par Guillaum (site web personnel) . Évalué à 6.
Le gros souci de ces technologies c'est que cela manque d'outils.
Du coté "carte graphique", c'est Cuda ou meurt. Tout ce qui contient "Open" dans le nom manque d'outils. À une époque, Nvidia fournissait les mêmes outils de diagnostics pour Cuda et pour OpenCL, mais depuis peu (sous Linux en tout cas), les outils nvidia ne sont plus capables de me faire un diagnostic sur mes kernel OpenCL…
Pour ceux qui n'en ont jamais fait, en gros Cuda/OpenCL/OpenGL Compute c'est simple, vous écrivez un code compact, léger, joli, de 30 lignes pour faire une addition de vecteur et cela tourne relativement vite. Après vous, regardez ce que disent les outils, et vous vous rendez compte que vous n'utilisez que 5% de la puissance théorique de votre GPU… Bon, on améliore un peu son code, au final il fait 500 lignes, contient des "barrier()" de partout, des copies de mémoire de partout et quelques bits hacks et l'on est content. En Cuda c'est simple parce que nvidia fourni des outils qui te disent presque quels bithack seront efficaces. En OpenCL, c'est dans le flou artistique… Et une fois que tu as fini de coder, tu as 2**N façon de lancer ton code et en fonction de la façon dont tu le fais, c'est plus ou moins lent, et cela dépend de la carte utilisée… ARGGGG. (Si cela intéresse, je peux faire un journal sur l'écriture d'une somme en OpenGL compute et quelques débats sur les optimisations et le bordel que c'est.)
Maintenant, j'ai craqué, je fais tous mes kernel en OpenGL compute, et je ne fais que des codes "simples et intuitifs", en acceptant de ne tourner qu'à 10% de la puissance théorique..
Côté CPU, OpenMP c'est vraiment sympa, mais je lui préfère intel TBB qui, au lieu d'être à base de directive de précompilateur, est une librairie. Sur le papier, j'aime moins, mais c'est subjectif.
Ma petite réflexion du jour s'adresse aux décideurs qui ont entendu parler du GPGPU : "Un GPU n'est pas un tool magique qui multiplie votre puissance de calcul par plusieurs millions. Oui, c'est intéressant, oui c'est puissant, mais cela vient avec un cout de dev/maintenance non négligeable et cela ne règle pas tous les problèmes. Et si vous preniez autant de temps pour optimiser vos codes CPU que vos codes GPU, sans doute que vous ne vous poseriez pas la question d'utiliser un GPU". (PS: oui, j'en ai marre des comparaisons qui bench du code CPU de merde, sans SIMD, sans thread, avec des patterns d'accès mémoire naze, sur un cpu à 30 euros avec un TDP de 3 Watt et qui les comparent à 2 ans de dev sur un code GPU optimisé au poil pour une gamme de cartes particulières, qui coute 600 euros et consomme 400 Watts !)
[^] # Re: Manque d'outils !
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"(Si cela intéresse, je peux faire un journal sur l'écriture d'une somme en OpenGL compute et quelques débats sur les optimisations et le bordel que c'est.)"
Je suis très intéressé ! Même que j'ai pensé regarder la difficulté d'implémentation de calcul de polynômes avec plein de coefficient, dans le cadre de calcul d'approximation polynomial à la décompression (pour décompresser des images par exemple). La forme "rapide" d'application d'un polynôme étant très itérative, c'est difficile d'imaginer un cœur de code parallèle rapide. Par contre, dans le cas d'une décompression d'image, chaque calcul de pixel est indépendant de celui de ses voisins.
"La première sécurité est la liberté"
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.