Acceleratori hardware del calcolo ad alte prestazioni

Acceleratori hardware del calcolo ad
alte prestazioni

Comparazione della performance
di un algoritmo di ottimizzazione matematica
su piattaforme FPGA, GPGPU e x86_64

Antonio.Maria.Cristini@crs4.it
Collana di seminari per la valorizzazione dei Risultati della Ricerca del CRS4

Premessa

Perché hpc e architetture complesse?
Il calcolo deve rispondere ad esigenze sempre più ardue …
Un esempio:
• Un tipico dato di input della sismica a riflessione
Anni ’90
2D
100 MB

Oggi
3D 1km

Quasi un TB 3 km

6 ordini di grandezza in più! Top salt surface, color map is related to the depth


Premessa

Perché hpc e architetture complesse?
Un altro esempio:


Premessa

Di cosa NON parleremo
• Quale architettura è meglio delle altre in termini di
possibili prestazioni medie o di picco a seconda del campo
di applicazione oppure in termini di consumo a parità di
velocità di calcolo per operazioni più o meno complesse
• Di calcolo numerico e metodi più rapidi per trovare i
minimi o i massimi di una funzione pluridimensionale,
non lineare, non regolare ecc.
• Di linguaggi di programmazione che siano per la
programmazione strutturata o orientata agli oggetti
oppure linguaggi specifici quali
Cuda o OpenCL, VHDL o Verilog

Premessa

I due concetti che vorremmo sottolineare …
Rispettare la legge di Moore è sempre più difficile
• «Le prestazioni dei processori, e il numero di transistor ad esso relativo,
raddoppiano ogni 18 mesi».
• Ma il raggiungimento dei limiti fisici per la riduzione delle dimensioni dei
transistor è ormai raggiunto
Le esigenze di calcolo crescono
• la soluzione non può essere più computer o computer più grandi
• Si richiede troppo in termini di consumi e infrastrutture

La soluzione è tornare al semplice


Premessa


La soluzione è tornare al semplice


Premessa



Premessa


Computation

Computation

MaxelerOs


Premessa

• Spostare la gestione del dato dall’hardware al software
• Ad esempio:
• avvicinare il dato all’unità di calcolo
• decidere la sequenza delle operazioni
• L’infrastruttura è a carico del programmatore
• FPGA o le GPGPU sono coprocessori
• Necessitano di essere inseriti in una macchina completa
• Non possono sostituire le CPU
• Elevate prestazioni di picco con minori consumi e costi
La soluzione è farsi aiutare da
hardware semplice ma efficiente


Premessa

Non c’è un’infrastruttura per l’HPC migliore delle altre, ma è
necessaria una valutazione globale del problema:
• Costi dell’hardware, Consumi e spese di mantenimento
• Possibilità di portare il problema nell’architettura specifica
• Complessità del problema da affrontare e costi di sviluppo
• Quantità di dati da elaborare
• Precisione necessaria per risolvere il problema
• Velocità d’elaborazione
• Mantenimento dell’applicazione nel tempo
• Frequenza dei possibili crash del sistema nel suo complesso

Valutare il problema globalmente, hardware compreso

Premessa
tre
• Cercare di avere una visione globale dei problemi
• Non si può essere specializzati in tutto (ma in qualcosa si!)
• Sapere chi può affrontare e risolvere argomenti specifici
• Lavoro d’equipe (che non vuol dire nessuna responsabilità …)
• Facilità nell’inserire nuove persone, conoscenze
• Cercare le collaborazioni necessarie
• sapere cosa cercare e cosa offrire


Chi siamo

Imaging and Numerical Geophysics
• Gruppo di ricerca di 8 persone con differente back-ground
• 4 fisici: Ernesto Bonomi, Antonio Cristini, Guido Satta e Zeno Heilmann (geofisico)
• 4 ingegneri: Claudio Gallo, Giuliana Siddi, Daniela Theis, Gianluigi Caddeo
• 1 informatico: Omar Shiaratura
• Lavora nel campo della sismica a riflessione in collaborazione con
l’industria petrolifera da circa 17 anni
• Capacità di autofinanziamento di più del 120%
• Inserito nel settore: Energy and Environment diretto da
Ernesto Bonomi con diversi interscambi interni
• Diverse le collaborazioni ancora attive con:
• Importanti società di hardware e software
– Nvidia – AMD – Maxeler – …
• I più importanti dipartimenti universitari di geofisica
– Karlsruhe – Imperial College London – Università di Pisa


