Integrazione di un’intera applicazione ASSIST

Nelle sezioni precedenti si `e descritta nel dettaglio l’integrazione di un modulo ASSI- ST in un componente CCM, tramite il tool ASSIST2CCM. In questa sezione invece viene discussa una parte del lavoro di tesi che ha riguardato l’integrazione di un’in- tera applicazione ASSIST, costituita da diversi moduli paralleli, in una applicazione costituita da componenti CCM che incapsulano i moduli ASSIST. Prima di discute- re ci`o, di seguito sono riportate alcune importanti caratteristiche dei CCM e del tool ASSIST2CCM che hanno influenzato l’andamento del lavoro. La prima sostanzia- le differenza riscontrata `e che l’ambiente dell’implementazione del CCM utilizzata, OpenCCM, `e, al contrario di ASSIST, un ambiente Java. Inoltre, nel mondo CCM,

le comunicazioni su stream non sono implementate e il tool ASSIST2CCM ha do- vuto sopperire a questa mancanza sfruttando il meccanismo delle comunicazioni ad eventi. Questo ha comportato, come detto nelle precedenti sezioni, l’introduzione di nuovi thread di interfaccia tra i due ambienti che sono stati mappati sui vari processori durante l’elaborazione.

Figura 4.5: Rappresentazione di un modulo ASSIST incapsulato in un componente CCM.

Il tool utilizzato per l’integrazione `e stato pensato per un’applicazione composta da un unico modulo ASSIST. Nonostante ci`o il tool ASSIST2CCM, poich´e imple- mentato in maniera modulare, `e stato utilizzato ugualmente in quanto, con oppor- tune modifiche, ha permesso l’integrazione di un’applicazione ASSIST complessa in pi`u componenti CCM (ogni modulo ASSIST viene incapsulato in un componente CCM).

In particolare, ASSIST2CCM `e composto da tre fasi. Nella prima fase vengono generati i file IDL del modulo ASSIST da integrare e degli eventi ad esso correlati (stream di ingresso ed uscita del modulo). A partire da questi vengono generati gli stub, gli skeleton e i file Java necessari per la costituzione del componente CCM. Infine, nell’ultima fase, vengono compilati i file Java generati ed il modulo ASSIST vero e proprio. Queste operazioni vengono eseguite in maniera automatica dal tool ogni volta che viene invocato per l’integrazione di un singolo modulo ASSIST.

Per effettuare l’integrazione di un’intera applicazione, quindi, si `e resa necessaria la separazione delle varie fasi descritte, poich´e vi era l’esigenza di un singolo file

IDL degli eventi, comune a tutti i componenti dell’applicazione, che specificasse le interfacce e quindi la composizione dei componenti. A partire da questo requisito sono stati generati i file IDL degli eventi e dei moduli separatamente ed in maniera automatica. In seguito ’manualmente’ sono stati uniti gli IDL degli eventi generati in un unico file utilizzato per la generazione automatica dei file Java, degli stub e degli skeleton necessari. Infine `e stata eseguita la compilazione dei file Java ed ASSIST. Il lavoro finale `e stato quello di creare un file main.java, in cui vengono localizzati, istanziati ed eseguiti i componenti CCM che costituiscono l’applicazione.

Metodologia proposta e

sperimentazioni

Sommario

In questo capitolo verr`a descritta l’intera applicazione sviluppata e la me- todologia seguita negli esperimenti. Verranno enunciati e commentati, infine, i risultati raggiunti, con particolare enfasi sull’eventuale overhead nel calcolo e nelle comunicazioni, introdotto dai componenti CCM, e sulla bont`a dell’Ap- plication Manager nel rimuovere i colli di bottiglia ed evitare lo spreco di risorse in una applicazione grid-aware.

