Cadre, architectures et param`etres

r´esum´e. En bref, nous avons propos´e une approche de parall´elisation des noyaux adaptatifs d´edi´e aux architectures multicore et manycore. Elle concilie les contraintes relatives `a l’irr´egularit´e⁴⁹ des noyaux avec celles du hardware, et toutes ses briques internes sontlock-free. Elle s’appuie sur :

• uneextraction du parall´elisme amorphepour chaque noyau par le biais d’heuristiques degraphes.

Afin d’alimenter suffisamment les cores, nous ne consid´erons que les conflits relatifs `a la confor-mit´ede la topologie ce qui maximise le nombre de tˆaches extraites.

• uneapproche de restructuration des acc`es-m´emoire irr´eguliers qui att´enue la latence. Pour cela,

les noyaux sont structur´es en vagues afin de r´eduire la fr´equence des ´echanges de donn´ees.

les emplacements des mailles sont pr´ecalcul´es au moment de leur cr´eation afin d’´eviter les recopies de donn´ees locales et pour pr´eserver au mieux la proximit´e de mailles voisines.

les r´eductions de donn´ees se font de mani`ere asynchrone ounuma-aware selon le contexte.

• unesynchronisation `a grain finpour les mises `a jour du graphe d’incidence. Elle est peu coˆuteuse et minimise les transferts et copies de donn´ees compar´e `a l’´etat de l’art.

Maintenant le but est de montrer exp´erimentalement l’efficacit´e de l’approche et des features propos´ees.

Pour cela, elle a ´et´e impl´ement´ee enC++11et utiliseOpenMP4pour le multithreading. Elle fait l’objet d’une biblioth`eque baptis´ee trigen qui sera bientˆot disponible en open-source. En fait nous avons initialement impl´ement´e une versionplanairedetrigenavant de l’´etendre au cas surfacique. Notons que l’approche est parfaitement adapt´ee aux deux cas, mˆeme si le profil de performances peut sensiblement varier car les noyaux surfaciques ont une intensit´e arithm´etique un peu plus importante que leurs variantes planaires. `A ce titre, nous tenons `a pr´esenter les deux cas ici.

plan. Pour commencer, nous fixons le cadre de nos benchmarks en d´ecrivant les architectures et param`etres de tests. Ensuite nous ´evaluons l’efficience des briques que nous avons con¸cus pour l’extraction du parall´elisme amorphe pour les noyaux de simplification et de relaxation. En parti-culier, nous montrons l’´evolution du nombre de tˆaches extraites au fur et `a mesure des it´er´es ainsi que leurs surcoˆuts sur le temps de restitution des noyaux. De mˆeme, nous ´evaluons notre sch´ema de synchronisation `a grain fin pour la mise `a jour des donn´ees d’incidence, en nous comparant avec celui de rokos en termes de surcoˆut induit. Apr`es nous ´evaluons le scaling du remailleur et de chaque noyau sur des cas-tests planaires et surfaciques, et cela sur toutes les architectures. En particulier, nous montrons le surcoˆut induit par la parall´elisation, et la mani`ere dont il ´evolue quand le nombre

49de leurs aspectsdata-drivenetdata-intensiveplus pr´ecis´ement, voir section4.1.2

c2018.HOBYRAKOTOARIVELO

118 4.3. ´Evaluation num´erique

de cores utilis´es augmente exponentiellement. Pour finir, nous profilons le d´ebit de tˆaches trait´ees et la quantit´e de calcul utile pour chaque noyau.

Table 4.3: Caract´eristiques des machines de tests.

code puces NUMA cores GHz threads GB/core r´ef´erence compl`ete

HSW 2 4 32 2.5 64 4.0 Intel Xeon Haswell E5-2698 v3

SKL 2 2 48 2.7 96 7.9 Intel Xeon Skylake Platinum 8168

KNL 1 4 72 1.4 288 1.5 Intel Xeon-Phi Knights Landing 7250

