In questa nuova rivoluzione Web chiamata per brevità HTML5, uno dei protagonisti è senza alcun dubbio il riesumato JavaScript. Tornato dalla tomba in cui sembrava essere stato sepolto per riportare nuova luce e dinamicità ai contenuti Web.

JavaScript, in quanto computazione client-side ha anche lo spiacevole effetto di condizionare le prestazioni di un sito e di scaricare il gravoso costo della sua esecuzione sui browser. Questa è la casus belli della JavaScript War che imperversa nei centri di sviluppo dei vari browser da qualche anno.

Iniziamo quindi ad analizzare la battaglia dei contendenti più accreditati: Firefox e Chrome.

Firefox

• Versione: 5.0
• Rendering: Geko 5.0
• Motore JavaScipt: SpiderMonkey

Chrome

• Versione: 13
• Rendering: WebKit 535.1
• Motore JavaScipt: V8 3.3.10.22

BENCHMARK 1 : SUNSPIDER 0.9.1

Il primo benchmark è SUNSPIDER di casa WebKit. Il test mi ha sorpreso perché Firefox risulta più performante di Chrome. Come potete vedere dal risultato (FROM è Firefox e TO è Chrome) la differenza è minima ma a favore di Firefox.

Risultato:

BENCHMARK 2 : V8 BENCHMARK

Questo è un benchmark piuttosto minimale fatto da Google appositamente per V8 e usato per il tuning dello stesso. C’è poco da sorprendersi che il risultato sia a vantaggio di V8 per un buon 168% in più.

Risultati Firefox:

Risultati Chrome:

BENCHMARK 3 : Kraken 1.1

Per par condicio ho lanciato anche Kraken, benchmark minimale di casa Mozilla. Tuttavia anche Kraken va contro la sua stessa creatura. La differenza è meno marcata (106%) ma comunque sostanziosa. In pratica Firefox ci mette il doppio del tempo del concorrente a terminare il benchmark.

BENCHMARK 4 : Dromaeo

Per finire ecco il risultato del benchmark javascript più completo che conosco: Dromaeo. Sempre di casa Mozilla ma è chiaro, verificabile e il codice del benchmark è disponibile a chiunque voglia controllarlo.

Risultati Firefox = 132.72runs/s

Risultati Chrome = 238.36runs/s

Potete controllare i dettagli cliccando sui link.

Chrome è più performante del 79.6% rispetto a Firefox.

CONCLUSIONE

Questa sfida è terminata 3-1 per il browser di Google e quel punto di Firefox è strappato per un soffio. Insomma, Chrome si classifica, come da pronostico, estremamente più veloce di Firefox nell’esecuzione del JavaScript. Tenendo però conto della velocità con cui questi Browser si riproducono non ci resta che aspettare qualche mese per vedere come evolverà questa appassionante sfida.

L’attesa per KDE 4.5 si fa sempre più spasmodica. A mio avviso siamo ad un giro di boa nella storia della release più infamata del panorama open-source. KDE, come sapete, ha la nomea di essere instabile eppure posso assicurarvi che non l’ho mai vista crashare su distro serie (Sidux), certo che se valutate KDE su Kubuntu allora ve la cercate.

Tornando alla nuova release le novità non sono molte, tuttavia molte delle features precedenti vengono rafforzate, stabilizzate e migliorate dal punto di vista dell’usabilità. È il caso del System Setting, il “pannello di controllo” di KDE, che perde le tab in modo da avere tutti i comandi in un unica schermata, senza però perdere in chiarezza. Anche il gestore attività è notevolmente cambiato, molto più pratico ed usabile. Oppure le nuove notifiche, molto più ordinate e meno invasive.

Ma quella che a mio avviso è il vero progresso, la punta di diamante del nuovo KDE 4.5 è l’integrazione, ormai quasi completa, fra le varie applicazioni Nepomuk e Akonadi.

