martedì 16 dicembre 2008

Misurare le prestazioni di un sistema operativo.

Questo articolo del blog ufficiale del team di Windows 7 e' il perfetto viatico per iniziare a capire l'argomento del benchmarking di un sistema operativo.

Misurare qualcosa e' un processo molto piu' complesso di quello che si possa pensare. Nella vita quotidiana siamo abituati a usare metodi di misura tra i piu' disparati. Misuriamo il nostro peso corporeo, misuriamo gli anni trascorsi da quando siamo nati, misuriamo il costo delle cose, misuriamo le prestazioni dei mezzi di trasporto, misuriamo aspetti fisici e non delle persone.

Sembra che si abbia a disposizione un "metro" per ogni cosa che vogliamo misurare. Ma se per alcune cose questo "metro" e' facilmente identificabile e utilizzabile, per molte altre cose non e' affatto cosi' scontato individuare cosa usare come parametro di confronto. Le misurazioni infatti si fanno per confronto. Non esiste il concetto assoluto di misura, ma solo relativo a qualcos'altro.

E cosi' finiamo ad esempio a voler misurare le prestazioni di un sistema operativo rispetto ad un altro, ma prima di poterlo fare forse bisognerebbe capire cosa andremo a misurare e soprattutto con che "metro" effettueremo queste misurazioni.

Nonostante la cosa non sia cosi' banale viene data per scontata da molti e si arriva al punto che c'e' chi pensa di poter misurare un intero sistema operativo utilizzando un singolo "indice di velocita'".

Persino un'auto (che e' infinitamente meno complessa di un sistema operativo dal punto di vista delle funzionalita' offerte) non si riesce a misurare con un solo indice. La potenza? La velocita' massima? Il tempo sul giro? Una media ponderata dei valori precedenti? Dovendo prendere una sola misurazione quale prendiamo? Qualunque si scelga si finisce per dare un'informazione molto limitata dell'auto e sostanzialmente poco utile per non dire del tutto inutile dato che nel momento in cui si andra' a scegliere un'auto da acquistare bisognera' avere a propria disposizione ben piu' di un singolo parametro.

La stessa cosa e' valida per la maggior parte delle cose che misuriamo. Se vi dico che Paolo pesa 80 Kg. e Marco ne pesa 85 Kg. e aggiungo che uno dei due e' grasso, sapreste individuare quale dei due senza sapere quanto sono alti? Di per se' il peso preso singolarmente non e' sufficiente a fare una qualsiasi considerazione degna di nota.

I sistemi operativi forniscono centinaia di funzionalita' diverse tra loro e spesso non sono neppure funzionalita' utilizzabili direttamente dall'utente, ma presenti solo per poter essere utilizzate da programmi che ne fanno uso.
La valutazione di un OS richiedera' quindi di individuare almeno delle categorie di funzioni da misurare, non si puo' certo pensare che si possa dare una valutazione complessiva riducendo il tutto a un indice complessivo sia anche esso il risultato della somma di N indici diversi.
Questo perche' sapere la somma non dice nulla sul valore individuale dei singoli indici che la compongono.

Quindi abbiamo stabilito che misurare un sistema operativo e' una operazione complessa che richiede molti indici, ma non abbiamo ancora una precisa idea di come fare queste misurazioni.

Ci sono due approcci molto diversi:
- eseguire manualmente una serie di operazioni cronometrandone la durata.
- eseguire dei programmi che a loro volta eseguono in modo automatico una serie di operazioni e ne misurano la durata.

Il primo metodo e' quello che piu' si avvicina all'esperienza dell'utente.
Il secondo invece e' completamente diverso da quello che fa l'utente ma puo' sembrare a prima vista il metodo piu' rigoroso per effettuare una misurazione.

In realta' le cose sono ben piu' complesse di cosi'.
Il problema cardine della "misurazione" e' di non interferire col sistema che si sta misurando evitando di alterarne il risultato o per lo meno di interferire il meno possibile.

E qua gia' bisognerebbe iniziare a dubitare dei test che utilizzano script di automazione in quanto l'eseguzione dello script inevitabilmente interferisce col sistema.

Prendiamo l'esempio gia' citato di OfficeBench che sali' agli onori della cronaca quando venne usato per sentenziare che Vista era il 40% piu' lento di XP. Si tratta di una serie di script che automatizzano operazioni di Microsoft Office cercando di simulare l'attivita' quotidiana di un ipotetico utente.