Acceleratori hardware del calcolo ad alte prestazioni

Sommario
Contesto: cos’è la sismica a riflessione
Common Reflection Surface Stack o CRS-stack
CRS: metodo Data-Driven
Parallelizzazione
L’applicazione CRS in tre diverse architetture
Una slide sui progetti futuri


Sismica a riflessione

Cosa è un giacimento di gas e petrolio
• Non è un lago di petrolio e gas.
• È una formazione porosa (rocce) che li racchiude;
• Una depressione della crosta terrestre che sprofondando
ha accumulato sedimenti e materiale organico
• La varietà è pressoché infinita:
• Strati piatti di roccia;
• Strati curvi verso il basso;
• Strati fratturati, dislocati e inclinati.



Alla ricerca del giacimento
• Finché non è trivellato un pozzo, è difficile confermare la presenza
di risorse utilizzabili …
• Il costo di una trivellazione è stimato a:
• 0,5-8 M$ per depositi “onshore”;
• 10-30 M$ per depositi in acque poco profonde;
• Oltre 100 M$ per depositi in acque profonde;
• Necessità di metodi per la previsione della presenza di giacimenti

• Tre fasi:
• Studio della superficie terrestre per costruire un primo modello di sottosuolo
• Sondaggio del sottosuolo, principalmente con metodi acustici
• Misure da pozzo


Che cosa è la sismica a riflessione …
• Il principale strumento di prospezione dell’industria
petrolifera;
• È utile anche in campo civile, ambientale e della ricerca
geologica di base;
• Usa molti concetti matematici sia originali sia mutuati da
altre branche della matematica applicata;
• L’elaborazione sismica richiede ingenti risorse di calcolo e
di archiviazione dati;
• È un’attività che vale oltre 4 miliardi di dollari all’anno.



La sismica o ecografia del sottosuolo
È il metodo di esplorazione che utilizza i principi della
sismologia per stimare le proprietà del sottosuolo a
partire da onde sonore indotte, in seguito riflesse.

Registrando il tempo di volo dell’eco e la sua intensità, è
possibile stimare la profondità della superficie riflettente;



I dati sismici
• Una traccia sismica è la registrazione degli
echi retro-propagati dalle discontinuità
del sottosuolo
• Le esplorazioni sismiche producono
enormi quantità di dati:
• Ciascuna esplorazione prevede 103 / 105 shots
• Ogni shot comporta circa 100-200 ricevitori
• Ciascun ricevitore registra circa 1500 campioni

Si sfiora facilmente un TB di dato a singola precisione



Processing dei dati sismici

• Correzione
dell’ampiezza
• Operazioni di
Filtraggio
• Deconvoluzione

• Analisi di velocità
• Stacking
• Migrazione


Common Reflection Surface Stack
2
 2 T  2t0 T
t 2
hyp =  t0 + w m  +
 v0  v (
m Hzy K N HT m + hTH zy K NIPHT h
zy zy )
m   0
S S=G G
0

-500 V0=1400 m/s

-1000

-1500

-2000 V1=2000 m/s
-2500

-3000

-3500

V2=3400 m/s
-4000

-4500

-5000
0 2000 4000 6000 8000 10000 12000


2
 2 T  2t0 T
t 2
hyp =  t0 + w m  +
 v0  v (
zy zy )
m   0
S S=G G
0

-500 V0=1400 m/s

-1000

-1500

-2000 V1=2000 m/s

• È un esperimento virtuale nel quale
-2500

-3000 sorgente e ricevitore coincidono (tracce zero-offset)
•
-3500 È una raccolta del segnale riflesso nello stesso punto
V =3400 m/s
(o in2un intorno molto vicino) del segnale zero-offset
-4000

•
-4500
Come realizzarla?
• Ipotizzando un modello di volo del segnale nel terreno
-5000
0 • Raccogliendo il segnale al tempo ipotizzato
2000 4000 6000 8000 10000 12000



La formula del TravelTime
2
 2 T  2t0 T
t 2
hyp =  t0 + w m  +
 v0  v (
zy zy )
  0
G −S G +S
h= ; m= − x0
2 2
Bortfeld R., (1989). Geometrical ray theory: Ray and
traveltimes in seismic systems (second-order
approximations of the traveltimes): Geophysics, 54, no.
3, 342–349.

Cervený V. (2001). Seismic ray theory. Cambridge University
Press.

