A query-to-hardware compiler for FPGA architectures
1 like503 views
Il documento discute l'implementazione di un compilatore per FPGA per l'elaborazione di flussi di dati, sottolineando i vantaggi delle architetture multi-core e la riduzione della latenza tramite l'integrazione di FPGA. Viene presentato Glacier, uno strumento che traduce query in circuiti logici, e si esaminano miglioramenti delle performance nel processamento dei dati, in particolare in un caso di studio con una banca svizzera. Si evidenziano infine le sfide e le opportunità offerte dagli FPGA per risolvere colli di bottiglia nelle architetture tradizionali, ottimizzando il throughput e la latenza.
![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](https://image.slidesharecdn.com/implementazionelinguaggi21-12990607858324-phpapp02/85/A-query-to-hardware-compiler-for-FPGA-architectures-51-320.jpg)
![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](https://image.slidesharecdn.com/implementazionelinguaggi21-12990607858324-phpapp02/85/A-query-to-hardware-compiler-for-FPGA-architectures-52-320.jpg)
![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](https://image.slidesharecdn.com/implementazionelinguaggi21-12990607858324-phpapp02/85/A-query-to-hardware-compiler-for-FPGA-architectures-53-320.jpg)
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.
- 18. FPGAs for stream processing
- 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.
- 35. Stream engine
- 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
- 38. Compilation rules Selection and Projection Query di selezione Query di proiezione
- 39. Compilation rules Arithmetics and Boolean Operations Generico operatore aritmetico/booleano Query di uguaglianza
- 40. Compilation rules Union Operatore di unione Operatore di unione binaria
- 41. Compilation rules Windowing Operatore window Utilizzo dell'operatore Window
- 42. Compilation rules Aggregation Algebraic Aggregate Functions Holistic Aggregate Functions
- 43. Compilation rules Grouping Operatore Group-By Utilizzo dell'operatore Group-By
- 44. Compilation rules Concatenation Operator Query di concatenazione
- 45. Optimization Reducing Clock Synchronization Tempo di esecuzione reale Miglioramento del tempo di esecuzione
- 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