User:Armarl


Tesi

Il lavoro di tesi tratta il confronto tra i linguaggi di programmazione lua e java dal punto di vista dei tempi di esecuzione e della memoria utilizzata.

Algoritmi Utilizzati

1. Hello world: stampa 1000 volte la stringa "Ciao mondo";
2. Attraversamento di array (tipi: int, double, float, ArrayList e Vector): crea ed attraversa un array di 1000 elementi;
3. Numeri di Fibonacci;
4. Accesso a file: legge due file di dimensioni 1.2 mega ciascuno e concatena le stringhe lette stampandole;
5. Classe Account: test di ereditarietà;
6. Whetstone: test di operazioni di tipo floating point;
7. Dhrystone: test di operazioni su stringhe;
8. Quicksort: algoritmo di ordinamento con chiamate ricorsive su un array di double di 100000 elementi;
9. Algoritmo di Dijkstra: cammino minimo su un grafo di 1000 vertici e altrettanti archi;

Conclusioni

Il confronto fra le due macchine virtuali è stato effettuato a parità di condizioni e sulla stessa macchina; sono stati utilizzati gli stessi algoritmi con la medesima implementazione. In generale si può osservare che Lua risulta meno lento nelle applicazioni in cui non sono presenti molte operazioni aritmetiche. Infatti, negli algoritmi Whetstone, Dhrystone e nell’algoritmo di Dijkstra, che contengono molte operazioni di questo tipo, Lua impiega un tempo superiore rispetto a quello impiegato da Java; mentre, in algoritmi come il Quicksort che contiene più confronti ed assegnazioni che operazioni aritmetiche o algebriche Lua risulta più performante. Per quanto riguarda le risorse di memoria, Lua in genere è in grado di eseguire l’applicazione con un impiego di risorse inferiore rispetto a Java. Osservando infatti i risultati degli algoritmi utilizzati si può notare che le risorse di memoria impiegate da Lua sono sempre inferiori a quelle impiegate da Java ad eccezione degli algoritmi Quicksort e Dijkstra. Le prove quindi hanno evidenziato una propensione per Lua all’ottimizzazione delle risorse di memoria. L’utilizzo del compilatore Just in time LuaJit ha migliorato le prestazioni di Lua, anche se ha ribaltato la situazione negli algoritmi più semplici introducendo un overhead per il bootstrap del compilatore Just in Time. Anche l’utilizzo delle risorse di memoria da parte di Lua sono aumentate utilizzando LuaJit restando, comunque, inferiori alle risorse impiegate da Java. LuaJit ha migliorato notevolmente i tempi di esecuzione degli algoritmi Whetstone, Dhrystone, Quicksort, Dijkstra, Fibonacci Ricorsivo, Accesso a File; i tempi di esecuzione in questi algoritmi in media si sono ridotti di un terzo. L’aumento dell’impiego delle risorse di memoria riscontrato utilizzando LuaJIT risulta maggiore negli algoritmi più complessi come il whestone, dhrystone, dijkstra e quicksort.

Seminari sostenuti

23-11-2007 – Panoramica del linguaggio di programmazione Lua
07-03-2008 – Lua vs Java
27-06-2008 – Benchmark: Lua, Java e LuaJIT

Bibliografia

Lua
Sito ufficiale Lua
Wiki Lua
LuaJIT
The Benchmark Game
Netlib
Java Doc

User:Salva3

Antonio Salvati

Lavoro di tesi

Il nostro lavoro di tesi, svolto insieme a Luigi Bifulco, è stato quello di estendere un proxy web che fornisce servizi per la modifica e la personalizzazione di pagine web: il proxy SISI, rendendolo distribuito e quindi aumentandone le potenzialità. Abbiamo utilizzato un paradigma di calcolo distribuito: il Grid Computing.

I sevizi offerti dal proxy sono servizi più o meno costosi che agiscono sulle pagine web, modificano codice HTML, immagini e fogli di stile CSS. in precedenza erano presenti sul proxy stesso come moduli di Apache, quindi un solo nodo si occupava di gestire e soddisfare tutte le richieste. Esportando i servizi su Grid abbiamo alleggerito il carico del proxy, che ora si occupa solo di smistare le richieste ai vari servizi distribuiti, in base al profilo dell’utente decide quali servizi invocare, in base al carico dei nodi sui quali è presente il servizio da invocare decide dove invocarlo.

Lo strumento utilizzato per creare i nostri servizi distribuiti è stato Globus Toolkit, che implementa le specifiche WSRF (specifiche che standardizzando i Grid Services), mentre il proxy è diventato in pratica un client dei servizi che abbiamo realizzato, il suo compito infatti è divenuto quello di ricevere le richieste dai web browser e applicare i servizi effettuando chiamate remote a Grid Services e non più chiamando moduli propri sullo stesso nodo.

Le maggiori problematiche affrontate e risolte sono state appunto quelle di mettere in comunicazione due sistemi molto differenti tra loro: da un lato un proxy in mod_perl basato su Apache Web Server e dall’altra Globus Toolkit, un’implementazione delle specifiche riguardanti il Grid Computing in Java. Ciò è stato possibile poiché la comunicazione lato Globus Toolkit prevedeva l’uso di messaggi SOAP, essendo i Grid Services un’estensione dei Web Services, e quindi ci è stato possibile invocare i servizi realizzati creando dei messaggi SOAP ad hoc per l’invocazione di Grid Services. Essendo i servizi ereditati scritti in mod_perl si è preferito tenere il codice Perl ed incorporarlo nei servizi Grid: in pratica i Grid Services realizzati utilizzano gli script Perl già esistenti. Ciò è stato fatto per mantenere i servizi identici nel loro comportamento ed evitare il rischio di trovare incongruenze tra i nuovi e i vecchi servizi. Inoltre l’invocazione dei suddetti script avviene per mezzo di un interprete Perl persistente, emulando così il comportamento di mod_perl ed evitando di appesantire il nodo per le troppe chiamate ad un interprete perl classico (che viene avviato per ogni invocazione di ogni script).

Seminari