Hardware e Software per processi decisionali in

Hardware e Software per
processi decisionali in tempo
reale
S. Veneziano
Incontro Unicredit-INFN, 29 ottobre 2014
Selezioni in tempo reale
In molti campi, non solo nella fisica delle alte energie, è irrealistico
memorizzare tutti i possibili dati che provengono da un sensore, spesso
questo è indesiderabile.
È sempre necessario definire un processo di selezione che ottimizzi la
rilevanza del campione di dati memorizzato:
•
•
•
•
Selezioni in tempo reale sono necessarie quando la mole di dati è tale che
diventa impossibile farlo dopo la memorizzazione “permanente”.
Le presentazioni dei miei colleghi hanno illustrato come viene utilizzato il
campione di dati prodotti da questo processo di selezione in tempo reale.
2
Outline
Introduzione ai processi
•
decisionali usati nella fisica
sperimentale delle particelle
elementari
Qualche dettaglio sulle architetture
hardware e software usate per il
processamento in tempo reale.
•
•
Prenderò il caso specifico degli
esperimenti al Large Hadron
Collider. In questo caso per tempo
reale si intende:
•
•
•
Selezioni che devono avvenire ogni 25
nanosecondi;
Decisioni che devono essere prese
entro 2 micorsecondi, o entro 10
millisecondi, o entro qualche secondo.
Vedremo il perché di questa
gerarchia di tempi di decisione, cosa
abbiamo progettato e costruito.
3
Un esempio
Supponiamo di voler realizzare un sistema
per cercare l’immagine della Gioconda tra
tutte le foto scattate dai turisti del Louvre
ogni anno:
• 35000 soggetti
• 30000 visitatori al giorno, 100 foto a
visitatore
Algoritmo: riconoscimento di un volto su
foto di 1 Mbyte:
•
•
•
•
Il numero di sorgenti di dati è: 35000 sensori di fotocamere
(immagazzinati su Internet repositories).
Flusso di dati in ingresso al sistema di circa 3 TeraBytes al giorno.
Supponiamo di avere una capacità di storage di 3 TeraBytes. La
massima latenza del sistema dovrà essere: un giorno.
La decisione punta ad una selezione di un’immagine ogni 35000,
assumendo che I soggetti del Louvre abbiano tutti lo stesso interesse.
(Fattore di reiezione richiesto dall’algoritmo, 35000)
4
Il processo decisionale
•
Vogliamo definire l’algoritmo
di riconoscimento,
selezionare un’architettura
che raccolga tutte le
immagini, le processi e le
memorizzi su una banca dati,
basandosi su una stima delle
necessita’ (simulazione).
•
Analogamente al caso di LHC,
L’algoritmo di selezione
potrebbe passare per fasi
successive (livelli di selezione),
che restringono sempre di più il
numero di foto su cui fare infine
il riconoscimento del sorriso
della Gioconda.
In questo caso sembra
possibile realizzare questo
obiettivo utilizzando una
computer farm, disponibile sul
mercato.
•
5
LHC
•
Un esperimento all’LHC produce
l’immagine sovrapposta di 40
Gioconde ogni 25 nanosecondi.
•
•
•
•
•
L’immagine aspettata non e’ nota
esattamente. Input dalla teoria (quadro,
ritratto, donna, sorridente?)
L’immagine è frammentata su 10 milioni
di sensori, i cui dati devono essere
raccolti in tempo reale.
Flusso di dati di circa 60 PetaByte/s.
Con la tecnologia moderna e le
capacita’ della Grid, e’ possibile
memorizzare ragionevolmente 300 MB/
s, con una reiezione di 180,000,000.
E’ necessario sviluppare qualcosa
“ad-hoc”!
•
La reiezione che dovrà avere l’algoritmo
nell’analisi finale, per selezionare un
evento da decadimento di un Bosone
di Higgs sara’ complessivamente di
100,000,000,000. Per questo scopo è
stata realizzata la GRID.
6
Le sorgenti di dati
•
Ciascun evento è contenuto alla fine del
processo decisionale in circa 1 Mbyte di
informazione (ATLAS), di cui non parlerò
in seguito, ma:
•
•
E’ il risultato del processamento analogico/
digitale di segnali che provengono da circa
10 Milioni di canali di lettura.
I segnali da trovare in ciascun canale
possono essere di pochi fotoelettroni
(fotosensori) o di qualche migliaio di elettroni
(rivelatori a raccolta diretta di carica)
•
•
•
Segnali da trovare piccoli, dell’ordine del
Microvolt.
La catena di lettura, elettronica analogica e
digitale, di ciascun canale e’ complessa,
adattata a ciascun tipo di rivelatore ed alle
caratteristiche temporali della macchina.
È necessario convogliare su pochi nodi
l’informazione proveniente da questi 10
milioni di canali di lettura, registrando in
modo permanente solo quello che
soddisfa I nostri criteri di selezione.
•
Data Acquisition System.
7
Detector / Sensor
Amplifier
Filter
Shaper
Range compression
clock
Sampling
Digital filter
Zero suppression
Buffer
Memorizzazione
Feature extraction
temporanea
Buffer
Format & Readout
to Data Acquisition
System
Multilevel Trigger
•
Per poter raggiungere la reiezione richiesta in
tempo reale, il processamento avviene su vari
livelli.
•
Il primo livello prende la decisione su
un’immagine rozza. Se l’immagine passa il
primo livello, aumenta il livello di dettaglio
analizzato, fino al processamento dell’immagine
completa nell’ultimo livello di selezione.
•
Early rejection per ottimizzare le risorse.
8
L’architettura di ATLAS
Tre livelli di
selezione,
Dataflow
dedicato alla
concentrazione
dei dati.
L’immagine
completa viene
processata infine
da una farm di
processori
commerciali.
L’INFN è responsabile per la costruzione di sistemi di
trigger ed acquisizione dati in collaborazioni internazionali
9
Le soluzioni Hardware
•
•
Nel primo livello di selezione, è necessario l’uso di hardware dedicato:
•
latenza massima 2 microsecondi.
•
una decisione ogni 25 nanosecondi.
Pipelined Logic
La tecnologia di interconnessione tra le sorgenti dei dati e le unità di
Processing
Processing
Processing
calcolo è fondamentale.
data from
beam
crossing
La soluzione
adottatta è
chiamata
“Pipelined
Processings"
4
...
Combinatorial logic
Flip flop
10
data from
beam
crossing
3
data from
beam
crossing
2
Trigger
decision
for beam
crossing
1
ASICs
•
Application Specific
Integrated Circuit
Track trigger w/ pattern matching AM
ISOTDAQ2014, Budapest, 5-Feb-2014
Result:
Matched
Patterns
“Roads”
K. Kordas - Pattern Recognition w/ Associative Memories - FTK
L’INFN realizza circuiti
integrati dedicati al
processamento di dati.
Fonderie accessibili
tramite programmi
Europei (Europractice)
26
Riconoscimento di tracce nel rivelatore al
silicio di ATLAS
11
ATLAS FTK AMChip
Radar
Passive
Array
Programmable logic
WP435_01_070213
Figure 1: Next-Generation High-Performance Target Applications Examples
Hundreds of design enhancements went into the UltraScale architecture. These enhance
synergistically combine to enable design teams to create systems that have greater func
run faster, and deliver greater performance per Watt than ever before. See Figure 2.
X-Ref Target - Figure 2
Exam
•
Se gli algoritmi sono interamente digitali e non c’è
danno da radiazione, diventa possibile usare logiche
programmabili (Field Programmable Gate Arrays).
WP435 (v1.1) May 13, 2014
•
Questi dispositivi vengono usati nel livello di
decisione a più bassa latenza, sia come acceleratori
di processori standard.
•
L’INFN realizza firmware per questi dispositivi,
utilizzando metodologie che fanno uso di linguaggi
di sintesi e di simulazione di alto livello (VHDL,
Verilog, C++/SystemC).
12
WP435_02_070213
Figure 2: The Xilinx UltraScale Architecture
www.xilinx.com
Embedded systems
CAPITOLO 6. IL SISTEMA DI LETTURA PER I FOTODIODI
92
Sistema di
lettura per
fotodiodi e
fotomoltiplicatori
al silicio,
progetto MCS
•
Sono disponibili dispositivi che integrano logiche programmabili a processori (ARM, nel
Figura 6.10: Setup del sistema di test. Le entità in comunicazione sono due:
dei cellulari).
la 98%
ZedBoard
e la macchina vmcsdaq. E’ opportuno ricordare che l’ARM comunica con l’esterno esclusivamente attraverso il bus AMBA. Per una migliore
•comprensione,
Integrandoinlogiche
programmabili
a processori
che hanno
interfacce standard (Gbit
figura, viene
indicata con le
frecce tratteggiate
l’interazione
traEthernet
client e server
dei rispettivipossiamo
interlocutori.
nell’esempio),
sfruttare tutto il software disponibile per i sistemi
operativi più diffusi (Linux), e per sistemi operativi real-time. Il tempo di sviluppo si
riduce
notevolmente.
• si occupa
di caricare la configurazione inviata dal13DAQ e stabilisce quali
Il processo di selezione
•
•
Gli algoritmi software, che vengono
utilizzati in HEP per fare selezioni in
tempo reale di eventi interessanti,
valutano alcune grandezze fisiche “locali”
(carica, impulso, Energia depositata)
della singola particella e grandezze
“globali” (Energia mancante nell’evento,
presenza di neutrini) che hanno bisogno
dell’informazione dell’intera “Immagine”.
Su queste grandezze vengono applicati
dei tagli che selezioneranno o meno
l’evento (cut-based selections).
Esempio:l’elettrone
Il “Menu” di selezione conterrà diversi
tagli sull’insieme di parametri usati per la
selezione delle diverse “segnature”.
14
Efficienza vs Reiezione
ion
t
c
e
j
re
eff
ici
en
c
y
names represent nominal thresholds in GeV. At LVL1, EM refers to electrom
electrons and photons cannot be separated at this level because there is no i
available.
High-level-triggers
•
Le diverse “segnature” vengono
processate nei vari livelli di selezione
attraverso delle “catene” (Chains).
•
Nell’esempio, la segnatura di un
elettrone (TE, Trigger Element) procede
per passi.
•
In ciascun passo:
•
viene estratta la caratteristica (Fex,
Feature extraction),
•
viene valutata un’ipotesi (Hypo)
•
Software di “steering” e di
monitoring è stato scritto per
Each trigger hascontrollare
a generic name, withl’esecuzione
a corresponding LVL1 item,
LVL2 ch
di
tutte
These HLT chains are central to the design of the HLT Steering. A chain is co
steps. These are the steps
to confirm
or reject this particular trigger i
le needed
catene
dell’esperimento
Figure
2. Illustration of the main configuration concepts of the HLT Steerin
Se l’ipotesi è soddisfatta
la nuova
an example.
segnatura viene passata al prossimo
elemento della catena (TE’)
step represents one or
15 more algorithms, and is specified in terms of Trigger Elem
Implementazione dello steering
•
Singolo processo, un core per evento, memoria richiesta
per core grande:
•
•
Deep Memo-ization: caching del dato
Ottimizzazione delle richieste alle sorgenti di dati
Navigation chain-wise e step-wise. Pre-fetching se
step-wise. Ottimizzazione (cost-monitoring tools):
riduzione del tempo di decisione del 30%, risultato di
trigger da memorizzare ridotto del 70%
la memoria disponibile per core diminuisce.
•
FEX
Event Building integrato nel processo decisionale
•
•
TE
Memo-ization: caching dei risultati delle Feature
Extractions, riutilizzo su piu’ steps
•
•
TE
Verso il multiprocessings, utilizzo di acceleratori.
16
Hypo
Hypo
TE’
TE’
Navigation
GPUs
•
•
•
•
•
La GPU (macchina SIMD), inventata per
ottimizzare il rendering nei videogiochi, è ora
usata in molti campi. È una delle principali
architetture usate nei top 500 supercomputers.
La comunità HEP è interessata a sfruttare
questo potenziale delle GPU come
acceleratore del calcolo in tempo reale (il
riconoscimento di pattern è un algoritmo che
potrebbe beneficiare enormemente da questa
implementazione).
Le sfide in tempo reale sono la connettività con
le sorgenti di dati ed il controllo della latenza.
È necessario ripensare l’architettura software,
che da un algoritmo seriale che lavora con
strutture di dati complesse deve diventare
parallelo, operante su oggetti semplici.
L’INFN vuole dimostrare, attraverso progetti
pilota, che è ora possibile usare questa
architettura, disponibile sul mercato, per
applicazioni scientifiche in tempo reale, HEP e
medical imaging.
ALICE’s GPU tracking
ALICE’s GPU tracking
17
ALICE are fully committed to a GPU reconstruction f
commissioned in Run I! Achieves a threefold increas
ALICE GPUs
High-level triggers
•
Per ognuna delle
segnature selezionate nel
menu viene allocata una
banda passante, gli
eventi che verranno scritti
su supporto permanente.
•
I menu di selezione
evolvono nel tempo,
seguono le richieste
provenienti dalle analisi
offline.
18
Realtimeanalyses
multivariate analysis
multivariate
igger
MDDAG, Benbouzid, Kegl et al.
1
ponseL’approccio illustrato nelle trasparenze precedenti, “cut-based”, può
•
essere sostituito dalla analisi contemporanea di più variabili, creando un
albero di decisione che ottimizzi la latenza globale e le risorse di calcolo.
s LHCb
2010 data
(shaded better
grey), than so-called “cut-based”
iate
analyses
perform
heir
way
into
HLT algorithms,
LHCb’s
inclusive
b-physics
red)• and
all
minimum
bias Monte
Questo
approccio,
già usatoe.g.
in fase
di analisi
“off-line”,
si sta
ime
data
an N.b.,
area
the
private
sector
invests
a
e data
(seeanalysis
text for details).
cominciando
aisportare
nel where
dominio
delle
decisioni
in tempo
reale.
improvements
over coming years. 37
19
ing this plot. as a result of collaborations
Conclusioni
•
L’INFN tradizionalmente si occupa di progettare sistemi
decisionali in tempo reale (Trigger Systems).
•
I gruppi di ricerca che lavorano in fisica subnucleare
adottano soluzioni hardware e software dedicate, a
seconda delle necessita degli esperimenti, che
minimizzano il rapporto costi/prestazioni.
•
La modellizzazione e la simulazione sono parte integrante
di un progetto di sistema in tempo reale.
•
La collaborazione tra gruppi di ricerca, anche in campo
internazionale, e la formazione di esperti fa parte della
nostra metodologia di lavoro.
20