a query-to-hardware compiler for fpga architectures
TRANSCRIPT
Implementazione di linguaggi 2
Bruno Filippo [email protected]
A Query-to-Hardware Compiler for FPGA architectures
Enrico [email protected]
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.
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.
Il progetto Avalanche
Si tratta di un progetto dell'ETH Zurich.
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.
In Avalanche viene studiato l'impatto di architetture moderne su operazioni di elaborazione dei dati.
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
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.
FPGAs for stream processing
Le lookup tables sono collegate attraverso una interconnect network in grado di indirizzare i segnali attraverso il chip.
FPGAs for stream processing
Infine, i flip-flops, chiamati anche registri, forniscono 1 bit ognuno di memorizzazione e sono direttamente collegabili alle unità logiche.
I vantaggi degli FPGA
sono economicipossono essere riprogrammatil'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
I problemi delle architetture attuali
Problemi noti da parecchi anni:the memory wallI/O bottlenecks
Problemi più recenti:sfruttare a pieno il parallelismo su architetture multi-corescendere a patti con processori di diversa naturaoverhead crescente per intra-host communications
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.
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.
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.
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.
Glacier
Glacier è composto da una component library e da un compilatore che permette di tradurre ed implementare query su database come circuiti hardware su FPGA.
Dato un piano di esecuzione di una query, il compilatore individua le corrispondenti componenti e le collega all'interno di un circuito digitale.
Cos'è?
Come funziona?
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.
Glacier - Operatori
Un vantaggio di Glacier è dato dalla componibilità, infatti Glacier accetta composizioni arbitrarie degli operatori algebrici supportati.
FPGAs for stream processing
FPGA system setup
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
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.
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.
La piattaforma FPGA utilizzata
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.
http://www.xilinx.com/univ/xupv5-lx110t.htm
Caratteristiche della piattaforma:XUPV5-LX110T board1GB Compact Flash card256 MB SODIMM module10/100/1000 ethernet interfaceSATA cableXUP USB-JTAG Programming CableDVI to VGA adapter6A power supply
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.
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.
System integration
Glacier fornisce interfacce per componenti che acquisiscono dati dalla CPU o dalla rete e ritornano lo stream risultante al mittente.
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.
Una query di esempio
SELECT Price, VolumeFROM TradesWHERE Symbol = "UBSN" AND Volume > 100000INTO LargeUBSTrades
CREATE INPUT STREAM Trades ( Seqnr int, -- sequence number Symbol string(4), -- valor symbol Price int, -- stock price Volume int -- trade volume)
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.
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.
Circuit generation
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.
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.
Design flow
Il compilatore di Glacier è incapsulato all'interno del design flow che utilizza una catena di strumenti FPGA standard come back-end.
Stream engine
Query compilation
Processo di compilazione dal piano di query a circuiti FPGA prevede l'attuazione di regole di compilazione e successive ottimizzazioni
From queries to circuitsOgni 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 FPGAin 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 correnteuseremo rettangoli per rappresentare componenti logiciindicheremo i registri come box grigiogni circuito sarà clock-driven o sincronizzatole frecce rappresenteranno i fili tra un componente logico e l'altro
Compilation rulesSelection and Projection
Query di selezione
Query di proiezione
Compilation rulesArithmetics and Boolean Operations
Generico operatore aritmetico/booleano
Query di uguaglianza
Compilation rulesUnion
Operatore di unione
Operatore diunione binaria
Compilation rulesWindowing
Operatore window
Utilizzo dell'operatore
Window
Compilation rulesAggregation
Algebraic Aggregate Functions
Holistic Aggregate Functions
Compilation rulesGrouping
Utilizzodell'operatore
Group-By
Operatore Group-By
Compilation rulesConcatenation Operator
Query di concatenazione
Optimization Reducing Clock Synchronization
Tempo di esecuzione reale Miglioramento
del tempo di esecuzione
OptimizationIncreasing Parallelism
L'eliminazione di registri intermedi (interni) porta ad esecuzioni parallele.
OptimizationTrading Unions For Multiplexers
Utilizzare un multiplexer al posto di un operatore di unione n-aria al termine dell'operazione di windows.
Example queries
CREATE INPUT STREAM Trades ( Seqnr int, -- sequence number Symbol string(4), -- valor symbol Price int, -- stock price Volume int -- trade volume)
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.
Query Q1
La prima query è molto semplice ed utilizza una semplice proiezione applicata alla selezione.
SELECT Price, VolumeFROM TradesWHERE Symbol = "UBSN"INTO UBSTrades
Query Q2
E' la stessa query vista in precedenza, riportata in quanto ci riferiremo ad essa come query Q2.
SELECT Price, VolumeFROM TradesWHERE Symbol = "UBSN" AND Volume > 100000INTO LargeUBSTrades
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 NumberFROM Trades [ SIZE 600 ADVANCE 60 TIME ]WHERE Symbol = "UBSN"INTO NumUBSTrades
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 WpriceFROM ( SELECT * FROM Trades WHERE Symbol = "UBSN")[ SIZE 4 ADVANCE 1 TUPLES ]INTO WeightedUBSTrades
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 AvgPriceFROM Trades [ SIZE 600 ADVANCE 60 TIME ]GROUP BY SymbolINTO PriceAverages
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 throughputverificheremo che l'integrazione di un FPGA all'interno del percorso dei dati migliora le performance a livello end-to-end
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.
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:
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.
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.
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.
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.
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.
Confronto sulle performance
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.
Bibliografia
Streams on Wires - A Query Compiler for FPGAsRene Mueller, Jens Teubner, Gustavo Alonsohttp://portal.acm.org/ft_gateway.cfm?id=1687654&type=pdfGlacier: A Query-to-Hardware CompilerRene Mueller, Jens Teubner, Gustavo Alonsohttp://portal.acm.org/ft_gateway.cfm?id=1807307&type=pdffpga4fun.com - What are FPGAs?http://www.fpga4fun.com/FPGAinfo1.htmIBM: Cell Broadband Engine resource centerhttp://www.ibm.com/developerworks/power/cell/index.html