Compilation efficace d applications de traitement d images pour processeurs manycore Soutenance de thèse Pierre Guillou mercredi 30 novembre 2016 MINES ParisTech, PSL Research University
Évolution des capacités de calcul 1987 2000 2016 2/52
De nouvelles architectures Limitations des processeurs monocœurs fréquence d horloge bloquée depuis 2005 consommation d énergie systèmes embarqués utilisation efficace des transistors? Nouvelles architectures parallèles processeurs multicœurs GPGPUs processeurs manycores jusqu à 10 cœurs SIMD, 30 4000 cœurs 60 300 cœurs The free lunch is over. Now welcome to the hardware jungle. Herb Sutter, 2011 3/52
Les processeurs manycore : le MPPA de Kalray 256 cœurs de calcul, 10 W 2 générations : Andey (400 MHz), Bostan (600 MHz) 4/52
L architecture du processeur MPPA Cluster d E/S Machine hôte PCI-E 16 Go/s Cluster de calcul Cluster de calcul Cluster de calcul Cluster de calcul Cluster d E/S Cluster de calcul Cluster de calcul Cluster de calcul Cluster de calcul Cluster de calcul Cluster de calcul Cluster de calcul Cluster de calcul Cluster d E/S Mémoire locale (3 Go) DDR 13 Go/s Cluster de calcul Cluster de calcul Cluster de calcul Cluster de calcul Cluster d E/S 16 clusters (16 cœurs + 2 Mo) 5/52
Le traitement d images, un domaine innovant et dynamique 6/52
Une branche : la morphologie mathématique Propriétés géométriques détection, extraction Algèbre d opérateurs images réguliers, parallèles arithmétiques unaires & binaires «morphologiques» érosion, dilatation, convolution réductions min, max, somme 7/52
Application de traitement d images sûreté licenseplate : détection de plaque d immatriculation 8/52
Application de traitement d images santé retina : détection des lésions de la rétine 9/52
Difficultés du développement logiciel Applications matériels fonctionnalités matériels cibles optimisations temps de développement travail de portage fluidité, temps de réponse, autonomie Enjeux : les 3P programmabilité portabilité performance temps de développement, maintenance cibles matérielles temps d exécution, énergie 10/52
Classes d architectures et modèles de programmation Mémoire partagée distribuée MPI PGAS Flot de données OpenMP OpenCL kernels Pthreads OpenCL TPP Flot de données OpenCL 2.0 SVM homogène hétérogène Architecture 11/52
Plan 1 Méthodologie de recherche 2 I Le modèle OpenMP 3 II Le modèle flot de données 4 III Le modèle OpenCL 5 Quel modèle choisir? 6 Conclusions & Perspectives 12/52
Méthodologie de recherche
Méthodologie de recherche Sujet compilation efficace traitement d images architectures manycore 1 programme 3P utile, parallèle complexité vs. énergie Étude de cas le processeur manycore MPPA de Kalray le traitement d images par morphologie mathématique des langages de traitement d images (DSLs 3P) 13/52
Contributions principales Comparaisons expérimentales sur MPPA 3 modèles de programmation parallèle 2 générations de processeurs Preuve de la possibilité d atteindre les 3P développement d un environnement logiciel intégré regroupant plusieurs chaînes de compilation restreint au traitement d images 14/52
SMIL : Simple (but efficient) Morphological Image Library SMIL app.cpp SMIL app.py applications runtimes SMIL Python (wrapper Swig) SMIL lib matériels Processeurs multicœurs 15/52
Exemple de code SMIL import smilpython as smil imin = smil.image("input.png") imout = smil.image(imin) smil.gradient(imin, imout) imout.save("output.png") # lecture sur le disque # allocation de imout # gradient morphologique # écriture sur le disque 16/52
FREIA : FRamework for Embedded Image Applications DSL & API FREIA app.c Optimisations à la compilation applications runtimes FREIA common runtime Fulguro OpenCL SPoC Terapix matériels Processeurs multicœurs GPUs FPGAs 17/52
PIPS pour FREIA Compilateur source-à-source entrée DSL : code C + appels FREIA optimisations spécifiques traitement d images : décomposition des opérateurs complexes élimination des temporaires élimination des sous-expressions communes propagation des copies fusion d opérateurs sortie, génération de code : FREIA simplifié SPoC, Terapix (FPGAs) OpenCL Sigma-C 18/52
I Le modèle OpenMP
OpenMP, un modèle pour architectures à mémoire partagée Mémoire principale Cœur 0 Cœur 1 Cœur 2 Cœur 3 19/52
Addition de vecteurs en OpenMP void vecadd(float *a, float *b, float *c, const unsigned int n) { unsigned int i; #pragma omp parallel for for (i = 0; i < n; i++) c[i] = a[i] + b[i]; } 20/52
Environnement d exécution OpenMP : 1 cluster Processeur hôte Cluster E/S Cluster de calcul Application Lectures Écritures PCIe Transferts NoC Bibliothèque OpenMP 21/52
Portage SMIL sur 1 cluster MPPA SMIL bibliothèque C++, OpenMP CMake compilation croisée transferts avec l hôte mémoire très limitée : 2 Mo standard portage rapide 3 environnements imagettes 22/52
Évaluation : passage à l échelle de SMIL avec OpenMP Speedup (1 cluster) 6 4 2 anr999 antibio burner deblocking licenseplate retina toggle GMEAN 0 1 2 4 6 8 10 12 14 16 Nombre de threads OpenMP petites images 23/52
Bibliothèque OpenMP sur MPPA SMIL MPPA portage direct et rapide 1 cluster de calcul / 16 environnements d exécution passage à l échelle limitations mémoire compilation croisée modèle mémoire transferts de données imagettes mixer avec des communications inter-clusters réduire l empreinte mémoire 24/52
II Le modèle flot de données
Le flot de données vol < w1_0 Le modèle et les langages imin D8 E8 E8 E8 E8 w2 graphe producteurs/consommateurs années 1970 adapté aux exigences industrielles adapté aux architectures parallèles KPN Lustre/SCADE StreamIt Sigma-C, un langage flot de données développé pour le MPPA CEA List Andey, Bostan 25/52
Agents Sigma-C entrée 0 sortie entrée 1 Agent interleave agent interleave() { interface { in<int> in0, in1; out<int> out0; spec{ in0[2], in1, out0[3] }; } void start() exchange(in0 i0[2], in1 i1, out0 o[3]) { o[0] = i0[0], o[1] = i1, o[2] = i0[1]; } } 26/52
Subgraphs Sigma-C Agent 2 Agent 4 Agent 1 Agent 5 Subgraph 3 Subgraph bar subgraph bar() { interface { in<int> in0[2]; out<int> out0, out1; spec { { in0[][3]; out0 }; { out1[2] } }; } map { agent a1 = new Agent1(); agent a3 = new Subgraph3(); connect(in0[0], a1.input0); connect(a5.output, out1); connect(a1.output0, a2.input); connect(a3.output, a5.input1); } } 27/52
Conversion de FREIA en Sigma-C À partir de code FREIA séquentiel freia_aipo_threshold(im1, im0, 50, 150, true); // arithmétique freia_aipo_erode_8c(im2, im1, kernel); // morphologique freia_aipo_dilate_8c(im3, im2, kernel); // morphologique Générer automatiquement des subgraphs Sigma-C subgraph foo() { int16_t kernel[9] = {0,1,0, 0,1,0, 0,1,0};... agent thr = new img_threshold_img(); agent ero = new img_erode(kernel); agent dil = new img_dilate(kernel);... connect(thr.output, ero.input); connect(ero.output, dil.input);... thr im1 ero im2 dil } im0 im3 28/52
Contraintes sur les applications Sigma-C Agents 1 agent 1 cœur de calcul 2 Mo pour 16 cœurs coût d itération fixe utilisation partielle mem(1 agent) 128 ko grouper les pixels par lignes Graphes débit : nœud le plus lent équilibrage fusion/fission placement : communications inter-clusters peu de clusters temps d activation constant gros graphes 29/52
Fusion des opérateurs arithmétiques ero +1 dil /2 30/52
Fusion des opérateurs arithmétiques ero dil (_ + 1) (_/2) 30/52
Optimisation : réduction des communications void freia_cipo_geodesic_reconstruct(freia_data2d *immarker, freia_data2d *immask) { int32_t volcurrent, volprevious; freia_global_vol(immarker, &volcurrent); do { volprevious = volcurrent; freia_dilate(immarker, immarker); freia_inf(immarker, immarker, immask); freia_global_vol(immarker, &volcurrent); } while (volcurrent!= volprevious); } pas de boucle dynamique en Sigma-C while sur hôte reconstruction géodésique : suite stationnaire d itérations = déroulement partiel 31/52
Chaîne de compilation FREIA Sigma-C FREIA app.c compilateur source-à-source code de contrôle subgraphs Sigma-C bibliothèque d agents Sigma-C compilateur hôte compilateur Kalray binaire de contrôle sur hôte binaires de calcul sur accélérateur 32/52
Environnement d exécution Sigma-C Code de contrôle Agents Sigma-C hôte Clusters E/S Clusters de calcul lecture écriture traitement 1 envoi lancement calcul réception Unix pipes transfert transfert transfert PCIe envoi réception NoC traitement i écriture lecture traitement n 33/52
Évaluation : Sigma-C sur multicœur et MPPA Speedups 8 6 4 2 Sigma-C sur i7 Sigma-C sur MPPA 0 anr999 antibio burner deblocking licenseplate retina toggle GMEAN 34/52
Flot de données et processeurs manycore vol FREIA Sigma-C MPPA bibliothèque d opérateurs imin D8 E8 E8 < E8 w1_0 E8 w2 compilation source-à-source FREIA Sigma-C environnement d exécution pour E/S optimisations pour le processeur MPPA Résultats modèle strict compilation automatique bonnes performances sur MPPA publication LCPC 2014 morceaux d applications 3P malgré usage partiel 35/52
III Le modèle OpenCL
Modèles pour architectures hétérogènes OpenCL Host.................................... Processing Element Compute Unit Compute Device 36/52
Addition de vecteurs en OpenCL : noyau de calcul kernel void vecadd( global float *a, global float *b, global float *c, const unsigned int n) { unsigned int id = get_global_id(0); } if (id < n) c[id] = b[id] + a[id]; 37/52
Addition de vecteurs en OpenCL : code hôte // Initializations clgetplatformids(1, &cpplatform, NULL); clgetdeviceids(cpplatform, CL_DEVICE_TYPE_GPU, 1, &device_id, NULL); ctx = clcreatecontext(0, 1, &device_id, NULL, NULL, &err); q = clcreatecommandqueue(ctx, device_id, 0, &err); // Create the compute program from the source buffer prgm = clcreateprogramwithsource(ctx, 1, (const char **)&kernelsource, NULL, &err); clbuildprogram(prgm, 0, NULL, NULL, NULL, NULL); // Create the compute kernel in the program we wish to run knl = clcreatekernel(prgm, "vecadd", &err); // Create the input and output arrays in device memory d_a = clcreatebuffer(ctx, CL_MEM_READ_ONLY, bytes, NULL, NULL); d_b = clcreatebuffer(ctx, CL_MEM_READ_ONLY, bytes, NULL, NULL); d_c = clcreatebuffer(ctx, CL_MEM_WRITE_ONLY, bytes, NULL, NULL); // Write our data set into the input array in device memory err = clenqueuewritebuffer(q, d_a, CL_TRUE, 0, bytes, h_a, 0, NULL, NULL); err = clenqueuewritebuffer(q, d_b, CL_TRUE, 0, bytes, h_b, 0, NULL, NULL); // Set the arguments to our compute kernel err = clsetkernelarg(knl, 0, sizeof(cl_mem), &d_a); err = clsetkernelarg(knl, 1, sizeof(cl_mem), &d_b); err = clsetkernelarg(knl, 2, sizeof(cl_mem), &d_c); err = clsetkernelarg(knl, 3, sizeof(unsigned int), &n); // Execute the kernel over the entire range of the data set err = clenqueuendrangekernel(q, knl, 1, NULL, &globalsize, &localsize, 0, NULL, NULL); clfinish(q); // Read the results from the device clenqueuereadbuffer(q, d_c, CL_TRUE, 0, bytes, h_c, 0, NULL, NULL); 38/52
Chaîne de compilation FREIA OpenCL FREIA app.c compilateur source-à-source FREIA app'.c code de contrôle kernels OpenCL générés compilateur hôte compilateur accélérateur binaire de contrôle sur hôte binaires de calcul sur accélérateur 39/52
OpenCL sur le MPPA, multicœur et GPU : temps d exécution 10 2 Bostan i7 Quadro 600 Tesla C 2050 ns/#op/pixel 10 1 10 0 10 1 anr999 antibio burner deblocking licenseplate retina toggle GMEAN 40/52
OpenCL sur le MPPA, multicœur et GPU : énergie 10 3 Bostan i7 Quadro 600 Tesla C 2050 nj/#op/pixel 10 2 10 1 anr999 antibio burner deblocking licenseplate retina toggle GMEAN 41/52
Le modèle OpenCL OpenCL MPPA modèle répandu E/S gérées par le modèle support partiel d OpenCL évolutions de la pile logicielle performances à améliorer accès à la mémoire globale? à éviter actuellement sur MPPA pour ce type d applications 42/52
Quel modèle choisir?
Andey vs. Bostan : OpenMP sur 1 cluster 40 Speedups 30 20 10 Andey (OpenMP 1 thread) Andey (OpenMP 16 threads) Bostan (OpenMP 1 thread) Bostan (OpenMP 16 threads) 0 anr999 antibio burner deblocking licenseplate retina toggle GMEAN 43/52
OpenCL sur MPPA : Andey vs. Bostan 2 Andey (OpenCL) Bostan (OpenCL) Speedups 1.5 1 0.5 0 anr999 antibio burner deblocking licenseplate retina toggle GMEAN 44/52
Le meilleur modèle de programmation sur MPPA? 10 2 OpenMP (Bostan 1 cluster) OpenCL (Bostan) Sigma-C (Andey) Speedups 10 1 10 0 anr999 antibio burner deblocking licenseplate retina toggle GMEAN 45/52
Comparaison des modèles Modèle Avantages Inconvénients OpenMP Sigma-C OpenCL répandu 16 cœurs sur 256 portage rapide mémoire : 2 Mo (code, données) transferts depuis l hôte performant communications répandu portage rapide trop statique contrôle hôte nouveau langage abandonné implémentation en cours accès mémoire performances? OpenMP 256 cœurs tuilage + IPC performances? communications 46/52
Comparaison avec d autres accélérateurs nj/#op/pixel 10 3 10 2 10 1 Sigma-C (Andey) SPoC SMIL (i7) Quadro 600 Tesla C 2050 anr999 antibio burner deblocking licenseplate retina toggle GMEAN 47/52
Conclusions & Perspectives
Contributions principales Comparaisons expérimentales sur MPPA 3 modèles de programmation parallèle 2 générations de processeurs Preuve de la possibilité d atteindre les 3P développement d un environnement logiciel intégré regroupant plusieurs chaînes de compilation restreint au traitement d images publication CPC 2016 48/52
Les piles logicielles SMIL et FREIA SMIL app.py smiltofreia FREIA app.c Optimisations à la compilation SMIL Python Swig wrapper FREIA common runtime applications runtimes smilc SMIL lib Fulguro Sigma-C OpenCL SPoC Terapix matériels Processeurs multicœurs Processeurs manycore GPUs FPGAs 49/52
Environnement logiciel : freiacc 1 app 3P FREIA app.c SMIL app.py Programmabilité? Performance freiacc Portabilité SMIL Sigma-C OpenCL SPoC/Terapix Processeurs multicœurs MPPA GPUs FPGAs 50/52
Perspective : autre modèle pour le MPPA Objectif : utiliser tous les cœurs du MPPA OpenMP sur les clusters en C : réécriture des noyaux environnement d exécution : transferts, tuilage, recouvrements communications inter-clusters (à la MPI) optimisations via PIPS (fusion d opérateurs, etc.) Processeur hôte Cluster E/S Clusters de calcul Application Noyaux OpenMP Lectures Écritures Runtime Noyaux OpenMP Noyaux OpenMP 51/52
Perspective : DSLs et nouvelles architectures Le processeur MPPA potentiel embarqué vs. complexité architecturale ok! mémoire : taille SMEM, accès DDR Traitement d image portage d algorithmes non locaux segmentation Langages spécifiques à un domaine DSLs 3P : programmabilité, portabilité, performance normalisation, basés sur des langages généralistes 52/52
Compilation efficace d applications de traitement d images pour processeurs manycore Soutenance de thèse Pierre Guillou mercredi 30 novembre 2016 MINES ParisTech, PSL Research University
Bibliographie personnelle I Pierre Guillou. Compilation d applications de traitement d images sur architecture MPPA-Manycore. Conférence d informatique en Parallélisme, Architecture et Système (ComPAS 2014). Poster. Avr. 2014. url : https://hal-minesparistech.archives-ouvertes.fr/hal-01096993. Pierre Guillou. Compiling Image Processing Applications for Many-Core Accelerators. ACACES Summer School : Eleventh International Summer School on Advanced Computer Architecture and Compilation for High-Performance and Embedded Systems. Poster. Juil. 2015. url : https://hal-mines-paristech.archivesouvertes.fr/hal-01254412.
Bibliographie personnelle II Pierre Guillou. smilc : A C wrapper for SMIL. url : https://scm.cri.ensmp.fr/git/smilc.git. Pierre Guillou, Fabien Coelho et François Irigoin. «Languages and Compilers for Parallel Computing : 27th International Workshop, LCPC 2014, Hillsboro, OR, USA, September 15-17, 2014, Revised Selected Papers». In : sous la dir. de James Brodman et Peng Tu. Cham : Springer International Publishing, 2015. Chap. Automatic Streamization of Image Processing Applications, p. 224 238. isbn : 978-3-319-17473-0. doi : 10.1007/978-3-319-17473-0_15. url : http://dx.doi.org/10.1007/978-3-319-17473-0_15.
Bibliographie personnelle III Pierre Guillou et al. «A Dynamic to Static DSL Compiler for Image Processing Applications». In : 19th Workshop on Compilers for Parallel Computing. Valladolid, Spain, juil. 2016. url : https://hal-mines-paristech.archivesouvertes.fr/hal-01352808. Nelson Lossing, Pierre Guillou et François Irigoin. «Effects Dependence Graph : A Key Data Concept for C Source-to-Source Compilers». In : 2016 IEEE 13th International Working Conference on Source Code Analysis and Manipulation (SCAM) (oct. 2016). Benoît Pin, Pierre Guillou et Fabien Coelho. smiltofreia : A SMIL Python to FREIA C compiler. url : https://scm.cri.ensmp.fr/git/smilpyc.git.