Akonadi è un server che si occupa di gestire le informazioni dei programmi PIM (email, appuntamenti, contatti, ecc) in modo centralizzato e veloce. Questo significa che tutte le applicazioni come KMail, KOrganizer e via discorrendo, possiedono un unica infrastruttura dati accessibile da qualunque altro programma. Proprio questo permette a Nepomuk, il servizio di indicizzazione di KDE, di indicizzare oltre ai file anche email, appuntamenti, allegati, contatti, e molto altro anche grazie all’uso di tag. Queste ricerche possono essere fatte sfruttando Krunner come se si stesse lanciando una qualunque applicazione.

È il primo grande esempio di desktop semantico. La possibilità di accedere con un paio di comando a qualunque risorsa all’interno del pc è divenuta quasi realtà.

Un altra grande novità, a mio avviso, è il netto miglioramento della suite KOffice che, anche grazie ai pesanti investimenti di Nokia, è ormai una suite moderna, funzionale e dall’interfaccia utente molto ingegnosa. Molti passi in avanti devono essere fatti ma la versione 2.2 può cominciare senza dubbio ad essere un sostituto di OpenOffice, almeno per chi non ha grosse pretese.

KDE 4.5 può quindi essere l’ottimo punto di partenza per chi vuole provare KDE sfidando le malelingue che vogliono (ingiustamente) KDE instabile e macchinoso. Tutto questo in attesa di vedere la riscrittura di KWin con le nuove OpenGL che ci attende nella 4.6 e 4.7. È qualcosa che vi consiglio di tenere d’occhio.

KDE 4.5 sarà disponibile nella prossima release di Kubuntu e OpenSuse mentre per chi utilizza Sidux, molto probabilmente si vedrà qualcosa verso settembre sempre che i pacchettizzatori non mi sorprendano con una release a tempo di record.

PS riguardo al flame: Per chi non lo sapesse quando nel titolo di un post scrivo “Flame” solitamente non rispondo ai commenti. Lo faccio perché un flame è un argomento fazioso (sia da parte mia che da parte di chi commenta) e quindi è solitamente inutile discutere e trasformare i commenti del blog in una bolgia. Tuttavia li leggo sempre tutti e ho notato che molti sono d’accordo con me e questo mi fa sentire meno solo.

Questa mattina stavo rivedendo lo script che ho postato ieri. L’ho ottimizzato un po’ e ho tolto una 30-ina di righe. Dopodiché mi sono messo a fare alcuni test prestazionali provando ad addestrare una rete di circa 5000 neuroni disposti in vari modi (da 3 strati da 2000 fino a 250 strati da 20).

Le prestazioni non erano mozzafiato e questo lo sapevo già, il python non è il linguaggio più indicato per applicazioni fortemente CPU bound.

Tuttavia la sorpresa l’ho avuta quando ho testato lo script con la nuova versione di Python (la 3.1) e costatando una diminuzione delle prestazioni di circa il 50%.

Cinquantapercento! Mica bruscolini!

Ho rifatto il conto con vari test (sempre utilizzando il mio script) e il risultato era sempre di questa entità. Le cose sono due:

1. L’interprete di python3.1 è proprio più lento di suo. In questo caso il problema verrà fuori quando si passerà definitivamente da 2.6 a 3.
2. Alcune funzioni che nella 2.6 vanno a meraviglia nella 3.1 fanno schifo. In questo caso la cosiddetta migrazione da 2.6 a 3 potrebbe essere meno facile del previsto.

In attesa  di risposte vi chiedo se voi sapete qualcosa di più al riguardo. Se volete poi posso fornire altri dettagli sui vari test.

UPDATE 19/07/10

Ho ripetuto i test su un’altra distribuzione (sidux) e questa volta i risultati sono un po’ diversi. La versione 3 di python è sempre più lenta ma in percentuali accettabili (5% circa).

Inoltre ho provato anche con psyco ottimizzando del 75% le prestazioni del programma.