Höcht, de Bazelaire E., Majer P., Hubral P. (1999). Seismics
and optics: hyperbolae and curvatures: J. of Applied
Geophysics no. 42, 261–281.

Höcht G., (2002). Traveltime approximations for 2D and 3D
media and kinematic wavefield attributes,
doctors’thesis. Universität Karlsruhe.


2
 2 T  2t0 T
t 2
hyp =  t0 + w m  +
 v0  v (
zy zy )
  0

• 2 parameters ( emergence angle & azimuth )
• 3 Normal Wavefront parameters ( RNx; RNy ; αN )
• 3 NIP Wavefront parameters ( RNIPx; RNIPy ; αNIP )

8 parametri attraverso I quali possiamo ricuperare i segnali
della traccia e ricostruire quello della traccia ZO



2
 2 T  2t0 T
t 2
hyp =  t0 + w m  +
 v0  v (
zy zy )
  0

Quali parametri utilizzare per identificare i tempi di volo?
Possiamo chiederlo ai dati …
Come?

8 parametri attraverso I quali possiamo ricuperare i segnali
della traccia e ricostruire quello della traccia ZO



Semblance
2
 2 T  2t0 T
thyp =  t0 + w m  +
2
 v0  v (
m Hzy K N HT m + hTHzyK NIPHT h
zy zy )
  0

N 2
2 M

∑ ∑a i,t i + k
r 1 k= − N i= 1
S ( x 0, t0 ) = N
2
M 2 M

∑ ∑a
2
i,t i + k
0≤S≤1 k= − N
2
i= 1

• Costituisce la funzione costo per una
procedura di ottimizzazione sugli 8 parametri



Piccola digressione …
Perché considerare tanti problemi distinti?
Potremo ad esempio riformulare il problema
• considerando il legame dei punti spazialmente vicini
• Risolvendo un sistema algebrico …

Ma
Parcellizzando riusciamo ad definire due livelli di parallelizzazione
1. Lungo gli assi spaziali
2. Lungo l’asse temporale

Formulare il problema considerando l’hardware sottostante



In un applicazione seriale
• Un ciclo esterno sulle tracce di output
I N P U T visto dall’alto OUTPUT

y
x
t

Forte sovrapposizione del dato di input



In un applicazione seriale
• Un ciclo esterno sulle tracce di output
• Per ogni traccia un ciclo sui campioni temporali
• Per ogni campione (t0): ottimizzazione sugli attributi

ottimizzazione

N 2
2 M

∑ ∑a i,t i + k
r 1 k= − N i= 1
S ( x 0, t0 ) = N
2
M 2 M

∑ ∑
2
a i,t i + k
k = − N 2 i= 1
Ciclo sui campioni

Ciclo sulle tracce

Parallelizzazione

L’applicazione parallela

ottimizzazione
ottimizzazione
ottimizzazione
N 2
2 M

∑ ∑a N
2 M
2
i,t i + k

S( x ,t ) = ∑ ∑
2
r 1 a N
2 kM − N 2 i= 1
=
i,t i + k
r 1∑ ∑a
M
0 0
k = − N N 2 i= 1 M
S( x ,t ) = 2 i,t i + k
∑ ∑a
2
0 0
r 1 M NN i= 1M
k = − 22
S( x ,t ) = i,t i2+ k
M
0
∑ ∑a
0 N
2 k= − N
M 2
i= 1
+
i,t i 2 k
Ciclo sui campioni ∑ ∑a k=− N
2
i= 1
i,t i + k
Ciclo sui campioni k= − N
2
i= 1
Ciclo sui campioni

• Tante istanze dello stesso codice seriale che elaborano
tracce differenti sono un’applicazione parallela
• Il calcolo procede in modo asincrono sul ciclo delle tracce

Parallelizzazione

Secondo livello di parallelizzazione

N 2
2 M

∑ ∑a N
2 Mi,t + k
2

∑ ottimizzazione
∑a
i
2
r 1 N
k = − N 2 i= 1 2
S( x ,t ) = Mi,t + k

∑ ∑a
i
0 0 2
r 1 N k= − N N
S( x ,t ) M
M 2 i= 1 2
= 2 2 i,t i + k
M
0
r0
S( x ,t ) M =
∑ ∑ a∑ ∑ a
1 N k= − N N
2 NM i,t i i=k 2
2 +
1 2
2 i,t i + k
M
2