Balza subito all'occhio che c'e' un errore di fondo in questo tipo di misurazione. Gli autori del tool di testing affermano che il tool e' in grado di misurare diverse versioni di Windows e di Office. Peccato pero' che per definizione stiano usando lo stesso metro per misurare cose diverse. Office 2007 e' profondamente diverso da Office 2003, ad esempio i comandi non sono piu' organizzati in menu' e sotto menu', ma sono disposti nel famoso Ribbon.
Ora un test di automazione non tiene assolutamente in conto il fattore accessibilita' di un comando. L'utente che vuole fare una stampa di un documento dovra' andare a cercare il comando e quindi eseguirlo, e a seconda della versione di Office questa operazione puo' richiedere piu' o meno tempo a seconda di dove e' posizionato il comando e di quanti click l'utente debba fare.
Un tool automatico sa gia' dove andare e puo' eseguire la sequenza di operazioni ad una velocita' che e' del tutto diversa da quella dell'utente in quanto non ha bisogno di attendere il feedback visivo tra un click e il successivo.
Office 2007 potrebbe anche avere delle prestazioni di eseguzione del singolo comando piu' lento di Office 2003 ma potrebbe avere una UI che rende piu' rapido per l'utente identificare cosa e dove cliccare.
Il tool potrebbe sentenziare che il comando di stampa e' piu' rapido su Office 2003 con XP, ma poi nella realta' l'utente potrebbe impiegare piu' tempo rispetto a Office 2007 con Vista.

E questo tipo di concetto si applica sostanzialmente a qualunque altro aspetto che riguarda i tool che automatizzano l'interfaccia utente attraverso script.

C'e' poi un altro aspetto, il tool OfficeBench usa OleDB per creare istanze degli oggetti di Office e quindi eseguirne comandi. Ma nella realta' l'utente non fa mai questo tipo di operazione, non apre Word invocando automatismi di OleDB, lo fa avviando l'applicativo in modo interattivo e via dicendo.

Quindi ammesso anche che le misurazioni e i confronti tra XP e Vista sia stati effettuati limitando al massimo l'interferenza col sistema, il dato finale che afferma che Vista e' piu' lento di XP del 40% che cosa comporta per l'utente finale?
Che le applicazioni si avviano il 40% piu' lentamente sotto Vista? No.
Che eseguire singoli task richieda il 40% di tempo in piu'? No.
Che l'impiegato che usa XP finisca il suo lavoro alle 5 del pomeriggio e che l'impiegato che deve fare le stesse identiche cose usando Vista finisca qualche ora dopo? No.

Ma allora per l'utente cosa significa sapere che Vista e' il 40% piu' lento di XP? Sostanzialmente nulla.
Quello che e' stato misurato non e' quanto Vista sia piu' lento di XP ma solo quanto un insieme di script e di comandi automatizzati risulti piu' lento su Vista rispetto a XP, ma nulla ci dice su cosa o come o perche' risulti piu' lento su Vista. Quindi alla fine non hanno misurato le performance del sistema operativo, ma solo quelle del loro programma.

Se qualcuno dubita del fatto che non sia stato misurato il sistema operativo penso che basti questa considerazione per convincerlo: su Vista c'e' Windows Defender attivo di default, su XP no. Se eseguo un tool che crea file automaticamente per poi effettuare dei test di apertura salvataggio degli stessi attraverso Office comandato via OleDB molto probabilmente Windows Defender interviene pesantemente in quanto individua un eseguibile che sta effettuando operazioni potenzialmente pericolose, mentre quando le stesse operazioni sono effettuate manualmente dall'utente il fattore Windows Defender incide percentualmente in modo meno significativo per non dire trascurabile.

Quindi c'e' qualcosa che si puo' misurare e confrontare senza cadere in questi errori?
Si certamente, ma la metrica e' piuttosto complessa.
Prendiamo ad esempio il tempo impiegato per effettuare il boot del sistema.
Questo valore e' condizionato da molti fattori, sia legati all'hardware che al software. Cambiera' quindi a seconda del tipo di CPU e della quantita' di ram, dal numero di periferiche presenti, da quanti applicativi/servizi sono stati installati e cosi' via. Puo' benissmo capitare che un sistema operativo che risulta piu' veloce all'avvio con una certa configurazione, non lo sia piu' su un'altra.

Questo e' ad esempio dimostrato in modo macroscopico con i test sulle prestazioni delle schede video. Li' almeno si usano, oltre ai programi di benchmark, anche i giochi che poi l'utente andra' ad usare. E ormai chiunque segua questo tipo di confronti sa benissimo che una scheda video che sulla carta e' molto piu' performante di un'altra puo' poi nella realta' produrre meno frame per second di una meno performante a seconda del gioco o della CPU o della versione del driver e via dicendo.

Se non e' possibile usare un singolo indice per identificare le prestazioni delle schede video (che sono solo una parte del computer) c'e' davvero qualcuno che puo' seriamente sostenere che sia possibile dare una valutazione seria di un sistema operativo usando un tool che produce un singolo numero?

Tutto questo lo dico in previsione degli articoli sulle prestazioni di Windows 7 che gia' stanno iniziando ad uscire e che diventeranno una vera e propria piaga mondiale quando verra' rilasciata la beta ufficiale ;-)

martedì 2 dicembre 2008

Windows 7: rimozione integrata dischi hot swap.

Altra chicca che vi svelo in anteprima mondiale (beh magari qualcuno l'aveva gia' scritto da qualche parte ma io non l'ho trovato google-ando): con Windows 7 la rimozione di dischi SATA hot swap e' facile tanto quanto la rimozione di un disco USB, infatti sono elencati insieme alle periferiche USB e quindi non c'e' piu' bisogno di usare utility terze parti o linee di comando o il Device Manager, basta tasto destro sull'icona del disco e poi selezionare la voce "Safely Remove".