In questi giorni sto studiando abbastanza approfonditamente le Qt e non vi nascondo che mi sto lentamente innamorando di questo framework. Già lo apprezzavo per molti motivi, ma più scendo nel dettaglio più scopro una certa “poesia ingegneristica”. Oggi però non sono qui per parlarvi delle QT, bensì del recente rilascio della nuova versione di Qt Creator.

Qt Creator 2 è l’ultima versione di un IDE multi-piattaforma dedicato alla programmazione in Qt. L’ambiente integra tutti i classici strumenti già noti ai programmatori Qt) in un unico ambiente integrato dotato di un editor, debug e interfacciamento ai più popolari sistemi di controllo di versione. Potete vedere un piccolo tour in questo video:

QtCreator integra un editor piuttosto avanzato.

La finestra dell'editor.

Anche QtDesigner è perfettamente integrato:

QtDesigner all'interno di QtCreator

E la documentazione completa del mondo Qt è accessibile con un semplice click.

QtAssistant in QtCreator

QtCreator è disponibile nei repository delle maggiori distribuzioni anche se, al momento, è disponibile solamente la versione 1.3. Se avete fretta e voglia potete provare la versione 2 scaricandola da qui. La versione per linux è facilmente installabile eseguendo il file .bin che scaricherete. Potete anche installare QtCreator in locale senza cioè sporcare il sistema con un installazione “non ufficiale”.

QtCreator non è attualmente all’altezza di altri colossi degli IDE quali Eclipse o Visual Studio, ma la strada imboccata da Nokia sembra proprio quella di creare una valida e completa alternativa. I presupposti ci sono tutti, non ci resta che aspettare.

Quando si lavora con complesse strutture dati, specie quando queste strutture sono generate a partire da dati offuscati, è estremamente importante utilizzare uno strumento in grado di rappresentare visivamente tali grafi. Io stesso ho perso alcune settimane dietro i problemi matematici che si nascondono dietro la visualizzazione dei grafi. Un esempio fra i tanti riguarda il problema di disporre i nodi in modo tale da minimizzare gli accavallamenti degli archi.

Non avevo però la pretesa di riscrivere da capo una libreria che disegnasse grafi e alberi in quanto ero sicuro che esistesse già qualcosa di pronto nel marasma del codice libero.

La risposta è iGraph. Fra tutte le librerie che ho visto e provato questa è sicuramente la più interessante. Il punto di forza di questa libreria consiste nel numero di piattaforme e linguaggi che supporta: C/C++, Python e anche Ruby più altre piattaforme di statistica. Inoltre, dando un occhiata alle API e alla documentazione, sembra molto semplice, intuitiva e ben tenuto.

Allora lo installo sfruttando i repository di Launchpad (ho utilizzato karmic anche se uso Sidux e pare che tutto funzioni bene). Scrivo un codicillo di prova e ho la brutta sorpresa:

Accidenti! La funzione principe del programma non è ancora stata implementata!? Non vi nascondo che ci sono rimasto malissimo. Anche perché era una libreria di cui avevo bisogno per visualizzare alcuni grafi di stato di piccoli progetti di prova di IA.

Pazienza. Guarderò il codice e cercherò di contattare gli sviluppatori per sapere come procede l’implementazione di questa funzionalità. Magari posso dare anche una mano. Alla fine è questo il bello del software libero.

UPDATE:

HO RISOLTO IL PROBLEMA! Ora funziona bene anche la visualizzazione. Vi aggiornerò a breve!

SEGUIMI SU TWITTER

A partire da qualche mese è possibile che voi utenti Eclipse vi siate trovati nella condizione di non riuscire più ad utilizzare Eclipse per aggiornamenti, scaricare plugin e, più in generale, accedere alla rete.

Il problema è dovuto ad un bug conteso fra Debian (che potrebbe essersi propagato anche alle sue derivate come Ubuntu) e la virtual machine Java. In pratica c’è un gran casino fra IPv4 e IPv6 che ha come conseguenza il completo isolamento della rete di alcuni programmi Java.

Per risolvere basta lanciare il programma con i parametri

E Eclipse tornerà a funzionare come prima.

