Architettura dataflow
L'architettura Dataflow è un tipo di architettura dei calcolatori che contrasta con il paradigma dell'architettura di von Neumann, dato che pone al centro dell'architettura gli operandi da elaborare e non le operazioni che elaborano gli operandi.
Concettualmente non necessita di un program counter dato che l'esecuzione delle istruzioni è governata dalla disponibilità degli operandi, appena tutti gli operandi di un'istruzione sono disponibili.
Nei progetti che prevedono l'utilizzo di memoria convenzionale, nella quale i dati sorgente sono indirizzati tramite tag, l'architettura viene definita dataflow statica. Queste macchine non sono in grado di eseguire più istanze della stessa procedura dato che i tag non sono differenziati per istanza ma solo per dati sorgente. Nei progetti che utilizzano la content addressable memory (CAM) sono chiamate dataflow dinamiche, queste utilizzano i tag per velocizzare l'esecuzione parallela.
Applicazioni[modifica | modifica wikitesto]
Sebbene in ambito general purpose questa architettura non ha trovato successo commerciale, in alcuni ambiti specialistici come il digital signal processing, l'instradamento, il graphic processing e il data warehousing si sono sviluppate soluzioni commercialmente valide[senza fonte]. Questa architettura trova ampi utilizzi come modello concettuale nello sviluppo di architetture software per database e più in generale per lo sviluppo di applicazioni parallele.
Le architetture sincrone ben si sposano con esigenze di analisi in tempo reale di dati, come quelle effettuate dagli apparati di rete. La natura deterministica delle architetture dataflow permette di gestire compiti complessi come il load balancing dei processori, la sincronizzazioni e la gestione di risorse condivise[1] in modo semplice ed efficiente.
Storia[modifica | modifica wikitesto]
Lo sviluppo in hardware di architetture dataflow fu uno dei maggiori filoni di ricerca degli anni 70 e dell'inizio degli anni 80. Jack Dennis del MIT fu un pioniere degli studi sui dataflow statici mentre la Manchester Dataflow Machine e il MIT Tagged Token architecture furono dei progetti pionieri per le architetture dataflow dinamiche.
Funzionamento[modifica | modifica wikitesto]
Normalmente un compilatore analizza il codice sorgente del programma e individua le dipendenze dei dati, il compilatore poi crea il programma binario memorizzandovi all'interno le istruzioni da eseguire disponendole in modo sequenziale. Le dipendenze sui dati non sono salvate dal compilatore nel codice binario. Un compilatore per macchine dataflow memorizza nel codice binario le dipendenze, ogni dipendenza viene identificata con un tag univoco e non con il nome della variabile indicata dal programmatore. Questo permette alle macchine basate su architettura dataflow di eseguire le istruzioni appena le relative dipendenze sono soddisfatte, quindi una macchina dataflow e intrinsecamente parallela ed esegue il codice fuori ordine.
I programmi vengono memorizzati in una CAM nelle architetture dataflow dinamiche. Quando tutti gli operandi di un'istruzione sono disponibili (per il completamento di un'istruzione precedente o per l'input dell'utente) l'istruzione viene marcata come eseguibile e viene inviata alla prima unità di esecuzione disponibile. Quando l'istruzione è stata completata i risultati vengono salvati nella CAM con il loro relativo tag. Tutte le istruzioni che dipendevano da quel tag particolare vengono marcate come eseguibile e questa permette di evitare race condition dato che quando un'istruzione viene eseguita tutte le sue dipendenze sono state risolte. L'ordine di esecuzione più differire da quello stabilito dal programmatore anche in modo notevole.
Ogni istruzione con i propri operandi viene trasmessa all'unità di esecuzione come un pacchetto. Similmente ogni risultato proveniente dalle unità di elaborazione viene inviato alla CAM come pacchetto. Questa organizzazione a pacchetti permette di realizzare reti di elaborazione parallele su ampia scala. Le reti basate su architettura dataflow ricevono pacchetti di dati da elaborare e restituiscono pacchetti di dati elaborati. In contrasto con l'architettura di von Neumann i dati non sono memorizzati in modo permanente nella memoria ma sono messaggi che esistono solo quando stanno partendo o arrivando dalla memoria.
La ricerca tuttavia non è riuscita a risolvere i seguenti problemi:
- Efficiente trasmissione di pacchetti dati su reti parallele.
- Efficiente trasmissione di pacchetti istruzioni su reti parallele.
- Costruzione di CAM abbastanza capienti da contenere tutte le dipendenze di programmi reali.
Le istruzioni e i loro dati sono un parallelismo troppo basso per essere utile, la trasmissione e la ricezione dei pacchetti con le istruzioni in reti ampie richiede più tempo della effettiva esecuzione delle istruzioni stesse, in sostanza l'overhead introdotto dalla rete è eccessivo.
L'esecuzione fuori ordine è diventato il paradigma dominante fin dagli anni 90 e questa può essere vista come una forma di esecuzione a dataflow. L'esecuzione fuori ordine prevede la creazione di una finestra d'esecuzione, dentro questa finestra le dipendenze tra le singole istruzioni vengono analizzate e le istruzioni vengono eseguite appena le dipendenze sono risolte, senza tener conto dell'ordine di esecuzione previsto dal programmatore. L'esecuzione in tempo reale di questa analisi limita la finestra a un numero limitato di istruzioni che normalmente oscilla tra le 20 e le 200 istruzioni, lo stesso processore di solito è dotato di un numero limitato di unità funzionali che oscillano tra l 2 e le 6. Un'architettura a dataflow completa invece prevede l'analisi di tutto il programma e un numero molto ampio di unità d'esecuzione.
Note[modifica | modifica wikitesto]
- ^ (EN) HX300 Family of NPUs and Programmable Ethernet Switches to the Fiber Access Market, su EN-Genius, 18 giugno 2008 (archiviato dall'url originale il 22 luglio 2011).