L’obiettivo di questa tesi `e quello di verificare la validit`a del modello sperimentale presentato in precedenza: l’integrazione fra l’ambiente ASSIST ed il framework CCM come punto di partenza per la costruzione di un ambiente di programmazione ad alte prestazioni, basato sulla tecnologia a componenti, per le griglie computazionali. L’idea iniziale `e stata quella di implementare un’applicazione complessa che ri- chiedesse una potenza di calcolo non banale e che producesse un risultato concreto (vedi sez. 5.3). Per questo in fase di progettazione l’orientamento `e stato focalizzato su due applicazioni che tradizionalmente usufruiscono della tecnologia del calcolo parallelo per la loro elaborazione: il calcolo dell’insieme di Mandelbrot (vedi sez. 5.1) e la compressione MPEG (vedi sez. 5.2). Il risultato finale voluto `e stato quello di costruire un filmato compresso, rappresentante uno zoom su una particolare area dell’insieme di Mandelbrot, partendo da immagini non compresse dell’insieme.

Un requisito che l’applicazione doveva rispettare fin dalle fasi iniziali della sua progettazione `e stato quello di costituirla a partire da una serie di moduli distinti, in previsione dell’integrazione con i componenti CCM. Inoltre, in questo modo, `e stato possibile dare origine ad un’applicazione complessa che presentasse dei comporta- menti dinamici, i quali richiedevano l’introduzione di una gestione dell’applicazione in grado di renderla adattiva ai vari contesti. Di fatto, il calcolo dell’insieme di Man- delbrot richiede un tempo di elaborazione dipendente dall’area del piano complesso in cui l’immagine deve essere calcolata. L’applicazione progettata richiede il calcolo di immagini dell’insieme sempre diverse, questo fa s`ı che il tempo di elaborazione sia variabile per ogni immagine calcolata. `E questa la spiegazione per il comporta- mento dinamico che l’applicazione assume in fase di elaborazione. Per il particolare percorso scelto nell’esplorare l’insieme, l’elaborazione `e caratterizzata da tre fasi:

• prima fase: il calcolo delle immagini dell’insieme di Mandelbrot risulta veloce; • seconda fase: il tempo di elaborazione di ogni singola immagine sale notevol-

mente;

• terza fase: il tempo di elaborazione di ogni singola immagine scende nuova-

mente.

Questo ha comportato l’introduzione di un modulo di gestione per l’applicazione che consentisse un risparmio delle risorse allocate e/o un aumento delle prestazioni 5.3.5.

La fase di implementazione `e stata guidata di volta in volta dai risultati ottenuti dagli esperimenti. Questo ha consentito il conseguimento dell’obiettivo della tesi creando le condizioni, per la fase di sperimentazione, che potessero essere il pi`u possibile aderenti alla realt`a delle griglie computazionali. La fase iniziale di analisi dei requisiti ha comportato lo studio di due applicazioni ASSIST, che verranno considerate moduli dell’applicazione pi`u complessa, gi`a esistenti ed indipendenti fra loro: Mandelbrot ed MpegEncoder.

Nel seguito verranno illustrati in dettaglio i moduli che sono stati utilizzati. Inoltre saranno descritti vari studi dell’applicazione ed i risultati degli esperimenti eseguiti per ogni studio, in modo da descrivere le fasi del lavoro svolto e i fattori che hanno guidato i cambiamenti nell’implementazione. Nel primo studio verr`a descritta una prima versione dell’applicazione in cui i due moduli Mandelbrot ed MpegEnco- der sono stati collegati attraverso l’introduzione di un nuovo modulo (PixConverter ). Inoltre verranno presentati i risultati delle sperimentazioni eseguite inizialmente con i singoli moduli separati ed, in seguito, con l’intera applicazione. Nel secondo stu- dio verranno illustrati i fattori che hanno portato alla costituzione di una seconda versione dell’applicazione e come questi abbiano inciso sull’implementazione della nuova versione. Di fatto, tali fattori si riferiscono alle prestazioni dell’applicazione. Anche in questo caso verranno presentati i risultati ottenuti nelle fasi di sperimen- tazione. Nel terzo studio verranno illustrate le innovazioni portate alla seconda versione dell’applicazione che hanno dato origine cos`ı alla terza versione. Di fatto, queste modifiche sono state decise in quanto, dagli esperimenti precedenti, si `e evi- denziato un comportamento dinamico dell’applicazione dovuto alla variabilit`a del tempo di elaborazione di ogni immagine da parte del modulo Mandelbrot, descritta precedentemente. Ci`o ha motivato esperimenti sull’adattivit`a dell’applicazione che hanno portato come detto all’introduzione di un modulo di gestione per l’applica- zione che consentisse un risparmio delle risorse e/o un aumento delle prestazioni. In particolare `e stato introdotto il modulo ApplicationManager che simula l’adat- tivit`a dell’applicazione su griglia scegliendo, in base a dei tempi rilevati dagli altri moduli, quale implementazione utilizzare di due moduli MpegEncoder, introdotti per simulare un incremento o un decremento delle prestazioni nello stesso modulo. Quando il modulo Mandelbrot risulta il collo di bottiglia (seconda fase dell’ela- borazione), ApplicationManager determina l’utilizzo del modulo MpegEncoder che utilizza meno risorse (pi`u lento). Allo stesso modo, quando il collo di bottiglia risulta l’implementazione pi`u lenta dell’MpegEncoder (prima e terza fase dell’ela- borazione), ApplicationManager determina l’utilizzo dell’altra implementazione di

MpegEncoder che utilizza maggiori risorse. Il risultato voluto `e che, con questo tipo di politica (vedi sez. 5.3.5), la performance dell’applicazione sia paragonabile all’utilizzo del modulo MpegEncoder pi`u veloce, ma che allo stesso tempo non vi sia uno spreco di risorse impiegate per l’esecuzione del modulo MpegEncoder quando il collo di bottiglia `e il modulo Mandelbrot. Questo ha determinato l’introduzione di un modulo StreamStore che si occupa di ricostituire il risultato finale dell’intera elaborazione a partire dai dati ricevuti alternativamente dalle due implementazioni dei due MpegEncoder. Anche in questo caso verranno presentati i risultati degli esperimenti eseguiti con questa versione dell’applicazione sia su cluster omogeneo sia su griglia.