PS: I parametri che vi ho segnalato con buona probabilità funzionano anche per altri programmi soggetti allo stesso bug.

Lo so. Sono discorsi pro-flame che hanno stancato tutti. Anche me. Ma a quanto pare qualcuno non ha capito a fondo la differenza fra le due librerie e crede che OpenGL sia il solito fratello sfigato delle DirectX che mamma microsoft ci offre con tanto spirito di carità.

Non starò a tediarvi con “è meglio X perché” o “quanto fa schifo Y”. Vi sparerò di seguito qualche dato preso da libri attendibili e non trarrò conclusioni. Queste spettano a voi.

Per prima cosa va puntualizzato che comparare OpenGL con le DirectX è come comparare KDE con OpenSolaris. Le OpenGL infatti sono puramente librerie 3D mentre le DirectX offrono anche funzionalità collegate al mondo dei videogame quali

DirectDraw – Libreria per la grafica 2D
Direct3D – Libreria per la grafica 3D
DirectSound – Libreria per la riproduzione e la manipolazione di effetti sonori
DirectInput- Libreria per la gestione dell’Input (tastiera, mouse, joystick etc.)
DirectShow – Libreria per la riproduzione di file video
DirectPlay – Libreria per il networking

Per OpenGL invece dobbiamo accoppiare librerie specifiche separate e librerie ausiliarie come GLUT e simili. Le comparazioni fra OpenGL e DirectX, quindi, le farò solamente rispetto a Direct3D.

Iniziamo con una tabella che comparativa delle features

Da notare il supporto allo Stereo Rendering che serve a creare video 3D compatibili con gli occhialetti tanto di moda nell’ultimo periodo. Ora non so se questa tabella è aggiornatissima ma è comunque indicativa.

Altra questione. Le DirectX hanno un accesso diretto all’hardware su Windows mentre le OpenGL si devono arrangiare con le WGL. Questo influisce negativamente sulle OpenGL su Windows ed è uno dei motivi per cui per i giochi windows si preferiscono le DirectX. Il motivo di questa discriminazione è nella chiusura del codice di Windows, ovviamente. Inoltre, astutamente, le funzionalità di accesso all’hardware (driver) e quelle di API sono inseparabili. Ciò significa che un programma che sfrutta OpenGL non può appoggiarsi a DirectX per avere una via preferenziale verso la scheda video, infatti tale via è utilizzabile solamente se il canale viene aperto dalle API Direct3D.

Inoltre le prestazioni fra Direct3D e OpenGL sono del tutto comparabili. A seconda dei test prevale una o prevale l’altra. Quindi siamo in totale parità.

Infine la semplicità di programmazione pende a favore delle OpenGL. Per prima cosa perché sono scelte universalmente come libreria didattica e in secondo luogo perché sfrutta la semplice interfaccia a “chiamata di funzione” a differenza dell’uso di COM per DirectX.

Non dico che la tecnologia COM sia peggio della chiamata di funzione. Ma sicuramente richiede un approccio diverso e quindi una curva di apprendimento più ripida rispetto al sistema “standard” usato da C/C++ e che quindi tutti conoscono già.

Quasi dimenticavo di aggiungere che le OpenGL sono disponibili ovunque, per qualunque architettura e dispositivo, mentre le DirectX sono vincolate a Microsoft.

Ci sarebbe altro da dire ma poi diventerei noiso. Penso che queste cose servano a fare un po di chiarezza.

BOINC (Berkeley Open Infrastructure for Network Computing) è uno dei più solidi e affermati sistemi di grid-computing. Con il termine grid-computing si è soliti indicare quell’architettura di calcolo nel quale un problema viene scomposto in sotto-unità chiamate e work-unit che vengono analizzati da computer diversi appartenenti ad una rete (sia locale che globale).