∑ ∑ a∑
S( x ,t ) M ∑ ∑ a ∑
2 M
0 0
r k= − N1 i=N k = − M
1 Na i= 1
= 2 2 i,t i + k
2 i,t i + k

r S ( x , t 1) M∑ ∑ a
0 0 k= − N i,t i + k2
r 1 i=N k = − M
1 N i= 1
S( x ,t ) = = k 2 − N 2 i= 1 i,t i + k
= 2

M M∑ ∑
2
0 0 k = − N 2i=N
0 0 N 2 a 1
M 2
M i,t + k

∑ ∑ a∑ a
∑
2 i 2
2
k = − N 2 i= 1
ottimizzazione i,t i + k
i,t i + k

• Eliminando il ciclo sui campioni (t0) k= − N
2
=−
ki= 1 N 2 i= 1

• Creando una routine che calcoli contemporaneamente molte funzioni costo
Ciclo sui campioni
• La Multi-Semblance costituisce il nuovo kernel del calcolo
• L’ottimizzazione procede in modo sincrono sui t0
• È più facile renderla più efficiente rispetto a tante Semblance distinte
• È più facile realizzare un paradigma SIMD (Single Instruction, Multiple Data) a basso livello
• La logica dell’ottimizzazione sui parametri non viene toccata

Parallelizzazione

Multi-Semblance
• L’applicazione costituisce un’infrastruttura attorno al nucleo
TravelTime e Multi-Semblance
• Chiamato molteplici volte dall’ottimizzazione
• 95% del tempo di calcolo è usato dalle due routine
• Scrittura modulare: facile sostituzione con altre implementazioni
• Versioni attuali sono:
(SpeedUp rispetto a un singolo core Intel Westmere a 2.66 GHz)
Piattaforma Linguaggi Collaborazione SpeedUp

Core Intel Fortran e C (Maxeler) 2x

Maxeler FPGA Java (Maxeler compiler) e C++ Maxeler 110 x

AMD FireStream OpenCL AMD e committente 60 x

Nvidia Tesla/Fermi Cuda Nvidia e committente 100 x


Parallelizzazione

