A query-to-hardware compiler for FPGA architectures
1. Implementazione di linguaggi 2
A Query-to-Hardware Compiler
for FPGA architectures
Bruno Filippo Mazzarello Enrico Cambiaso
bruno.mazzarello@gmail.com enrico.cambiaso@gmail.com
2. Abstract
Sfruttare i vantaggi di tecnologie multi-core per attività di
elaborazione dati è un problema molto importante.
Considerare l'utilizzo degli FPGA come architetture multi-
core per l'elaborazione di stream di dati puo' rivelarsi una scelta
vincente; verranno illustrate le possibili integrazioni di questa
tipologia di dispositivi hardware con un database system.
In seguito verrà presentato Glacier, uno strumento utilizzato
per tradurre una query in un circuito logico; verranno
considerati i soli operatori più comuni e ne verrà discusso il
design come elementi modulari.
Verranno inoltre mostrati i miglioramenti di performance
ottenuti inserendo un FPGA all'interno del percorso dei dati.
3. Il futuro dei processori
Un esempio di possibile calcolatore del futuro è il Cell
Broadband Engine, frutto di una ricerca di IBM, che fornisce
otto Synergistic Processing Units (SPUs) prossime ad una
CPU di tipo general-purpose.
In modo simile, i produttori hardware hanno già annunciato che
il processore del futuro in un elaboratore multi-core non
conterrà CPU identiche: alcune avranno unità floating point,
altre forniranno un vasto insieme di instruzioni, altre ancora
avranno differenti caratteristiche.
4. Il progetto Avalanche
Si tratta di un progetto dell'ETH Zurich.
In Avalanche viene studiato l'impatto di architetture moderne su
operazioni di elaborazione dei dati.
Nel progetto è stato valutato il potenziale delle tecnologie FPGA
se utilizzate come processori aggiuntivi su elaboratori multi-core
e l'importanza dei risultati raggiunti in attività di data processing.
5. Field-Programmable Gate Arrays
Gli FPGA sono una tecnologia molto promettente che si
rivela interessante se applicata al campo dei database.
Due principali aziende produttrici di FPGA:
Xilinx http://www.xilinx.com
Altera http://www.altera.com
6. FPGAs for stream processing
In ogni FPGA vi è un gran numero di LookUp Tables (LUTs),
che forniscono una tipologia programmabile di porte logiche.
Ogni lookup table puo' implementare una funzione 6 bit → 1 bit.
7. FPGAs for stream processing
Le lookup tables sono collegate attraverso una interconnect
network in grado di indirizzare i segnali attraverso il chip.
8. FPGAs for stream processing
Infine, i flip-flops, chiamati anche registri, forniscono 1 bit
ognuno di memorizzazione e sono direttamente collegabili alle
unità logiche.
9. I vantaggi degli FPGA
sono economici
possono essere riprogrammati
l'alto numero di elementi logici permette di raggiungere un
livello di parallelismo non confrontabile con quello offerto da
architetture tradizionali multi-core o processori grafici
(parallelismo puro)
possono essere integrati all'interno per percorso dei dati
10. I problemi delle architetture attuali
Problemi noti da parecchi anni:
the memory wall
I/O bottlenecks
Problemi più recenti:
sfruttare a pieno il parallelismo su architetture multi-core
scendere a patti con processori di diversa natura
overhead crescente per intra-host communications
11. Il memory wall
Il vantaggio maggiore dell'utilizzo degli FPGA è dato dall'alto
livello di parallelismo offerto.
Questo permette infatti di scappare dal Von Neumann
bottleneck (memory wall), che colpisce tutte le architetture
classiche.
Nel modello di Von Neumann la memoria è fisicamente
separata dalla CPU e l'accesso ai dati si rivela molto costoso.
12. FPGA e la soluzione al memory wall
Negli FPGA i registri flip-flop (così come la block RAM tipica di
questa tipologia di processori) sono all'interno del chip e
strettamente legati agli elementi logici.
In aggiunta, le LUTs possono essere riprogrammate a runtime
per essere utilizzate come memoria aggiuntiva.
In questo modo è possibile accedere alle risorse di
memorizzazione degli FPGA sfruttando un alto livello di
parallelismo.
13. Content-Addressable Memory
La content-addressable memory (CAM) puo' essere acceduta
sfruttando il valore di un dato, piuttosto che un indirizzo di
memoria esplicito.
Tipicamente, le CAM vengono utilizzate per tradurre
l'identificativo di un elemento nell'indirizzo utilizzato per
memorizzare l'informazione di quell'elemento.
14. Bottlenecks
Con l'introduzione di tecnologie multi-core, le performance
offerte dalle CPU sono migliorate notevolmente, sebbene siano
rimasti i limiti architetturali dei prodotti hardware.
I veri colli di bottiglia dei sistemi attuali sono dati dalle
comunicazioni con le periferiche di input/output, che sono
considerati un problema critico.
Gli FPGA sono visti come una soluzione a questo problema,
infatti vari prototipi e alcuni prodotti hanno mostrato le
potenzialità della tecnologia FPGA per l'utilizzo pratico
applicato ad un database.
15. Glacier
Cos'è?
Glacier è composto da una
component library e da un
compilatore che permette di
tradurre ed implementare query su
database come circuiti hardware
su FPGA.
Come funziona?
Dato un piano di esecuzione di una query, il compilatore
individua le corrispondenti componenti e le collega all'interno di
un circuito digitale.
16. Glacier - Come funziona?
La component library di Glacier è composta da moduli
componibili che rappresentano gli operatori che processano lo
stream di dati.
Data una query, il compiler di Glacier istanzia i moduli
necessari e li connette tra loro in un circuito logico digitale che
viene poi tradotto in una configurazione FPGA.
17. Glacier - Operatori
Un vantaggio di Glacier è dato dalla componibilità, infatti
Glacier accetta composizioni arbitrarie degli operatori algebrici
supportati.
20. Network adapter
La comunicazione tra l'interfaccia di rete e la CPU è effettuata
utilizzando un protocollo a passi:
1. la scheda di rete trasferisce un pacchetto ricevuto
all'interno della memoria principale del sistema host
utilizzando il DMA
2. la scheda di rete informa la CPU dell'arrivo generando un
interrupt
3. l'interrupt permette al sistema operativo di effettuare uno
switch verso il kernel mode, dove il sistema operativo
decodifica tutti i pacchetti necessari, prima di passare i
dati allo user space
21. CPU adapter
Per inviare le informazioni risultanti alla CPU si utilizza ora una
strategia simile a quella utilizzata dall'interfaccia di rete descritta
in precedenza.
I dati vengono scritti in una coda FIFO accessibile dalla CPU
tramite un registro memory-mapped.
Ogni volta che un nuovo dato è stato preparato si genera un
interrupt per informare la CPU, che leggerà la coda FIFO e
passerà i dati al programma utente.
22. CPU adapter
Due differenti approcci sono concepibili per implementare una
comunicazione nell'altra direzione (dalla CPU all'FPGA):
I memory-mapped slave registers permettono alla CPU di passare i
dati direttamente all'interno del circuito FPGA scrivendo l'informazione
in una speciale locazione di memoria virtuale.
Mentre questo approccio fornisce un accesso intuitivo e con bassa
latenza all'FPGA, i protocolli di sincronizzazione necessari risultano
poco efficienti in condizioni di alto volume di traffico, se confrontati
all'approccio DMA-based, nel quale i dati vengono scritti in una
memoria esterna, dove la logica dell'FPGA si attiva autonomamente
dopo aver ricevuto una richiesta dalla CPU.
23. La piattaforma FPGA utilizzata
http://www.xilinx.com/univ/xupv5-lx110t.htm
Negli studi dell'ETH Zurich è stata utilizzata una piattaforma di
sviluppo Xilinx XUPV5-LX110T, caratterizzata da una FPGA di
tipo Virtex-5 XC5VLX110T da 100 MHz.
Caratteristiche della piattaforma:
XUPV5-LX110T board
1GB Compact Flash card
256 MB SODIMM module
10/100/1000 ethernet interface
SATA cable
XUP USB-JTAG Programming Cable
DVI to VGA adapter
6A power supply
24. Un caso pratico
Verranno mostrati i risultati di un caso pratico effettuato in
collaborazione con una banca Svizzera:
Il sistema della banca in oggetto richiede di processare in tempo
reale un alto volume di traffico dal mercato finanziario Eurex.
Il flusso di dati arriva sotto forma di pacchetti UDP ogni circa un
secondo.
La bassa latenza, specialmente sotto condizioni di traffico
elevato, è critica e difficile da raggiungere con metodi
tradizionali software-based che processano il flusso di dati in
ingresso.
25. Utilizzo di Glacier per il caso della
banca Svizzera
Nell'approccio in oggetto è stato utilizzato Glacier per generare
piani di esecuzione hardware ed eseguire query su processori
FPGA.
L'FPGA è stato posto tra l'interfaccia di rete e gli alti livelli
dell'applicazione utilizzata dalla banca e eseguita su un server
tradizionali.
26. System integration
Glacier fornisce interfacce per componenti che acquisiscono
dati dalla CPU o dalla rete e ritornano lo stream risultante al
mittente.
27. Glacier functionalities
Attualmente Glacier supporta
tutte le query composte dagli
operatori nella tabella vista in
precedenza.
In aggiunta a questi operatori vengono fornite interfacce per
la comunicazioni via rete e con la CPU, operatori per
bilanciare la latenza, concatenazione di stream e metodi per
valutare espressioni aritmetiche e booleane.
28. Una query di esempio
SELECT Price, Volume
FROM Trades
WHERE Symbol = "UBSN" AND Volume > 100000
INTO LargeUBSTrades
CREATE INPUT STREAM Trades (
Seqnr int, -- sequence number
Symbol string(4), -- valor symbol
Price int, -- stock price
Volume int -- trade volume
)
29. Una query di esempio
Il compilatore effettua il parsing della
query e produce una rappresentazione
corrispondente al piano di esecuzione
della query.
Gli operatori aritmetici e booleani sono
esplicitamente visibili, per poter
agevolare la preparazione dello schema
di compilazione composizionale.
30. Circuit generation
Il compito di Glacier è quello di tradurre un piano di esecuzione
di una query nella descrizione di un circuito hardware espresso
nell'hardware description language VHDL.
32. Query avanzate
I circuiti per query di aggregazione e per query che contengono
raggruppamenti richiedono meccanismi FPGA aggiuntivi, come
memorie con contenuto indirizzabile o multiplexer.
Attualmente l'implementazione di Glacier supporta aggregati
algebrici solo sotto alcune limitazioni.
33. Demo setup
La dimostrazione effettuata dal team dell'ETH Zurich ha messo
in mostra un intero design flow di Glacier ed uno stream
engine che processa i dati in arrivo dalla rete.
34. Design flow
Il compilatore di Glacier è incapsulato all'interno del design flow
che utilizza una catena di strumenti FPGA standard come back-
end.
36. Query compilation
Processo di compilazione dal piano di query a circuiti FPGA
prevede l'attuazione di regole di compilazione e successive
ottimizzazioni
37. From queries to circuits
Ogni operazione SQL puo' essere tradotta in un circuito
hardware in maniera sistematica tramite Glacier.
Per assicurare la reale composizione, tutte le regole del
sottopiano dovranno aderire ad una interfaccia comune:
ogni tupla di n colonne è rappresentata da n fili nella FPGA
in ogni set di fili, una tupla puo' essere propagata ad ogni clock
(100 milioni di tuple per secondo)
una linea aggiuntiva (data valid) indica la presenza di una tupla nel
clock corrente
useremo rettangoli per rappresentare componenti logici
indicheremo i registri come box grigi
ogni circuito sarà clock-driven o sincronizzato
le frecce rappresenteranno i fili tra un componente logico e l'altro
46. Optimization
Increasing Parallelism
L'eliminazione di registri intermedi (interni) porta ad esecuzioni
parallele.
47. Optimization
Trading Unions For Multiplexers
Utilizzare un multiplexer al posto di un operatore di unione n-
aria al termine dell'operazione di windows.
48. Example queries
Gli esempi presi in considerazione si basano su una
collaborazione tra ETH Zurich e una banca svizzera.
Lo schema dei dati (così come il contesto di utilizzo) è lo stesso
utilizzato in precedenza.
CREATE INPUT STREAM Trades (
Seqnr int, -- sequence number
Symbol string(4), -- valor symbol
Price int, -- stock price
Volume int -- trade volume
)
49. Query Q1
La prima query è molto semplice ed utilizza una semplice
proiezione applicata alla selezione.
SELECT Price, Volume
FROM Trades
WHERE Symbol = "UBSN"
INTO UBSTrades
50. Query Q2
E' la stessa query vista in precedenza, riportata in quanto ci
riferiremo ad essa come query Q2.
SELECT Price, Volume
FROM Trades
WHERE Symbol = "UBSN"
AND Volume > 100000
INTO LargeUBSTrades
51. Query Q3
Utilizzando le funzionalità della finestra scorrevole e del
raggruppamento, la query conta il numero di transazioni con
simbolo UBSN avvenute negli ultimi 10 minuti.
SELECT count () AS Number
FROM Trades [ SIZE 600
ADVANCE 60 TIME ]
WHERE Symbol = "UBSN"
INTO NumUBSTrades
52. Query Q4
La query utilizza una funzione di aggregazione wsum che
computa la somma pesata sui prezzi delle ultime quattro
transazioni con simbolo USBN.
SELECT wsum (Price, [ .5, .25, .125, .125 ])
AS Wprice
FROM (
SELECT * FROM Trades
WHERE Symbol = "UBSN"
)
[ SIZE 4 ADVANCE 1 TUPLES ]
INTO WeightedUBSTrades
53. Query Q5
Questa query determina i prezzi medi delle transazioni per ogni
simbolo su una finestra che si riferisce agli ultimi 10 minuti.
SELECT Symbol, avg (Price) AS AvgPrice
FROM Trades [ SIZE 600 ADVANCE 60 TIME ]
GROUP BY Symbol
INTO PriceAverages
54. Evaluation
La compilazione di query in circuiti logici ha significato
solamente se i circuiti risultanti risolvono i problemi visti in
precedenza.
Ci concentreremo ora su due valutazioni:
latenza e throughput
verificheremo che l'integrazione di un FPGA all'interno del
percorso dei dati migliora le performance a livello end-to-
end
55. Latency and throughput
Le caratteristiche di performance di piani di esecuzione
hardware possono essere accuratamente derivati unicamente
dall'analisi del design del circuito.
In questo modo le performance di un circuito di grandi
dimensioni sono determinate dalle performance dei suoi
sottopiani.
56. Latency
Misuriamo la latenza di un circuito hardware nel numero di cicli
di clock necessari dal momento in cui una tupla entra all'interno
del circuito al momento in cui il risultato viene prodotto.
Per il caso di query che contengono group-by la tupla di input
rilevante è l'ultima tupla dello stream di input.
In un flusso di dati sequenziale, la latenza di tutti i sottopiani si
accumula:
57. Latency & Issue Rate
Per circuiti semplici come le query Q1 e Q2, la latenza
corrisponde al numero di flip-flop coinvolti nel circuito.
Per le query Q3 e Q4 l'operatore di unione aggiunge altra
latenza dovuta alla coda FIFO che utilizza.
Nella query Q5 la differenza tra lettura/scrittura nella memoria
CAM introduce ulteriore latenza in maniera dipendente dalla
quantità di dati in arrivo.
58. Throughput
Il tempo massimo di esecuzione è direttamente dipendente
dalla sua frequenza di esecuzione.
Con un Clock di 100 MHz, nel nostro caso (query Q2)
possiamo processare 100 milioni di tuple al secondo.
Come visto nella tabella
precedente, si giunge ad un
issue rate di 1 per tutte le
query prese come esempio.
59. End-to-end performance
Un aspetto chiave dell'utilizzo degli FPGA per attività di data
stream processing è che il circuito hardware puo' essere
direttamente incorporato all'interno del percorso dei dati.
L'interesse è quello di utilizzare l'FPGA come preprocessore
che opera tra l'interfaccia di rete fisica e una CPU di tipo
general-purpose.
L'ETH Zurich ha implementato questa piattaforma di sviluppo
su FPGA, per verificare l'efficienza di questa configurazione.
60. Performance e flusso di dati
La più grande sfida è quella di processare dati di rete con un
alto tasso di package (concetto opposto a quello di pacchetti di
grandi dimensioni).
L'applicazione configurata via software, comincia a decadere
con un flusso di dati ~maggiore di 100.000 pacchetti al
secondo, a causa dell'alto overhead di comunicazione intra-
host, necessaria per ogni pacchetto.
Al contrario, il nostro circuito di esecuzione della query è
direttamente connesso all'interfaccia di rete fisica.
61. Risultati di performance
Gli studi dell'ETH Zurich hanno rivelato quanto sia difficile
generare un flusso di pacchetti molto alto all'interno di un
laboratorio.
Utilizzando un generatore di pacchetti NetBSD-based, si è
riusciti a generare un massimo di 1.000.400 pacchetti per
secondo (come traffico UDP), che non è risultata sufficiente a
saturare l'implementazione hardware utilizzata.
63. Conclusioni
I risultati dimostrano chiaramente che il circuito non delude le
aspettative.
Questo rende gli FPGA particolarmente interessanti, anche per
scenari molto comuni quali interrogazioni a basi di dati che
coinvolgono una grande quantità di informazioni.
Altri scenari interessanti riguardano ambienti in cui le
informazioni devono essere processate quasi in tempo reale
rendendo l'applicazione molto simile ai sistemi real-time.
64. Bibliografia
Streams on Wires - A Query Compiler for FPGAs
Rene Mueller, Jens Teubner, Gustavo Alonso
http://portal.acm.org/ft_gateway.cfm?id=1687654&type=pdf
Glacier: A Query-to-Hardware Compiler
Rene Mueller, Jens Teubner, Gustavo Alonso
http://portal.acm.org/ft_gateway.cfm?id=1807307&type=pdf
fpga4fun.com - What are FPGAs?
http://www.fpga4fun.com/FPGAinfo1.htm
IBM: Cell Broadband Engine resource center
http://www.ibm.com/developerworks/power/cell/index.html
