URL: https://linuxfr.org/users/tallion/journaux/petit-tour-d-horizon-de-la-haute-performance-et-du-parallelisme Title: Petit tour d’horizon de la haute performance et du parallélisme Authors: tallion Date: 2013年11月08日T04:29:27+01:00 License: CC By-SA Tags: opencl, gpgpu et openmp Score: 23 (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](http://fr.wikipedia.org/wiki/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](http://en.wikipedia.org/wiki/SPMD) ): 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](http://en.wikipedia.org/wiki/Actor_model) : le model d’acteur de [scala](www.scala-lang.org) ou les [webworkers](http://en.wikipedia.org/wiki/Web_worker): 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](http://en.wikipedia.org/wiki/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](http://storm-project.net/) 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](http://fr.wikipedia.org/wiki/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](http://en.wikipedia.org/wiki/OpenMP) en anglais est relativement bien fait. RenderScript: ------------- Contrairement à son nom, [l’API d’android](http://developer.android.com/guide/topics/renderscript/index.html) 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](www.khronos.org/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] (http://streamcomputing.eu/blog/2013-08-01/google-blocked-opencl-on-android-4-3/) ).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](https://brendaneich.com/2013/05/today-i-saw-the-future/) 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] (http://en.wikipedia.org/wiki/Glide_API). 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 :]

AltStyle によって変換されたページ (->オリジナル) /