Multi-Semblance
• L’applicazione costituisce un’infrastruttura attorno al nucleo
TravelTime e Multi-Semblance
• Chiamate molteplici volte dall’ottimizzazione
• 95% del tempo di calcolo è usato dalle due routine
• Scrittura modulare: facile sostituzione con altre implementazioni
(

Cosa rende speciale calcolare tante
Semblance assieme rispetto a una per volta?


Parallelizzazione

Utilizzo dei dati nella Multi-Semblance
Utilizzo dei dati con 1 campione Utilizzo dei dati con 4 campioni

Utilizzo dei dati con 16 campioni Utilizzo dei dati con 64 campioni


CPU e Multi-Semblance

Sfruttamento della cache della CPU
• Non calcola una Semblance alla volta
• Calcolanum = ...i termini parziali relativi alla singola traccia
(1 )
assieme
−N
num = num −N
+a
( nsemb ) ( nsemb )
−N
i , t i( nsemb ) −
N
2 2 2 2
i=1
... ...

num (1 )
k
= ... num ( nsemb )
k
= num ( nsemb )
k
+ a i , t ( nsemb ) + k
i

... ...

denom (1 )
= ... denom ( nsemb )
= denom ( nsemb )
+ ∑a 2
i , t i( nsemb ) + k

N 2
2 M

∑ ∑a i,t i + k
r 1 k = − N 2 i= 1
S ( x 0, t0 ) = N
M 2 M

∑ ∑a
2
i,t i + k
Collana di seminari per la valorizzazione dei Risultati − N 2 Ricerca del CRS4
k = della i= 1

CPU e Multi-Semblance

Sfruttamento della cache della CPU
• Non calcola una Semblance alla volta
• Calcola assieme i termini parziali relativi alla singola traccia

• Una traccia occupa circa 12 KB e può risiedere per intero dentro la
cache di primo livello delle moderne CPU
• Ciò permette di aumentare il rapporto tra “Cache hit e Cache miss ”
fino a 100 volte
• Il meccanismo di caricamento del dato in cache è automatico

• Riduzione del tempo globale del calcolo del 50%:
• Da 3 a 1,5 mesi il tempo di elaborazione di un dataset con 1.000 core


Field Programmable Gate Array e Multi-Semblance

Meccanismo di calcolo nel FPGA
• Algoritmo del calcolo uguale a quello visto per la CPU
• Non c’è un meccanismo di cache nel FPGA
• C’è un flusso continuo delle tracce nel FPGA
• calcola e conserva in memoria quanto serve
• Per ogni FPGA si hanno fino a:
• 6 pipe ovvero 6 flussi continui del dato a 180 MHz
• Le pipe lavorano in modo SIMD
• Tuning specifico per il codice
• Utilizzo della rappresentazione in virgola fissa
• Si ha una maggior precisione solo dove richiesto



Meccanismo di calcolo nel FPGA
DRAM of PCI card PCIe
Parametri
Coord. delle tracce
FPGA

Riduzione del tempo globale e TraveTime Kernelnecessarie
Riduzione del tempo globale edelle risorse necessarie
delle risorse
Da 3 mesi a 6 giornitt da 1.000 core in 167 nodi a 128 FPGA su 32 nodi
,
Da 3 mesi a 6 giorni, da 1.000 core in 167 nodi a 128 FPGA su 32 nodi

Ris. parziali
Ris. parziali
Multi-Semblance Kernel



Un risultato con FPGA
CPU Coherency MAX2 Coherency


GPGPU e Multi-Semblance

Meccanismo di calcolo nella GPGPU
• Algoritmo di calcolo “naturale”
• Ogni Semblance è assegnata a un Thread
• Il calcolo della funzione costo procede in modo asincrono
• L’hardware gestisce la schedulazione dei thread ai core “liberi”
• Si realizza un modello SIMD sui parametri del TravelTime
• (L’ottimizzazione procede in modo sincrono)
• Il calcolo viene velocizzato dai numerosi core
• fino a 512 sulle schede Nvidia Fermi
• Importanti differenze tra le due implementazioni in test:
AMD FireStream OpenCL AMD e committente 60 x

Nvidia Tesla/Fermi Cuda Nvidia e committente 100 x



Confronto tra versione AMD e Nvidia
Versione AMD:
• Scritta in OpenCL
• C’è un tempo di latenza iniziale dovuto alla compilazione del kernel
• Il TravelTime è calcolato “al volo” all’interno della Semblance
• Coprire la lettura del dato con il tempo di calcolo
Versione Nvidia:
• Scritta in Cuda
• Linguaggio, fino ad oggi, un po’ più maturo per HPC
• TravelTime vengono calcolati preventivamente
• Uso della memoria Texture per le interpolazioni
• Interpolazioni hardware molto veloci, ma meno precise
• Dobbiamo ancora verificare se la precisione è sufficiente



Confronto tra versione AMD e Nvidia
Versione AMD:
• Scritta tempo globale e delle risorse necessarie
Riduzione delin OpenCL
Riduzione deltempo globale e delle risorse necessarie
Da 3 •mesiun47 giorni,latenza iniziale dovuto alla compilazione delFireStream
Da 3
C’è tempo di kernel
mesi a 47 giorni,da 1.000 core in 167 nodi a 32 schede FireStream
a da 1.000 core in 167 nodi a 32 schede
• Il TravelTime è calcolato “al volo” all’interno della Semblance
• Coprire la lettura del dato con il tempo di calcolo
Versione Nvidia:
• Scritta tempo
Riduzione delin Cuda globale e delle risorse necessarie
Riduzione deltempo globale e delle risorse necessarie
Da 3 •mesia 28 giorni,ad oggi, uncore in maturo pera32 schede Fermi
Da 3 mesi a 28 giorni,da 1.000 po’ più 167 nodi aHPC schede Fermi
Linguaggio, fino
da 1.000 core in 167 nodi 32
• TravelTime vengono calcolati preventivamente
• Uso della memoria Texture per le interpolazioni
• Interpolazioni hardware molto veloci, ma meno precise
• Dobbiamo ancora verificare se la precisione è sufficiente



Progetti futuri
• Continuare a seguire lo sviluppo dell’hardware

• Modifica dell’ottimizzazione
• Meno performace, ma con una convergenza uniforme per ogni t0

• Estendere il porting su FPGA e GPGPU
• Altri modelli data-driven con più parametri da cercare
• Altri progetti



Domande?


Acceleratori hardware del calcolo ad alte prestazioni

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Acceleratori hardware del calcolo ad alte prestazioni

Ähnlich wie Acceleratori hardware del calcolo ad alte prestazioni (20)

Mehr von CRS4 Research Center in Sardinia

Mehr von CRS4 Research Center in Sardinia (20)

Acceleratori hardware del calcolo ad alte prestazioni