Il modulo ApplicationManager appena descritto, cos`ı come gli altri moduli, sono stati progettati in modo tale da rendere agevole l’integrazione dell’intera applica- zione con il framework CCM (vedi sez. 4.3.6), sperimentata fin dalla prima versio- ne dell’applicazione. Questo ha consentito di paragonare i risultati ottenuti dagli esperimenti dell’applicazione costituita solo da moduli ASSIST, con quelli ottenuti dall’applicazione costituita da moduli ASSIST integrati in componenti CCM (vedi cap. 4). Gli studi dell’applicazione effettuati sono stati eseguiti su piattaforme di- verse nelle differenti versioni. In particolare gli esperimenti relativi alla prima ed alla seconda versione dell’applicazione sono stati eseguiti su un cluster omogeneo, in quanto propedeutici allo studio dell’applicazione finale in esecuzione in ambienti eterogenei.

In questo capitolo verr`a presentata in dettaglio la versione finale dell’applicazione implementata al fine della sperimentazione e verranno introdotti i risultati ottenuti dagli esperimenti eseguiti sulle tre versioni dell’applicazione. In particolare tali sperimentazioni verranno suddivise in due sezioni:

1. Esperimenti preliminari (sez. 5.5), in cui vengono enunciati i risultati raggiunti dalle sperimentazioni delle prime due versioni dell’applicazione, in ambiente omogeneo, che sono stati propedeutici per la definizione della versione finale

dell’applicazione;

2. Esperimenti sulla versione finale dell’applicazione (sez. 5.6), in cui sono ri- portati i risultati pi`u importanti per gli obiettivi fissati nella tesi (vedi cap. 1): validazione del modello sperimentale proposto (integrazione ASSIST-CCM come punto di partenza per la definizione di un ambiente di programmazione per applicazioni grid-aware) e della politica adattiva implementata dall’Appli- cationManager.

5.1

L’insieme di Mandelbrot

L’insieme di Mandelbrot `e definito come l’insieme dei numeri complessi c tale per cui non `e divergente la successione definita da:

  

zn+1= zn2 + c;

z0 = 0;

L’insieme consiste in un frattale (vedi fig. 5.1), la cui elaborazione richiede una

Figura 5.1: Immagine dell’insieme di Mandelbrot.

notevole potenza di calcolo. Per questo motivo `e stato scelto, in questa tesi, di uti- lizzare un modulo parallelo che implementa questo calcolo come modulo generatore

delle immagini necessarie a formare il filmato finale. L’insieme deve il suo nome a Benoˆıt Mandelbrot che nel 1975 introdusse il termine frattale per descrivere alcuni comportamenti matematici che sembravano avere un comportamento caotico. Que- sto genere di fenomeni nasce dalla definizione di curve o insiemi tramite funzioni o algoritmi. Si pu`o dimostrare che se il modulo di zn `e maggiore di 2 allora la suc-

cessione diverge e quindi il punto c `e esterno all’insieme di Mandelbrot. Il minimo valore di n per cui |zn| > 2 `e un indice di quanto ’lontano dal bordo’ si trova un

punto e viene spesso utilizzato, come descritto in seguito, per la visualizzazione del colore di ogni punto dell’insieme.