Boinc è utilizzato da molti gruppi di ricerca e associazioni per condurre ricerche che necessitano di un elevato tempo di calcolo. La partecipazioni a tali ricerche è totalmente volontaria e aperta a chiunque. E’ inoltre un ottimo modo per non lasciare andare sprecata la potenza di calcolo nei momenti in cui lasciamo inutilizzato il pc. Questo aspetto. insieme alla partecipazione volontaria, sono così importanti in Boinc che spesso sono stati definiti come screensaver-computing o volounteers-computing.

Il programma esiste per ogni sistema, sia Windows che Linux, ed è composto da due componenti:

• boinc-client : che contiene il client vero e proprio
• boinc-manager: che contiene l’interfaccia per interagire e per configurare il client

I progetti a cui partecipiamo, inoltre, installano uno screensaver che mostra alcuni dati sulla computazione in corso, ma solo su windows. Questa feature è sfortunatamente  ancora assente da GNU/Linux e non so per quanto ancora lo sarà.

Per installare Boinc dobbiamo installare le due componenti:

# apt-get install boinc-manager boinc-client

A questo punto il client è già pronto, non resta che aprire il Boinc Manager (che trovate nel menù delle applicazioni) e aggiungere il progetto che volete.

Io ad esempio sono molto attivo su Rosetta@home che produce risultati sulla struttura tridimensionale delle proteine.

C’è però un bug almeno nella mia installazione: la funzionalità che mette in pausa automaticamente la computazione quando l’utente è attivo non mi funziona bene. Devo quindi attivare e sospendere manualmente. Non è un granché ma il bug è noto e segnalato. Speriamo in una rapida correzione.

Me lo hanno chiesto in alcuni: quale plugin usi per colorare la sintassi del codice? La risposta è semplice: CodeColorer. Ho provato un paio di plugin analoghi ma solo quest’ultimo era semplice da usare, altamente personalizzabile e con un numero molto ampio di linguaggi supportati (come sapete ho necessità di colorare la sintassi Scheme).

Code colorer potete scaricarlo da qui oppure installarlo dal menù plugin direttamente da WordPress.

Il funzionamento è immediato, basta aggiungere un tag prima e dopo il codice che volete inserire specificando quale linguaggio utilizzare. Queste ed altre informazioni per l’utilizzo sono disponibile nella pagina che ho linkato.

C’è solo un “problema” che ho individuato e che penso sia causato da qualche impostazione sbagliata che ho: WordPress infatti rimuove le indentazioni del testo ed è quindi necessario racchiudere il codice comprensivo dei tag di CodeColorer all’interno dei tag <pre>.

Io lo sto utilizzando nel riassetto generale del blog e mi ci sto trovando bene. Spero possa tornarvi utile.

Il passaggio da KDE 3.5 a KDE 4 è sempre più comleto. Un po in ritardo rispetto ad altri pezzi grossi (ad esempio come Amarok, che ha raggiunto la completezza della 1.4 in queste settimane, e Digikam) la versione definitiva di Kdevelop è quasi in arrivo. Su debian possiamo già godere di queste anticipazioni installando la versione beta dal ramo experimental.

Kdevelop per chi non lo sapesse è un ottimo IDE multilinguaggio per KDE. Offre integrazione con numerosi tool di sviluppo e numerosi linguaggi quali Python, Ruby, C++, C, C#, Java e molti altri.

La versione sebbene beta sembra del tutto usabile. La sto utilizzando da qualche giorno e sembra funzionare bene. Certo, a volte si sente la mancanza di qualche funzione a cui si era abituati con la 3.5 ma per il resto rimane un ottimissmo IDE.

Molte features sono state aggiunte ed altre verranno presto implementate.

Qui trovate una lista esauriente delle features ed un confronto fra la versione 3.5 e quest’ultima.

http://www.kdevelop.org/mediawiki/index.php/KDevelop_4/KDev3_KDev4_comparison_table

Adesso restiamo solo ad aspettare per la versione finale di Kdevelop e per la nuova versione di K3b. Una volta arrivati questi due software e con l’avvento di KDE 4.4 potremo forse finalmente dire che KDE è finalmente completo.