Multicœurs et Manycœurs - IME-USP
publicité
CRI’2013 Multicœurs et Manycœurs Une Analyse de la Performance et l’Efficacité Énergétique d’une Application Irrégulière Márcio Castro* — Emilio Francesquini* + — Thomas Messi Nguélé* - — Jean-François Méhaut* x * Nanosim - Laboratoire Informatique de Grenoble – Université de Grenoble, France Email: [email protected] + Institute of Mathematics and Statistics – Université de São Paulo, Brésil - LIRIMA-UMMISCO, Département d’Informatique, Université de Yaoundé 1, Cameroun x CEA/DRT/LETI, France RÉSUMÉ. Les études sur la performance et l’efficacité énergétique sont nombreuses dans le cas des multicœurs mais rares dans le cas des manycœurs. Contrairement à ces études, dans cet article, nous analysons un problème NP-complet irrégulier bien connu, le problème du voyageur de commerce. Nous étudions deux aspects de cette application sur un processeur multicœur et un processeur manycœur: d’abord l’adaptation du code à un manycœur (MPPA-256), puis l’analyse des performances de calcul et la consommation d’énergie. Nos résultats montrent que les applications capables d’utiliser pleinement les ressources d’un manycœur peuvent avoir de meilleures performances comparées à celles d’un processeur généraliste tout en consumant environ 10 fois moins d’énergie. ABSTRACT. Research on the performance and the energy efficiency of numerical kernels on multicores are common but studies in the context of manycores are scarce. Unlike these works, in this paper we analyze a well-known irregular NP-complete problem, the Travelling-Salesman Problem (TSP). We investigate two aspects of the application on multi and manycore processors. First we concentrate on the adaptation of the application to a manycore (the MPPA-256 processor) then we analyze its performance and energy consumption. Our results show that applications able to fully use the resources of a manycore can have better performance than a general purpose processor and at the same time consume 10 times less energy. MOTS-CLÉS : Processeurs Multicœurs, Processeurs Manycœurs, Performance de calcul, Efficacité Énergetique, TSP KEYWORDS : Multicore Processors, Manycore Processors, Performance, Energy Efficiency, TSP 1. Introduction La demande en processeurs de plus en plus performants pousse les fabricants de puces à combiner les approches telles que l’augmentation de la taille des caches, du parallélisme d’instructions et de la fréquence des processeurs. Cependant, ces approches semblent avoir atteint un point où elles ne suffisent plus pour maintenir la croissance de la performance prédite par la loi de Moore et attendue par les consommateurs [6]. Une augmentation exponentielle de la puissance consommée liée à une augmentation linéaire de la fréquence d’horloge [2] et une grande complexité de conception des nouveaux processeurs a changé le cours du développement de ces nouveaux processeurs. La puissance consommée est devenue un aspect essentiel pour le développement des systèmes à petite et grande échelle. Ceci peut justifier les études actuelles sur l’usage de processeurs de faible puissance dans la prochaine génération des systèmes HPC. Par exemple, le projet européen Mont-Blanc a été créé pour évaluer l’usage de ces types de composants dans un environnement HPC [8]. Bien que n’offrant pas les mêmes performances de calcul que leurs homologues généralistes, ces multicœurs de faible puissance offrent généralement de meilleurs résultats quand on compare l’énergie dépensée pour trouver une solution (energy-to-solution). Les processeurs parallèles actuels vont même encore plus loin, avec des centaines voire des milliers de cœurs, tout en ayant une consommation efficace d’énergie. Certains de ces manycœurs comme Tilera Tile-Gx [12] et Kalray MPPA-256 [3] ont des cœurs autonomes qui supportent le modèle d’exécution threads POSIX (PThreads) et pouvant ainsi faire la parallélisation des données et des tâches. Ceci peut faciliter le passage d’une application parallèle des multicœurs aux manycœurs, car plusieurs applications parallèles développées pour les multicœurs s’appuient sur ce modèle. Par contre, les GPUs (General Processing Units) suivent une autre approche basée sur le modèle SIMD (Single Instruction, Multiple Data) qui s’appuie sur des APIs comme CUDA et OpenCL. Un effort considérable peut donc être nécessaire pour adapter le code parallèle développé d’un multicœur vers un GPU. Les recherches sur l’efficacité énergétique et les performances de calcul des processeurs généralistes et des processeurs de faible puissance sont assez fréquentes [9, 11]. Cependant, dans le cadre de ces travaux, nous nous intéressons à l’analyse du passage des multicœurs aux manycœurs en utilisant un problème irrégulier et NP-complet bien connu : le problème du voyageur de commerce. Avec une instance assez grande (20 villes), sa solution peut être parallélisée et faire usage d’un nombre arbitraire de threads assurant l’utilisation complète des plates-formes choisies. Bien que ce problème soit très parallélisable, il soulève des questions importantes liées au déséquilibre de charge et à l’irrégularité. Le reste de cet article est organisé comme suit. La Section 2 décrit les plates-formes évaluées. Une description de haut niveau du problème choisi ainsi que ses algorithmes sont présentés dans la Section 3. Ensuite, la Section 4 aborde les défis rencontrés lors du passage des multicœurs au manycœur MPPA-256. La Section 5 présente les évaluations de perfomance de calcul et d’efficacité énergétique. Enfin, nous discutons des travaux connexes dans la Section 6 et concluons dans la Section 7. 2. Plates-formes Dans cette étude nous avons utilisé deux plate-formes. La première est composée d’un processeur multicœur généraliste et la deuxième est composée d’une puce manycœur à basse consommation. Nous les présentons ci-dessous. Xeon E5. Le processeur Intel Xeon E5 est un processeur x86-64 64-bit. Dans cette étude, nous avons utilisé une puce Xeon E5-4640 Sandy Bridge-EP, qui dispose de 8 cœurs (16 threads avec l’Hyper-Threading activé) cadencée à 2.40GHz. Chaque cœur dispose de deux caches L1 (un d’intructions de 32Ko et autre de données de 32 Ko) et d’un cache L2 de 256Ko. Tous les 8 cœurs partagent un cache L3 de 20 Mo et la plateforme a 32 Go de mémoire DDR3. MPPA-256. Le MPPA-256 [1, 3] est un processeur manycœur développé par Kalray qui intègre 256 cœurs utilisateurs et 32 cœurs système dans une technologie CMOS de 28nm. Ces cœurs sont répartis sur 16 clusters de calcul et 4 sous-systèmes d’E/S (cluster d’E/S) qui communiquent à travers deux NoCs (Networks-on-Chip) de données et de controle. ������������� �� �� �� �� �� �� �� �� �� �� �� ������������� �� �� �� ������������� ����� �������������� ����� �� ��� ��� ��� ��� ��� ��� ���� ���� ������������� �� �� �������������� ��� ��� ��� ��� ���� ���� ���� ���� ��������������� ������������� �������� Figure 1. Une vue simplifiée de l’architecture du MPPA-256. La Figure 1 montre l’architecture générale du MPPA-256. Il possède deux types de cœurs : PE (Processing Elements) et RM (Resource Managers). Les PEs et les RMs sont regroupés au sein des clusters de calcul et les clusters d’E/S. Chaque cluster de calcul comporte 16 PEs, 1 RM et une mémoire locale partagée de 2 Mo. Les applications parallèles s’exécutant sur MPPA-256 suivent habituellement le modèle maître/esclaves. Le processus maître fonctionne sur un RM du cluster d’E/S et il est responsable de la création des processus esclaves. Ces processus sont ensuite exécutés sur des clusters de calcul et chaque processus peut créer jusqu’à 16 threads POSIX, un pour chaque PE. 3. Étude de Cas : Le Problème du Voyageur de Commerce Le problème du voyageur de commerce (Traveling-Salesman Problem, TSP), consiste à trouver l’itinéraire d’un voyageur de commerce qui doit se déplacer dans n villes. Un tel itinéraire doit être le plus court possible, passant une seule fois dans chaque ville et se terminer par la ville d’origine. C’est un problème NP-complet très bien étudié. Le TSP pourrait être modélisé avec un graphe non orienté complet G = (V, E),|V | = n où chaque arête (i, j) ∈ E a un coût c(i, j) ≥ 0 représentant la distance entre les villes i et j. Le but est de trouver un cycle hamiltonien avec un coût minimal. Il existe plusieurs approches de la résolution de ce problème [5]. Ici, nous utilisons un algorithme de force brute exact, basé sur une heuristique très simple. Algorithme séquentiel. La version séquentielle de l’algorithme est basée sur la méthode de séparation et d’évaluation (branch and bound). Cet algorithme prend en entrée le nombre de villes, et une matrice de coût, et retourne la longueur du chemin minimal (min_path). Il a une complexité de O(n!) dans le pire des cas. Il n’explore pas les chemins plus long que le meilleur chemin déjà rencontré, il écarte donc les branches inutiles. Cette technique d’élagage améliore considérablement les performances de l’algorithme mais introduit également des irrégularités dans l’espace de recherche. La profondeur de la recherche nécessaire pour parcourir une des branches dépend de l’ordre dans lequel les branches ont été fouillées. Algorithme multi-threadé. Ici, on a créé une file d’attente de tâches (branches de recherche) à partir de laquelle chaque thread prend les tâches à exécuter. La génération des tâches se fait de manière séquentielle car le temps nécessaire pour le faire est négligeable. Dès qu’un thread se retrouve sans tâche, il prend une nouvelle tâche dans la file d’attente. Le nombre de tâches qui doivent être générées change en fonction du nombre de threads et est défini par le paramètre max_hops (le nombre minimum de niveaux de l’arbre de recherche). Le nombre total t(l, n) de tâches en fonction des niveaux l et des n villes peut être déterminé par la relation de récurrence suivante : ∀l ∈ [0, n[, t(l, n) = 1 si l = 0 et t(l, n) = t(l − 1, n) ∗ (n − l) sinon. Algorithme distribué. Cet algorithme reçoit comme paramètre supplémentaire le nombre de postes n_postes à utiliser. Pour chaque poste, n_threads threads sont créés, donc on a un total de n_threads ∗ n_postes threads. Dans chaque poste, l’exécution est similaire à celle du cas multi-threadé. La seule différence est que, lorsque le min_path est mise à jour dans un poste, cette mise à jour est diffusée à tous les autres postes afin qu’ils puissent aussi l’utiliser pour optimiser leur exécution. À la fin de l’exécution, un des postes imprime la solution. Chaque poste poste_id ne travaille que sur les tâches qui lui ont été assignées. Pour ce faire, nous définissons le nombre de tâches (regroupées en partitions) par poste. Lorsque les postes sont à court de tâches, ils demandent d’autres partitions au poste maître. Pour réduire le nombre de communications, le poste maître envoie des partitions de taille décroissante à chaque demande [7]. En effet, comme les tailles des tâches sont irrégulières, la distribution d’un nombre de plus en plus petit de partitions vers la fin de l’exécution pourrait réduire le déséquilibre de charge entre les postes. Dans ce cas, pour chaque demande, le poste maître envoie un ensemble de partitions S et le poste poste_id travaille sur des tâches telles que task_index mod n_partitions ∈ S. Comme la génération des tâches se fait au niveau local, la quantité de données transférées peut être minimisée. 4. Adaptation du TSP à une Plate-forme Manycœur Nous avons présenté dans la section 3 un aperçu des algorithmes de résolution du TSP. Toutefois, les différences architecturales entre les plates-formes multicœur et manycœur nous obligent à faire des adaptations du code. Dans cette section, nous discutons des adaptations effectuées avec le cas particulier du manycœur MPPA-256. La bibliothèque Pthreads est installée sur les deux plates-formes testées. Dans la version multi-threadé du code, min_path est implémenté en utilisant une variable partagée qui est accessible par tous les threads. Les opérations d’écriture sur cette variable (c.a.d. quand un thread trouve un chemin plus court) sont protégées par un verrou pour éviter les situations de compétition. Contrairement aux opérations d’écriture sur cette variable, les opérations de lecture ne sont pas protégées pour que le parallélisme ne soit pas limité. Malheureusement, cette solution n’est pas appropriée à la plate-forme MPPA-256, car les PEs ne possèdent pas des mémoires caches cohérentes. La prise de verrou par le PE qui réalise la mise à jour de min_path a comme effet secondaire l’invalidation de sa mémoire cache. Toutefois, les lignes de cache des autres PEs du même cluster qui stockent cette variable ne sont pas invalidées. Ainsi, les threads s’exécutant sur les autres PEs utilisent l’ancienne valeur stockée dans min_path pendant une longue période de temps et perdent du temps sur des branches stériles de l’arbre de recherche. Pour corriger cela, nous avons utilisé des instructions spécifiques de la plate-forme (__builtin_k1_lwu et __builtin_k1_swu) qui permettent un accès direct à la mémoire locale du cluster, contournant ainsi la mémoire cache. Ce mode de lecture coûte nettement plus cher que d’utiliser la valeur stockée dans les caches (l’accès à la mémoire locale coûte 8 cycles alors que l’accès à la mémoire cache coûte 2 cycles). Toutefois, l’amélioration des performances due à un bon élagage de l’arbre de recherche l’emporte largement sur ce coût supplémentaire. Du fait de la non existence d’une mémoire globale partagée entre clusters de calcul, nous avons utilisé la version distribuée du TSP. Les échanges de messages asynchrones entre clusters prennent la forme d’opérations d’écriture sur une mémoire distante. En raison du temps nécessaire pour diffuser une nouvelle valeur de min_path, certains threads peuvent utiliser une valeur erronée pour un laps de temps jusqu’à ce que l’émission soit terminée. 5. Résultats Expérimentaux Dans cette section, nous présentons l’évaluation des performances de calcul et de l’efficacité énergétique des plates-formes lors de l’exécution des versions parallèles et distribuées du TSP. Nous commençons par présenter notre méthodologie de mesure ainsi que les métriques utilisées pour analyser les résultats (Section 5.1). Ensuite, nous comparons les performances énergétiques et de calcul des processeurs (Section 5.2). 5.1. Méthodologie de Mesure Nous utilisons deux indicateurs pour comparer les performances énergétiques et de calcul des deux processeurs : time-to-solution et energy-to-solution. La métrique timeto-solution désigne le temps passé pour trouver une solution à un problème donné. Dans notre cas, il s’agit du temps global d’exécution du TSP parallèle/distribuée. La métrique energy-to-solution est la quantité d’énergie dépensée pour parvenir à résoudre un problème. Elle peut être calculée en multipliant la puissance moyenne (en watts) consommée lors de l’exécution de l’application par la métrique time-to-solution. La puissance consommée par chaque processeur a été obtenue en utilisant deux approches bien similaires. Le Xeon E5 a une microarchitecture Intel Sandy Bridge, qui a des capteurs d’énergie RAPL (Running Average Power Limit). Cela nous permet de mesurer la consommation d’énergie au niveau des composants du processeur à travers des registres spécifiques de la machine (en anglais Machine-Specific Registers, MSRs). Nous avons utilisé cette approche pour obtenir la consommation d’énergie de l’ensemble du package CPU, c.a.d., l’ensemble des cœurs et la mémoire cache. La puissance moyenne consommée par le Xeon E5 a été de 68,6W. Les mesures de puissance à l’aide de cette approche sont très précises, comme indiqué dans [10, 4]. De même, le MPPA-256 comporte des capteurs pour mesurer la puissance électrique consommée de la puce entière, c.a.d., 16 clusters de calcul ainsi que les 4 sous-systèmes de clusters d’E/S. La puissance moyenne consommée par le MPPA-256 a été de 10.7W En ce qui concerne la pile logicielle, nous avons compilé le TSP avec le même compilateur (GCC 4.7) sur les deux plates-formes. Cependant, MPPA-256 propose une version modifiée de GCC pour construire les binaires pour sa plate-forme spécifique. En outre, les systèmes d’exploitation installés sur les deux plates-formes sont différents : le système Linux v.30 est installé sur la plate-forme Xeon E5 alors que MPPA-256 gère deux systèmes d’exploitation différents. Le RTEMS (Real Time Executive for Multiprocessor System) 1 fonctionne sur les clusters d’E/S, et le NodeOS (un système d’exploitation propriétaire développé par Kalray) fonctionne sur le RM de chaque cluster de calcul. Nous avons également défini deux tailles de problème pour le TSP : un petit (16 villes) et un grand (20 villes). Nous avons utilisé une petite taille de problème lors de l’exécution du TSP avec un nombre de threads réduit pour obtenir les résultats dans un délai raisonnable. Dans toutes les expériences, nous avons utilisé la même instance du problème afin de garantir le même chemin d’exécution entre les différentes plates-formes. Chaque expérience a été répétée au moins 20 fois pour garantir un niveau de confiance de 95%. 5.2. Résultats Les performances énergétiques des processeurs Xeon E5 et MPPA-256 peuvent varier considérablement selon le nombre de threads utilisés (Figure 2a). Nous avons mesuré la métrique energy-to-solution entre le processeur Xeon E5 et un cluster du MPPA-256, en faisant varier le nombre de threads de 1 à 16 avec une petite taille de problème (16 villes). Bien que le processeur Xeon E5 ait seulement 8 cœurs physiques, il dispose de la technologie Hyper-Threading (HT), qui double le nombre de cœurs logiques, permettant l’exécution de 16 threads simultanément. ���������� ������ ��� ������� �� ������� �� ������������������������ ���� �������� ��� ���� ���� ���� ���� ���� ������������������������ ��������� ���� ������ ��� ������ ��� ������ ��� ������ ��� ����� ��� ����� ���� �� ���� ���� �� �� �� �� �� �� �� �� �� ��� ��� ��� ��� ��� ��� ��� ������������������ ����������������� ��� ����� ����� ��� �� ��������������������� ��� � ��� �� �� �� ����� �� �� ������� �������� �������������� ��������������� ��������� �������� ������������ ����������� ��� Figure 2. Performances et efficacité énergétique des processeurs Xeon E5 et MPPA-256. Nous avons remarqué que Xeon E5 surpasse un cluster MPPA-256 sur un faible nombre de threads (il a consommé 90% et 11% moins d’énergie avec un et deux cœurs, respectivement). Pour plus de 8 threads, cependant, un cluster MPPA-256 surpasse le Xeon E5, consommant jusqu’à 40% moins d’énergie avec 16 threads. Cela est dû au fait que 1. RTEMS est disponible sur http://www.rtems.org la puissance consommée par le Xeon E5 augmente considérablement avec le nombre de cœurs utilisés (de 27W à 68,6W) alors que la puissance consommée par un seul cluster MPPA-256 est resté pratiquement inchangée (de 4,1W à 4,6W). Cela signifie que les applications parallèles s’exécutant sur MPPA-256 doivent exploiter la totalité des cœurs afin de parvenir à une meilleure performance énergétique. La Figure 2b compare à la fois les métriques time-to-solution (axe de droite) et energyto-solution (axe de gauche) sur les deux processeurs. Dans ces expériences, nous avons exécuté le TSP avec une grande taille de problème et nous avons utilisé tous les cœurs de chaque processeur. Étonnamment, le TSP s’exécute 1,6x plus vite sur MPPA-256. Même si la fréquence d’horloge des PEs de MPPA-256 est bien inférieure à celle des cœurs Xeon E5, ce processeur embarqué réalise une meilleure performance. Cela est dû à la caractéristique inhérente de notre mise en oeuvre de TSP. Comme nous l’avons déjà dit à la Section 3, il y a peu d’échanges de messages entre les postes dans l’algorithme distribué. La diffusion entre les clusters a été implémentée en utilisant les messages asynchrones à travers le NoC, ce qui se traduit par une absence de contention. On a pu constater aussi que le processeur MPPA-256 consomme moins d’énergie que Xeon E5 pour résoudre le même problème. Dans nos expériences, le processeur MPPA-256 a montré la meilleur energy-to-solution, réduisant la consommation d’énergie de Xeon E5 d’environ 90%. 6. Travaux connexes E. Totoni et al. [13] comparent la puissance et la performance du processeur SCC (Single-Chip Cloud Computer) d’Intel aux autres types de CPUs et GPUs. E. Padoin et al [9] comparent le processeur dual-core ARM Cortex-A9 1.0GHz de Texas Instruments à deux multiprocesseurs : un composé de deux processeurs quad-core 2,4 GHz Intel Xeon E5 et l’autre composé de quatre processeurs Xeon X7 de 8 cœurs 2,0 GHz. En utilisant une approche légèrement différente, Aubry et al. [1] ont comparé la performance d’un processeur Intel Corei7-3820 avec le MPPA-256. Leurs résultats montrent que les performances de ce processeur traditionnel va de pair avec la performance du MPPA-256 tout en fournissant un meilleur rendement énergétique de 6,4x. Contrairement aux travaux précédents, nous avons mis l’accent sur le passage des multicœurs aux manycœurs avec un un problème irrégulier (TSP). Nous avons souligné quelques questions de programmation qui doivent être prises en compte lors du développement d’applications parallèles sur les manycœurs. 7. Conclusion et perspectives Les processeurs manycœurs comme le MPPA-256 semblent être la tendance dans le développement des processeurs plus rapides et énergétiquement efficaces. Étant composé de plusieurs cœurs de performances limitées, l’utilisation efficace d’un processeur embarqué manycœur exige des adaptations du code de l’application afin que ce code puisse utiliser efficacement l’ensemble de la puce. Ces modifications ne sont pas triviales. Avec le MPPA-256, ceci est par exemple dû à l’absence d’un espace mémoire adressable globalement et à l’absence des mémoires cache cohérentes. Pour une application assez parallelisable comme le TSP, nous avons montré que le MPPA-256 peut être très compétitif, même si cette application est irrégulière. Nos résultats montrent que ce processeur manycœur a une très bonne performance comparée à un processeur multicœeur généraliste très utilisé (Intel Xeon E5) tout en offrant un meilleur rendement énergétique (∼10x). En perspective, nous comptons évaluer les performances de ce processeur avec une application ayant beaucoup de communications et beaucoup de zone séquentielles dans le code. Nous planifions aussi de comparer les performances de MPPA-256 avec d’autres processeurs embarqués et optimisés pour l’efficacité énergétique. Enfin, nous envisageons une comparation des performances de calcul et de la consommation énergetique de ces processeurs avec des outils de plus haut niveau tels que MPI et OpenCL. 8. Bibliographie [1] Pascal Aubry, Pierre-Edouard Beaucamps, and F. Blanc et. al. Extended Cyclostatic Dataflow Program Compilation and Execution for an Integrated Manycore Processor. In International Conference on Computational Science (ICCS), volume 18, pages 1624–1633, Barcelona, Spain, 2013. Elsevier. [2] D.M. Brooks, P. Bose, and S.E. Schuster et. al. Power-Aware Microarchitecture : Design and Modeling Challenges for Next-Generation Microprocessors. IEEE Micro, 20(6) :26–44, 2000. [3] Benoît Dupont de Dinechin, Pierre Guironnet de Massasa, and G. Lagera et. al. A Distributed Run-Time Environment for the Kalray MPPA-256 Integrated Manycore Processor. In Intl. Conference on Computational Science (ICCS), volume 18, pages 1654–1663, Barcelona, Spain, 2013. Elsevier. [4] Marcus Hähnel, Björn Döbel, Marcus Völp, and Hermann Härtig. Measuring Energy Consumption for Short Code Paths Using RAPL. ACM Sigmetrics Performance Evaluation Review, 40(3) :13–17, 2012. [5] Gilbert Laporte. The Traveling Salesman Problem : An Overview of Exact and Approximate Algorithms. European Journal of Operational Research, 59(2) :231–247, June 1992. [6] James Larus. Spending Moore’s Dividend. Communications of the ACM, 52 :62–69, 2009. [7] Li, Hui et. al. Locality and Loop Scheduling on NUMA Multiprocessors. In International Conference on Parallel Processing (ICPP), volume 2, pages 140–147, Syracuse, USA, 1993. IEEE Computer Society. [8] N. Rajovic et. al. The Low-Power Architecture Approach Towards Exascale Computing. In Workshop on Scalable Algorithms for Large-Scale Systems (ScalA), pages 1–2, New York, USA, 2011. ACM. [9] Edson Luiz Padoin, Daniel Alfonso G. de Oliveira, Pedro Velho, and Philippe Navaux. Timeto-Solution and Energy-to-Solution : A Comparison between ARM and Xeon. In Workshop on Applications for Multi-Core Architectures (WAMCA), pages 48–53, New York, USA, 2012. IEEE Computer Society. [10] Efraim Rotem, Alon Naveh, Avinash Ananthakrishnan, and E. Weissmann et al. PowerManagement Architecture of the Intel Microarchitecture Code-Named Sandy Bridge. IEEE Micro, 32(2) :20–27, 2012. [11] Luka Stanisic, Brice Videau, Johan Cronsioe, and A. Degomme et al. Performance Analysis of HPC Applications on Low-Power Embedded Platforms. In Design, Automation & Test in Europe (DATE), pages 475–480, Grenoble, France, 2013. IEEE Computer Society. [12] Tilera Corporation. TILE-Gx Processor Family, June 2013. [13] Ehsan Totoni and B. Behzad et. al. Comparing the Power and Performance of Intel’s SCC to State-of-the-Art CPUs and GPUs. In IEEE Intl. Symposium on Performance Analysis of Systems and Software (ISPASS), pages 78–87, New Brunswick, Canada, 2012. IEEE Computer Society.