architectures. Le profiling a ´et´e effectu´e sur deux machines multicore et une machine manycore, dont les caract´eristiques sont r´esum´ees `a la table4.3. Elles sont repr´esentatives des nœuds de calcul que l’on trouve sur les clusters r´ecents.

• multicore: on a deux machines dual-socket(HSW, SKL)bas´ees sur des processeurs Intel Xeon cadenc´es `a 2.5 Ghz (turbo-boost `a 3.4 Ghz) avec 3 niveaux de cache. HSW est une machine 32-core (avec16cores par puce) dont m´emoire est structur´ee enquatre nœudsNUMA reli´es en anneau, tandis queSKLest un noeud 48-core structur´e endeuxnœudsNUMA. Les deux machines disposent d’un cacheL3commun de33 Mo par nœudNUMA.

• manycore : on a une machine dual-memory (KNL) bas´ee sur un processeur Intel Xeon-Phi cadenc´e `a 1.4 Ghz. KNL a la particularit´e d’int´egrer une m´emoire on-chip MCDRAM avec une bande passante de320 Go/set une capacit´e fixe de16 Go, ainsi qu’une m´emoire classiqueDDR4`a 60 Go/s. Notons que laMCDRAMpeut ˆetre utilis´ee en tant que cache suppl´ementaire ou comme une m´emoire `a part enti`ere, en sp´ecifiant le mode utilis´e (cache/flat) au moment du boot. Afin d’optimiser l’utilisation des caches pour adapter au mieux avec les patterns d’acc`es-m´emoire, les cores peuvent ˆetre logiquement regroup´es en quadrant, en h´emisph`ere (deux groupes de cores) ou en 4 domainesNUMA(modesubnuma). Ce mode devrait ˆetre privil´egi´e afin de tirer profit du caract`ereNUMA-awaredes noyaux<sup>50</sup>. N´eanmoins, ne disposant pas de privil`eges administrateurs sur le nœud de calcul, nous n’avons pu utiliser que le couple de modes quadrant/flat, ce qui revient `a utiliser la machine en modeSymmetric Multiprocessing.

Shared L3 Cache

Figure 1: Block diagram of the Intel Nehalem.

lines in the Shared state remain silent, reducing coherency traffic. For further architectural details on the Nehalem, see, for example, the paper [29].

2.2 The Sun Niagara 2

The Sun UltraSPARC T2 platform, Niagara 2, has two 8-core sockets with each core supporting 8 hardware threads. Figure 2 shows a block diagram. Similar to the Nehalem, multithreading on the Niagara 2 is simultaneous. The system has a shallow instruction pipeline (in contrast to the XMT), and each core has two integer execution units, a load/store unit, and a floating-point unit. The pipeline is capable of issuing two instructions per cycle, either from the same thread or from di↵erent threads. Threads are divided into two groups of four, and one instruction from each group may be selected based on theleast-recently fetched policy on ready threads. The clock frequency of the processor is 1.165 GHz.

The total size of the memory system is 32 GB. Each core has an 8 KB, 4-way associative L1 cache for data and a 16 KB, 8-way associative I1 cache for instructions. Unlike Nehalem, where L2 cache is private, Niagara 2 has a shared, 16-way associative L2 cache of size 4 MB . The cache is arranged in 8 banks and is shared using a crossbar switch between CPUs. The latency is 129 cycles for local memory accesses and 193 cycles for remote memory accesses. The peak memory bandwidth is 50 GB/s for reads and 26 GB/s for writes. See [32] for additional details.

2.3 The Cray XMT

The Cray XMT platform used in this study is comprised of 128 Cray Threadstorm (MTA-2) processors interconnected via a 3D torus. Figure 3 shows a block diagram of the platform from a programmer’s point of view. Each processor has 128 hardware thread-streams and one instruction pipeline. Each thread-stream is equipped with 32 general purpose registers, 8 target registers, a status word, and a program counter.

Consequently, each processor can maintain up to 128 separate software threads. In every cycle, a processor context switches among threads with ready instructions in a fair manner choosing one of the threads to issue its next instruction. In other words, the multithreading variant on the XMT, in contrast to Nehalem and Niagara 2, isinterleaved. A processor stalls only if no thread has a ready instruction. There are three functional units, M, A, and C for executing the instructions. On every cycle, the M-unit can issue a read or write operation, the A-unit can execute a fused multiply-add, and the C-unit can execute either a control or an add operation. Instruction execution on the XMT is deeply pipelined, with a 21-stage pipeline. The

4

(1)hi´erarchie de caches surHSWetSKL

- un tile : deux cores et un cache-L2 partag´e.

- un quadrant de six tiles : un noeudNUMA.

DDR4

(2)clustering en quadrants surKNL

Figure 4.13: Architecture m´emoire de nos machines de tests.

50En effet laMCDRAMest r´epartie enquatresur la puce, et les cores sont regroup´es de sorte qu’ils soient physiquement plus proches de laMCDRAMint´egr´ee au nœudNUMA. Ici les adresses physiques sont mapp´ees auxtag directoryde sorte que les transferts m´emoire restent au maximum au sein du quadrant. Cela permet ainsi de r´eduire la latence en cas de d´efaut de cache tant que la donn´ee reste au sein du mˆeme nœudNUMA.

c2018.HOBYRAKOTOARIVELO

Afin de d´eterminer l’impact r´eel des d´efauts du dernier niveau de cache du processeur, nous avons profil´e le d´ebit et la latence m´emoire effective sur les deux architectures (HSWetKNL) `a la figure4.14.

• pour la bande-passante, nous utilisons le c´el`ebre benchmarkstream [165] disponible surhttp://

www.cs.virginia.edu/stream/dont les r´esultats sont illustr´es pour le noyautriad;

• pour la latence, nous utilisons le benchmarklmbench[175] disponible sur http://www.bitmover.

com/lmbench/dont les r´esultats sont donn´es pour les acc`es en lecture.

PourKNL, le d´ebit varie sensiblement selon qu’on utilise laMCDRAMou laDDR4(320 Go/set64 Go/s) mais la latence reste quasi-identique (30 nset28 ns). `A l’inverse, le d´ebit est identique pour l’acc`es `a une m´emoire locale ou distante pourHSW, mais la latence varie fortement selon que l’on acc`ede `a un bloc en cache (4.7et 6.4 nsen cache L2-L3), `a une m´emoire locale (18 ns) ou distante (40 nspour le noeud#4).

8 16 32 64 128 256

1 2 4 8 16 32 64

(GB/s)

cores Bandwidth [stream TRIAD]

HSW KNL: ddr4 KNL: mcdram

0 10 20 30 40 50

0 0 0 1 32 1024 32768

(ns)

array size in MB Latency

HSW : remote:1 HSW : remote:2 HSW : remote:3

HSW : local KNL : mcdram KNL : ddr4

Figure 4.14: D´ebit et latence m´emoire sur les deux architectures.

param`etres. Le code detrigena ´et´e compil´e avec le compilateur d’Intelicpcavec le flag d’optimisation -O3et qopt-prefetch=5 incluant l’auto-vectorisation et le prefetching logiciel. Afin de tirer profit des features sp´ecifiques au hardware, nous activons les flags -march=native lors de la compilation sur HSW-SKLetxmic-avx-512surKNL. Ici les threads sont explicitement punais´es sur les cores de mani`ere compacte `a raison d’un thread par core. Concr`etement, cela est r´ealis´e en positionnant la variable d’environnementKMP AFFINITY=compact, granularity=unitavecunit=core|fineen mode normal ou hy-perthreading. En fait c’est le mode par d´efaut que nous utilisons surKNLavec 4 htpar core comme recommand´e par Intel. Pour les instances de tests, nous avons consid´er´e les cas :

• ^2D. Nous utilisons trois champs de solution `a diff´erents degr´e d’anisotropies pour nos tests, tels qu’illustr´es `a la figure 4.16. Pour chaque cas, nous utilisons une grille triangul´ee de 504 100 points et1 005,362mailles. Pour chaque run, une seule adaptation est effectu´ee surtroisit´er´es, et le facteur de r´esolution est fix´e `a0.9⁵¹.

• surfacique. Nous consid´erons deux cas-tests : (1) une adaptation isotrope bas´ees sur les courburesd’une pi`ece m´ecanique (engine) avec1 826 000points et3 652 058mailles, ainsi qu’(2) une adaptation anisotrope bas´ee sur lahessienned’une solution num´erique (shock) avec1 014 890 points et2 029 772mailles et une r´esolution ciblen_max=250 000pour ce dernier cas. Pour chaque run, une seule adaptation est effectu´ee surquatreit´er´es.

Aucune gradation n’est effectu´ee. Enfin les points sont initialement r´eordonn´es afin d’obtenir un placement m´emoire initial optimal, mais aucune r´enum´erotation n’est effectu´ee en cours de calcul.

51Le nombre cible de pointsnmaxest donc `a90%de500Kpoints.

c2018.HOBYRAKOTOARIVELO

120 4.3. ´Evaluation num´erique

shock n=504 100

gauss n=504 100

waves n=504 100

Figure 4.15: Champs de solutions planaires utilis´es.

engine n=1 826 000

solut n=1 014 890

Figure 4.16: Cas-tests surfaciques utilis´es.