<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> <HEAD> <TITLE>Linux Benchmarking HOWTO: Procedure di benchmarking e interpretazione dei risultati </TITLE> <LINK HREF="Benchmarking-HOWTO-3.html" REL=next> <LINK HREF="Benchmarking-HOWTO-1.html" REL=previous> <LINK HREF="Benchmarking-HOWTO.html#toc2" REL=contents> </HEAD> <BODY> <A HREF="Benchmarking-HOWTO-3.html">Avanti</A> <A HREF="Benchmarking-HOWTO-1.html">Indietro</A> <A HREF="Benchmarking-HOWTO.html#toc2">Indice</A> <HR> <H2><A NAME="s2">2. Procedure di benchmarking e interpretazione dei risultati </A></H2> <P> <P>Qualche raccomandazione semi-ovvia <OL> <LI>Prima di tutto, <B>identificare i propri obiettivi nel benchmarking</B>. Cosa si sta esattamente tentando di testare? In che modo il processo di benchmarking ci aiuterà nel prendere una decisione? Quanto tempo e risorse si è intenzionati ad impiegare nei propri sforzi di benchmarking? </LI> <LI><B>Usare strumenti standard</B>. Usare una versione recente ma stabile del kernel, le attuali gcc e libc ed un banco di test standard. In breve usare l'LBT (vedere più avanti) </LI> <LI>Dare una <B>completa descrizione</B> del setup (vedere il modulo LBT più avanti). </LI> <LI>Provare a<B> isolare una singola variabile</B>. Il Benchmark comparativo è più informativo del benchmark "assoluto"<B>. Non lo ripeterò mai abbastanza.</B></LI> <LI><B>Verificare i propri risultati</B>. Fare i propri benchmark più di una volta e verificare le variazioni nei risultati, se ce ne sono. Variazioni inspiegate invalideranno i risultati. </LI> <LI>Se si pensa che i propri sforzi nel benchmarking produrrano informazioni utili, <B>condividerle</B> con la comunità Linux in una maniera <B>precisa</B> e <B>concisa</B>. </LI> <LI>Per favore <B>ci si dimentichi dei BogoMips</B>. Mi sono ripromesso di implementare un giorno un ASIC davvero veloce con il ciclo dei BogoMips dentro. Poi vedremo quello che vedremo! </LI> </OL> <P> <H2><A NAME="ss2.1">2.1 Capire le scelte di benchmarking </A> </H2> <P> <H3>Benchmark sintetici contro applicazioni</H3> <P> <P>Prima di spendere un bel po' di tempo nei processi di benchmarking va fatta una scelta di base fra benchmark "sintetici" e "applicazioni" benchmark. <P>I benchmark sintetici sono spesso progettati per misurare le performance di una singola componente di un sistema, di solito impiegando questa componente alla sua massima capacità. Un esempio ben conosciuto di benchmark sintetico è la <B>Whetstone</B> suite, originariamente programmata nel 1972 da Harold Curnow in FORTRAN (o era ALGOL?) e ancora largamente usata ai giorni nostri. La suite Whetstone misurerà le prestazioni dell'unità in virgola mobile di una CPU. <P>La maggiore critica che può essere fatta ai benchmark sintetici, è che non rappresentano le prestazioni di un sistema nelle situazioni della vita reale. Prendiamo ad esempio la suite Whetstone: il ciclo principale è molto corto e entrerà facilmente nella cache primaria di una CPU, tenendo la pipeline dell'unità in virgola mobile costantemente riempita in modo tale da esercitare l'FPU alla sua massima velocità. Non possiamo davvero criticare la Whetstone suite se ricordiamo che è stata programmata più di 25 anni fa (e le date della progettazione risalgono ancora a prima!), ma noi dobbiamo essere sicuri di interpretare i suoi risultati con attenzione, quando ci troviamo a testare un moderno microprocessore. <P>Un altro punto molto importante circa i benchmark sintetici è che, in teoria, loro ci possono dire qualcosa rispetto ad uno <B>specifico</B> aspetto del sistema che stiamo provando, indipendentemente da tutti gli altri aspetti: un benchmark sintetico per il troughtput di una scheda Ethernet può avere lo stesso o similare risultato che esso sia effettuato su un 386SX-16 con 4MB di Ram o su un Pentium 200 MMX con 64 MB di RAM. Altrimenti, un test potrebbe misurare le prestazioni generali della combinazione di CPU/Scheda Madre/Bus/Scheda Ethernet/Sottosistema di memoria/DMA: non molto utile dato che il cambio del microprocessore causerebbe un impatto molto più grande rispetto al cambio della scheda di rete Ethernet (questo, ovviamente, prendendo per scontato che stiamo usando la stessa combinazione di kernel e driver, cosa che potrebbe causare una variazione ancora più grande)! <P>Infine uno degli errori più comuni è fare la media di alcuni benchmark sintetici e affermare che quella media è una buona rappresentazione della vita reale per ogni dato sistema. <P>Questo è un commento dei benchmark sull'unità in virgola mobile riproposto con il permesso del sito web della Cyrix Corp.: <P> <BLOCKQUOTE> <EM>"Una unità in virgola mobile (FPU) accelera il software progettato per usare il calcolo matematico in virgola mobile: tipicamente programmi CAD, fogli elettronici, giochi 3D e applicazioni di disegno. Fatto sta, che oggi molte tra le più popolari applicazioni per pc fanno uso di entrambe le istruzioni in virgola mobile e intere. Come risultato, Cyrix ha scelto di enfatizzare il "parallelismo" nella progettazione dei processori 6x86 per velocizzare le prestazioni dei software che mischiano questi due tipi di istruzioni.</EM> </BLOCKQUOTE> <P> <BLOCKQUOTE> <EM>Il modello di eccezione del floating point x86 permette alle istruzioni intere di iniziare e completarsi mentre un istruzione in virgola mobile è ancora in elaborazione. In contrasto, una seconda istruzione in virgola mobile non può iniziare la sua esecuzione mentre una precedente istruzione è ancora in esecuzione. Per rimuovere questo limite alle prestazioni, il 6x86 può specularmente iniziare fino a quattro istruzioni in virgola mobile alla FPU nel chip mentre continua ad iniziare ed eseguire istruzioni intere. Per esempio, in una sequenza di codice con due istruzioni in virgola mobile (FLT) seguite da sei istruzioni intere (INT) seguite da due FLT, il processore 6x86 può inizare ad eseguire tutte e dieci le istruzioni con l'appropriata unità di esecuzione prima ancora del completamento dell'esecuzione del primo FLT. Se nessuna delle istruzioni fallisce (il caso tipico), l'esecuzione continua con entrambe le unità intera ed a virgola mobile che completano in parallelo le istruzioni. Se uno degli FLT fallisce (caso atipico), la capacità di esecuzione speculativa del 6x86 permette che lo stato del processore sia restaurato in una maniera che sia compatibile con il modello di eccezione dell'x86.</EM> </BLOCKQUOTE> <P> <BLOCKQUOTE> <EM>L'esame dei test di benchmark rivela che i benchmark sintetici dell'unità in virgola mobile usano un 'code stream' in pura virgola mobile che non si trova nelle applicazioni del mondo reale. Questo tipo di benchmark non trae vantaggio dalle possibilità di esecuzione speculativa dei processori 6x86. Cyrix crede che i benchmark non sintetici basati sulle applicazioni del mondo reale riflettano meglio le attuali prestazioni che gli utenti otterranno. Le applicazioni del mondo reale contengono funzioni intere e a virgola mobile miste, e quindi beneficieranno della capacità di esecuzione speculativa del 6x86"</EM> </BLOCKQUOTE> <P>Così la recente moda nel benchmarking è di scegliere applicazioni comuni ed usare queste per provare le prestazioni di un computer completo. Per esempio, <B>SPEC</B>, l'organizzazione no-profit che ha progettato le ben conosciute suite di benchmark SPECINT e SPECFP ha lanciato un progetto per una nuova suite di benchmark applicativo. Ma ancora è molto difficile che certi benchmark commerciali includeranno mai codice Linux. <P>Ricapitolando, i benchmark sintetici sono validi fino a che si capiscono i loro obiettivi e le loro limitazioni. I benchmark applicativi rifletteranno meglio le prestazioni di un computer nel suo insieme, ma nessuno è disponibile per Linux. <P> <H3>Benchmark di alto livello contro quelli di basso livello</H3> <P> <P>I benchmark di basso livello misureranno direttamente le prestazioni dell'hardware: il clock del processore, i cicli di DRAM e SRAM, il tempo medio di accesso del disco rigido, la latenza, il tempo di stepping da traccia a traccia, ecc ... Questo può essere utile nel caso si compri un sistema e si vuole vedere con quali componenti è stato costruito, ma una maniera migliore di controllare questo sarebbe di aprire il case, elencare i numeri di serie di tutti i componenti, e poi ottenere le caratteristiche per ogni componente sul web. <P>Un altro uso dei benchmark di basso livello è di controllare che il driver del kernel sia correttamente configurato per una specifica componente hardware: se si hanno le caratteristiche dichiarate dal produttore per quel componente si possono confrontare i risultati dei benchmark di basso livello con quelle ... <P>I benchmark di alto livello tengono maggiormente conto delle prestazioni della combinazione di hardware/driver e sistema operativo per un aspetto specifico di un sistema, per esempio, le prestazioni di input&output, o anche le prestazioni di una singola applicazione rispetto alla combinazione di hardware/driver e sistema operativo, p.es. un benchmark di Apache su sistemi differenti. <P>Ovviamente tutti i benchmark di basso livello sono sintetici. I benchmark di alto livello possono essere sintetici o applicativi. <P> <H2><A NAME="ss2.2">2.2 Benchmark standard disponibili per Linux</A> </H2> <P> <P>A mio modesto avviso un semplice test che ognuno può fare nell'aggiornare qualsiasi componente del suo sistema Linux è di lanciare la compilazione del kernel prima e dopo l'aggiornamento di hardware e/o software e confrontare i tempi di compilazione. Se tutte le altre condizioni sono tenute costanti allora il test è valido come una misura delle prestazioni nella compilazione e si può essere tranquilli nel dire che: <BLOCKQUOTE> "Cambiare A in B porta ad un miglioramento delle prestazioni di x % nella compilazione del kernel di Linux sotto tale e tali condizioni". </BLOCKQUOTE> <P>Ne più, ne meno! <P>Dal momento che la compilazione è un processo molto usuale sotto linux, e dal momento che esercita molte funzioni che vengono esercitate dai normali benchmark (eccetto le prestazioni in virgola mobile), esso costituisce un test <B>individuale</B> abbastanza buono. In molti casi, comunque, i risultati da test a test non possono essere riprodotti da altri utenti Linux perché ci sono variazioni nelle configurazioni hardware/software e così questo tipo di test non può essere usato come "unità campione" per confrontare sistemi dissimili (a meno che non ci accordiamo su un kernel standard da compilare - vedi più avanti). <P>Sfortunatamente, non ci sono strumenti di benchmarking specifici per Linux, eccetto forse i Byte Linux Benchmarks che sono una versione leggermente modificata dei Byte Unix Benchmarks che datano Maggio 1991 (Trasposizione Linux di Jon Tombs, autori originali Ben Smith, Rick Grehan e Tom Yager). <P>C'è un <A HREF="http://www.silkroad.com/bass/linux/bm.html">sito web</A> centrale per i Byte Linux Benchmarks. <P>Una versione migliorata e aggiornata dei Byte Unix Benchmarks è stata messa assieme da David C.Niemi. Questa è chiamata UnixBench 4.01 per evitare confusioni con le versioni precedenti. Questo è ciò che David scrisse circa i suoi mods: <BLOCKQUOTE> <EM>"Gli originali e leggermente modificati BYTE Unix benchmarks sono rotti in un numero tale di modi che fanno di loro un indicatore stranamente non stabile delle performance del sistema. Intenzionalmente ho fatto sembrare i miei valori indice molto differenti per evitare confusioni con i vecchi benchmarks." </EM> </BLOCKQUOTE> <P>David ha messo su una mailing list basata su majordomo per discutere del benchmark su Linux e sistemi operativi concorrenti. Per partecipare si invii "subscribe bench" nel corpo di un messaggio a <A HREF="mailto:majordomo@wauug.erols.com">majordomo@wauug.erols.com</A>. Il Washington Area Unix User Group è anche in procinto di mettere su un <A HREF="http://wauug.erols.com/bench "> Sito Web </A>per i benchmark Linux. <P>Inoltre recentemente, Uwe F. Mayer, <A HREF="mailto:mayer@math.vanderbilt.edu">mayer@math.vanderbilt.edu</A> ha portato la BYTE Bytemark suite in Linux. Questa è una moderna suite attentamente assemblata da Rick Grehan del BYTE Magazine per testare CPU, FPU e memoria su un moderno computer (questi sono benchmark strettamente orientati alle prestazioni del processore, né l'I/O né le performance del sistema sono tenute in conto). <P>Uwe ha anche messo online un <A HREF="http://math.vanderbilt.edu:80/~mayer/linux/bmark.html">Sito Web</A> con un database di risultati per la sua versione dei Linux BYTEmark benchmarks. <P>Mentre si cerca per benchmark sintetici per Linux, si noterà che sunsite.unc.edu ha disponibili diversi strumenti di benchmarking. Per testare la velocità relativa dei server X e delle schede grafiche, la suite xbench-0.2 di Claus Gittinger è disponibile da sunsite.unc.edu, ftp.x.org e altri siti. Xfree86.org si rifiuta (saggiamente) di rendere disponibile o raccomandare alcun benchmark. <P>L' <A HREF="http://www.goof.com/xbench/">XFree86-benchmarks Survey</A> è un sito web con database di risultati di x-bench. <P>Per il troughput puro I/O dei dischi il programma hdparm (incluso con molte distribuzioni, altrimenti disponibile da sunsite.unc.edu) misurerà la velocità di trasferimento se avviato con le opzioni -t e -T. Ci sono molti altri strumenti liberamente disponibili su Internet per provare vari aspetti delle prestazioni di un sistema Linux. <P> <H2><A NAME="ss2.3">2.3 Collegamenti e riferimenti</A> </H2> <P> <P>comp.benchmarks.faq di Dave Sill è ancora il punto di riferimento standard per il benchmarking. Non è specifico per Linux, ma la lettura è raccomandata per chiunque si voglia impegnare seriamente nel benchmarking. È disponibile da un grande numero di FTP e siti web ed elenca <B>56 differenti benchmark</B>, con links agli FTP o siti web che li rendono disponibili. Alcuni dei benchmark listati sono commerciali (SPEC per esempio). <P>Quindi non andrò oltre nell'esaminare ognuno dei benchmark menzionati in comp.benchmarks.faq, ma c'è almeno una suite di basso livello di cui voglio parlare: la <A HREF="http://reality.sgi.com/lm/lmbench/lmbench.html">lmbench suite</A>, di Larry McVoy. Citando David C. Niemi: <P> <BLOCKQUOTE> <EM>"Linus e David Miller la usano molto perché fa molte utili misurazioni di basso livello e può anche misurare il throughput di rete e la latenza se si hanno 2 sistemi da testare.</EM> </BLOCKQUOTE> <P>Un <A HREF="ftp://ftp.nosc.mil/pub/aburto">Sito FTP</A> piuttosto completo per benchmark <B>liberamente</B> disponibili è stato messo su da Alfred Aburto. La Whetstone suite usata nell'LBT può essere trovata a questo sito. <P>C'è una <B>FAQ in più parti di Eugene Miya</B> che viene postata regolarmente su comp.benchmarks; è un eccellente punto di riferimento. <P> <HR> <A HREF="Benchmarking-HOWTO-3.html">Avanti</A> <A HREF="Benchmarking-HOWTO-1.html">Indietro</A> <A HREF="Benchmarking-HOWTO.html#toc2">Indice</A> </BODY> </HTML>
