Swaptions

L’obbiettivo di questa applicazione è di calcolare il valore di un portfolio di swaptions finanziarie, basandosi sul framework Heath-Jarrow-Morton [6]. La particolarità del modello utilizzato è che non può essere risolto analiti- camente utilizzano delle equazioni differenziali, quindi l’applicazione utilizza una simulazione Monte Carlo per stabilire il valore di tutto il portfolio. Come parametri prevede la possibilità di specificare il numero di thread da utiliz- zare, il numero di simulazioni da effettuare e un seed da utilizzare per la generazione pseudo-casuale delle caratteristiche delle swaptions nel portfo- lio. I parametri applicativi adatti ad influenzare la fase di Run-Time sono solamente il numero di thread impiegati e il numero di simulazioni, in quanto il seed non influenza le prestazioni.

Prima di integrare il framework ARGO è stato necessario modificare il comportamento dell’elaborazione. Invece di calcolare un numero fisso di swaptions che compone il portfolio e terminare l’esecuzione, viene simulato uno stream di azioni finanziarie che deve essere valutato dall’applicazione. Per ottenere tale scopo si è trasformato il numero di swaptions che compone il portfolio nel numero di elementi processati contemporaneamente (ognuno affidato ad un thread), ed è stato creato un ciclo esterno che simula la durata dello stream da elaborare.

Utilizzando questo approccio si ricalcola più volte il valore delle swap- tions, tuttavia si è effettuata tale modifica in quanto non è importante il valore del risultato ottenuto, ma mostrare la capacità di adattamento offerta dal framework e l’overhead introdotto dallo stesso. La conseguenza inter- essante derivata dall’utilizzare questo approccio è che all’inizio di ogni ciclo vengono creati i thread e distrutti alla fine. Considerando che la creazione di un thread è un’operazione onerosa, nel test sull’adattabilità viene riscon- trato un comportamento interessante. Questa applicazione è stata scelta per evidenziare come il metodo di attuazione del cambiamento dei parametri applicativi influisca sul comportamento dell’applicazione.

6.3.1.1 Adattabilità rispetto alle prestazioni

In questa prova si cerca di mostrare come il framework permetta all’ap- plicazione di rispettare i goal stabiliti senza avere il bisogno di coordinarsi con altri attori. Per ottenere questo scopo si avvia un’istanza dell’appli- cazione ogni venti secondi e si tiene traccia delle grandezze rilevanti. Per caratterizzare le prestazioni dell’applicazione vengono misurati il throughput dell’applicazione e l’errore commesso nell’elaborazione. L’errore è calcolato come differenza rispetto al risultato ottenuto con i parametri che permetto la miglior qualità possibile. Per misurare le prestazioni del framework si misura il tempo impiegato a decidere la configurazione di parametri migliore e il tempo di esecuzione vero e proprio.

All’applicazione viene imposto un vincolo sull’errore massimo che può commettere e sul throughput che fornisce. Viene utilizzata una funzione di rank geometrica che cerca di minimizzare in ugual misura il numero di thread utilizzati e l’errore commesso. Per evidenziare le azioni che il framework intraprende viene riportato anche il numero di thread proposto. Le politiche appena espresse non vengono modificate in fase di Run-Time, i cambiamenti ottenuti sono frutto del cambiamento dell’ambiente di esecuzione che fa da contesto all’applicazione stessa.

In Figura 6.7 sono presenti i risultati ottenuti dal framework dalla prima applicazione eseguita. Come è possibile osservare il vincolo sul throughput viene rispettato per la maggior parte del tempo, tuttavia nell’intorno del decimo istante di tempo rimane insoddisfatto per molti istanti di tempo. In Figura 6.7c è possibile vedere come l’applicazione cerchi di compensare tale mancanza aggiungendo thread e diminuendo il numero di punti utilizzati per effettuare la simulazione (l’errore aumenta), ovvero effettuando tutte le azioni che ha a disposizione. Come è possibile vedere dalle immagini l’anda- mento delle caratteristiche osservate è abbastanza movimentato, tale effetto si genera in quanto sono state lanciate diverse istanze dell’applicazione che si autoconfigurano in maniera indipendente, influenzandosi a vicenda. La causa di tale influenza è derivata dal fatto che l’attuazione delle modifiche decise

0.6 0.8 1 1.2 1.4 1.6 1.8 2 0 10 20 30 40 50 60 70 80 90 100 Throughpu t (swaptio n/sec) Numero cicli Throughput Goal

(a) Throughput dell’applicazione

0 0.0001 0.0002 0.0003 0.0004 0.0005 0.0006 0.0007 0.0008 0.0009 0.001 0 10 20 30 40 50 60 70 80 90 100 Errore Numero cicli Error Goal (b) Errore commesso 2 2.5 3 3.5 4 0 10 20 30 40 50 60 70 80 90 100 Thread utilizzat i Numero cicli (c) Thread utilizzati 0 10 20 30 40 50 60 70 80 90 100 0 10 20 30 40 50 60 70 80 90 100 Overhead (microsecondi) Numero cicli (d) Overhead del framework

0 2 4 6 8 10 12 14 16 0 10 20 30 40 50 60 70 80 90 100 Throughpu t (swaptio n/sec) Numero cicli Throughput Goal

(a) Throughput dell’applicazione

0 0.0001 0.0002 0.0003 0.0004 0.0005 0.0006 0.0007 0 10 20 30 40 50 60 70 80 90 100 Errore Numero cicli Error Goal (b) Errore commesso 2 2.5 3 3.5 4 0 10 20 30 40 50 60 70 80 90 100 Thread utilizzat i Numero cicli (c) Thread utilizzati 2 4 6 8 10 12 14 0 10 20 30 40 50 60 70 80 90 100 Overhead (microsecondi) Numero cicli (d) Overhead introdotto

Figura 6.8: Stress test per swaptions

dall’AS-RTM sono molto onerose, provocando oscillazioni nelle prestazioni del sistema, che si riflettono in oscillazioni decisionali.

Per questo motivo è importante nella fase di progettazione dell’appli- cazione prevedere delle tecniche di attuazione dei cambiamenti che non com- portino operazioni molto onerose computazionalmente.

6.3.1.2 Stress test

In questa prova si considera una sola istanza dell’applicazione a cui viene au- mentato periodicamente il vincolo che esprime il throughput minimo che deve raggiungere, mantenendo invariato il vincolo sull’errore commesso. In questo modo è possibile osservare le azioni intraprese dal framework. Le politiche de- cisionali sono le stesse dell’esperimento precedente, si è modificato solamente i valori dei vincoli.

In Figura 6.8 sono raffigurati i risultati ottenuti dal framework. A dif- ferenza del caso precedente tali risultati sono molto più stabili e lineari, in quanto l’attuazione dei cambiamenti non è sufficiente ad alterare la capacità computazionale del sistema. Come è possibile notare al trentesimo istante

il modello diventa impossibile, in quanto non viene più rispettato il vincolo sull’errore. Dopo tale istante, il framework rinuncia a soddisfare tale vinco- lo per cercare di inseguire quello di priorità maggiore. Tuttavia è possibile osservare come il punto di lavoro selezionato cerca di restare sempre vicino al valore del vincolo sull’errore, rispettando correttamente la metodologia proposta.