<!-- LinuxDoc file was created by LyX 0.10 (C) 1995 1996 by Matthias Ettrich --> <!-- Export filter
v0.5 by Pascal Andre                                --> 
<!doctype linuxdoc system>

<article OPTS="italian">

<title>Linux Benchmarking HOWTO
<author>di André D. Balsa, <htmlurl url="mailto:andrewbalsa@usa.net"
name="andrewbalsa@usa.net"> 
<date>v0.12, 15 agosto 1997

<abstract> 
Il Linux Benchmarking HOWTO discute alcune questioni relative al
benchmarking ("misura delle prestazioni") di sistemi Linux e presenta
un semplice strumento di benchmarking ed un modulo a questo associato
che consente di fornire informazioni significative per il benchmarking
in un paio d'ore. Probabilmente aiuterà anche a diminuire la quantità
di articoli inutili in comp.os.linux.hardware ...
Traduzione di Gianluca Pecoraro (<htmlurl
url="mailto:atahualpa@altavista.net" name="atahualpa@altavista.net">). 
</abstract>
<toc>
<sect>Introduzione
<p>

<em>"What we cannot speak about we must pass over in silence."</em> <quote><em>Ludwig
Wittgenstein (1889-1951), filosofo austriaco</em> </quote>

Benchmarking significa <bf>misurare</bf> la velocità con la quale un
computer esegue un processo, in una maniera tale da consentire il
confronto tra differenti combinazioni di hardware e software. 
Ciò <bf>non</bf> include la facilità, l'estetica, considerazioni
ergonomiche o qualsiasi altro giudizio soggettivo.

Il Benchmarking è un processo tedioso e ripetitivo e necessita
dell'attenzione ai dettagli. Molto spesso i risultati non sono quelli
che ci si aspettava, e sono soggetto di interpretazione (che
attualmente può essere la parte più importante di una procedura di
benchmarking).

Infine il benchmarking implica fatti e dati, non opinioni e
approssimazioni.

<sect1>Perché il benchmarking è così importante?   
<p>

Oltre alle ragioni spiegate nel BogoMips Mini-HOWTO (sezione 7,
paragrafo 2), ci si trova a volte a confrontarsi con un budget
limitato e un minimo di prestazioni richieste per il suo sistema
Linux. In altre parole, quando ci si pongono le seguenti domande:  
<itemize>
<item>Come massimizzo le prestazioni per un dato budget?  
<item>Come riduco i costi per un dato livello minimo di prestazioni?  
<item>Come ottengo il miglior rapporto prezzo/prestazioni (entro un
dato budget o una data richiesta di prestazioni?)
</itemize>

Si dovrà esaminare, confrontare e/o produrre benchmark. Minimizzare i
costi senza un tetto minimo di prestazioni richiesto di solito implica
il mettere assieme una macchina con rimasugli (quel vecchio 386SX-16
che sta da qualche parte nel garage andrà bene) e non richiede
benchmark, e massimizzare le prestazioni senza un limite di costi non
è una situazione realistica (a meno che non si voglia mettere un
sistema Cray nel proprio soggiorno - gli alimentatori rivestiti in
pelle attorno sembrerebbero simpatici, no?) 

Il benchmarking di per se è senza senso, una perdita di tempo e soldi;
ha solo senso quando è parte di un processo di decisione, p.es. se si
deve fare una scelta tra due o più alternative.

Di solito un altro parametro nel processo di decisione è il
<bf>costo</bf>, ma potrebbe anche essere la disponibilità, il
servizio, la compatibilità, decisioni strategiche o altre
caratteristiche misurabili e razionali di un computer. Quando si
confrontano, p.es. le prestazioni di differenti versioni del kernel di
linux, la <bf>stabilità</bf> è quasi sempre più importante della
velocità.

<sect1>Considerazioni non valide per il benchmarking<p>

Spesso si leggono nei newsgroup e nelle mailing list, sfortunatamente:
<enum>
<item>Reputazione del costruttore (non misurabile e senza senso).
<item>Quote di mercato del costruttore (senza senso e irrilevanti).  
<item>Parametri irrazionali (p.es. la superstizione o il pregiudizio:
compreresti un processore etichettato 171717ZAP e colorato di rosa?) 
<item>Valori percepiti (senza senso, non misurabili e irrazionali). 
<item>Presenza di una forte campagna pubblicitaria: questo è uno dei peggiori,
penso. Io personalmente sono cresciuto con i logo "XXX inside" o
"kkkkkws compatibile" (ora "aaaaaPowered è entrato a far parte della
truppa - chi sarà il prossimo ?). A mio modesto avviso, i miliardi di
dollari spesi in queste campagne sarebbero meglio utilizzati dai team
di ricerca nel progetto di processori nuovi, più veloci, (economici :-)
senza-bug . Nessuna massiccia campagna pubblicitaria potrà rimuovere
un bug nel coprocessore in virgola mobile di un nuovo processore che
hai appena montato sulla tua scheda madre, ma il cambio con un
processore riprogettato lo farebbe.
<item>Le opinioni del tipo "Tu hai per quello che paghi" sono solo
quello: opinioni. Fornite i fatti per favore.  
</enum>

<sect>Procedure di benchmarking e interpretazione dei risultati <p> 

Qualche raccomandazione semi-ovvia 
<enum>
<item>Prima di tutto, <bf>identificare i propri obiettivi nel
benchmarking</bf>. 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?  
<item><bf>Usare strumenti standard</bf>. 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) 
<item>Dare una <bf>completa descrizione</bf> del setup (vedere il modulo
LBT più avanti).  
<item>Provare a<bf> isolare una singola variabile</bf>. Il Benchmark
comparativo è più informativo del benchmark "assoluto"<bf>.  Non lo
ripeterò mai abbastanza.</bf>
<item><bf>Verificare i propri risultati</bf>. Fare i propri benchmark
più di una volta e verificare le variazioni nei risultati, se ce ne
sono. Variazioni inspiegate invalideranno i risultati.  
<item>Se si pensa che i propri sforzi nel benchmarking produrrano
informazioni utili, <bf>condividerle</bf> con la comunità Linux in
una maniera <bf>precisa</bf> e <bf>concisa</bf>.  
<item>Per favore <bf>ci si dimentichi dei BogoMips</bf>. Mi sono ripromesso
di implementare un giorno un ASIC davvero veloce con il ciclo dei
BogoMips dentro. Poi vedremo quello che vedremo! 
</enum> 

<sect1>Capire le scelte di benchmarking 
<p>
<sect2>Benchmark sintetici contro applicazioni
<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.

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 <bf>Whetstone</bf> 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. 

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.

Un altro punto molto importante circa i benchmark sintetici è che, in
teoria, loro ci possono dire qualcosa rispetto ad uno
<bf>specifico</bf> 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)!

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. 

Questo è un commento dei benchmark sull'unità in virgola mobile
riproposto con il permesso del sito web della Cyrix Corp.:

<quote><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></quote> 

<quote><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></quote>

<quote><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></quote>

Così la recente moda nel benchmarking è di scegliere applicazioni
comuni ed usare queste per provare le prestazioni di un computer
completo. Per esempio, <bf>SPEC</bf>, 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.

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.

<sect2>Benchmark di alto livello contro quelli di basso livello
<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.

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 ...

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&amp;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. 

Ovviamente tutti i benchmark di basso livello sono sintetici. I
benchmark di alto livello possono essere sintetici o applicativi.

<sect1>Benchmark standard disponibili per Linux
<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: 
<quote>"Cambiare A in B porta ad un miglioramento delle prestazioni di
x &percnt; nella compilazione del kernel di Linux sotto tale e tali
condizioni".  </quote> 

Ne più, ne meno! 

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 <bf>individuale</bf> 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).

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).

C'è un <htmlurl url="http://www.silkroad.com/bass/linux/bm.html"
name="sito web"> centrale per i Byte Linux Benchmarks. 

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:  
<quote><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>
</quote> 

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
<url url="mailto:majordomo@wauug.erols.com"
name="majordomo@wauug.erols.com">.  
Il Washington Area Unix User Group è anche in procinto di mettere su
un <htmlurl url="http://wauug.erols.com/bench " name=" Sito Web ">per
i benchmark Linux.  

Inoltre recentemente, Uwe F. Mayer, <url url="mailto:mayer@math.vanderbilt.edu"
name="mayer@math.vanderbilt.edu"> 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). 

Uwe ha anche messo online un <htmlurl
url="http://math.vanderbilt.edu:80/~mayer/linux/bmark.html" name="Sito
Web"> con un database di risultati per la sua versione dei Linux 
BYTEmark benchmarks.

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. 

L'<htmlurl url="http://www.goof.com/xbench/" name="XFree86-benchmarks
Survey"> è un sito web con database di risultati di x-bench.  

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.

<sect1>Collegamenti e riferimenti
<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 <bf>56 differenti benchmark</bf>, con links agli FTP o siti web
che li rendono disponibili. Alcuni dei benchmark listati sono
commerciali (SPEC per esempio).

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 <htmlurl
url="http://reality.sgi.com/lm/lmbench/lmbench.html" name="lmbench
suite">, di Larry McVoy.  Citando David C. Niemi:

<quote><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> </quote>

Un <htmlurl url="ftp://ftp.nosc.mil/pub/aburto" name="Sito FTP">
piuttosto completo per benchmark <bf>liberamente</bf> disponibili è
stato messo su da Alfred Aburto. La Whetstone suite usata nell'LBT può
essere trovata a questo sito.

C'è una <bf>FAQ in più parti di Eugene Miya</bf> che viene postata
regolarmente su comp.benchmarks; è un eccellente punto di riferimento.

<sect>The Linux Benchmarking Toolkit (LBT)
<p>

Proporrò uno strumento base per testare sistemi Linux. Questa è una
versione preliminare di un Linux Benchmarking Toolkit, da essere
espansa e migliorata. Prendetela per come è, cioè una proposta. Se si
pensa che questa non sia una valida suite di test, si è invitati a
mandare una e-mail con le proprie critiche e saranno apportati i
cambiamenti e migliorie se possibile. Prima di entrare nell'argomento,
comunque, è consigliabile leggere questo HOWTO e i punti di
riferimento menzionati: critiche informate sono le benvenute, vuoto
criticismo no.

<sect1>Razionale 
<p>
Questo è solo il buonsenso:
<enum>
<item>Non dovrebbe prendere un giorno intero per andare. Quando si va
al benchmarking comparativo, nessuno vuole spendere giorni tentando di
immaginare il più veloce setup per un dato sistema. Idealmente
l'intero set di benchmark dovrebbe prendere circa 15 minuti per
completarsi su una macchina media. 
<item>Tutto il codice sorgente utilizzato per il programma deve essere
liberamente disponibile su internet per ovvie ragioni.
<item>I benchmark dovrebbero provvedere semplici indici che
rispecchino le performance misurate. 
<item>Ci dovrebbe essere un misto di benchmark sintetici e applicativi
<item>Ogni benchmark <bf>sintetico</bf> dovrebbe impiegare il relativo
sottosistema alla sua massima capacità. 
<item>I risultati dei benchmark <bf>sintetici non</bf> dovrebbero
essere unificati in un unico indice (che non rispetta l'intera idea
che c'è dietro i benchmark sintetici, con considerevole perdita di
informazioni).
<item>I benchmark applicativi dovrebbero consistere in processi
eseguiti comunemente in un sistema Linux 
</enum> 

<sect1>Selezione dei benchmark
<p>

Ho selezionato cinque differenti suite di benchmarking, tentando il
più possibile di eliminare overlap nei test:
<enum>
<item>Compilazione del Kernel 2.0.0 (configurazione di default) usando
gcc.
<item>Whetstone suite versione 10/03/97 (ultima versione di Roy Longbottom). 
<item>xbench-0.2 (con parametri di esecuzione veloce).
<item>UnixBench benchmarks versione 4.01 (risultati parziali).  
<item>BYTE Magazine's BYTEmark benchmarks beta release 2 (risultati
parziali).
</enum> 

Per i test 4 e 5, "(risultati parziali)" significa che non tutti i
risultati prodotti da questi benchmark vanno considerati.

<sect1>Durata dei test
<p>
<enum>
<item>Kernel 2.0.0, compilazione: da 5 a 30 minuti, dipende dalle
<bf>reali</bf> performance del sistema.   
<item>Whetstone: 100 secondi. 
<item>Xbench-0.2: &lt; 1 ora. 
<item>UnixBench benchmarks versione 4.01: approssimativamente 15
minuti.
<item>BYTE Magazine's BYTEmark benchmarks: approssimativamente 10
minuti.
</enum>

<sect1>Commenti
<p>
<sect2>Compilazione Kernel 2.0.0: 
<p>
<itemize>
<item><bf>Cos'è:</bf> È l'unico benchmark applicativo in LBT.
<item>Il codice è largamente disponibile (p.es. finalmente troverete
un uso per i vostri vecchi cd di linux).  
<item>Molti utenti Linux ricompilano il kernel abbastanza spesso, così
è una misura significante delle performance generali del sistema 
<item>Il kernel è grosso e gcc usa un bel po' di memoria: ciò attenua
il miglioramento che si potrebbe avere grazie alla cache di secondo
livello svolgendo piccoli test
<item>Svolge frequenti operazioni di I/O col disco
<item>Procedura del test: prendi il sorgente originale di un kernel
2.0.0, compilalo con le opzioni di default (make config e premendo
Invio ripetutamente). Il tempo riportato dovrebbe essere il tempo
speso nella compilazione p.es. dopo che si è digitato make zImage e
<bf>non</bf> includendo make dep, make clean. Notare che
l'architettura di default per il kernel è la i386, perciò se è
compilato su un altra architettura, gcc dovrebbe essere impostato come
cross-compile, con i386 come architettura di destinazione.
<item><bf>Risultati:</bf> tempo di compilazione in minuti e secondi
(per favore, è inutile riportare le frazioni di secondo).
</itemize> 

<sect2>Whetstone: 
<p>
<itemize>
<item><bf>Cos'è:</bf> misura le prestazioni pure dell'unità in virgola
mobile con un corto ciclo. Il sorgente (in C) è abbastanza leggibile
ed è molto facile vedere quali operazioni in virgola mobile ne
prendono parte. 
<item>Test più corto del LBT :-). 
<item>È un "vecchio classico" test: punti di riferimento sono
disponibili, i suoi limiti sono ben conosciuti.  
<item>Procedura del test: il più nuovo sorgente in C dovrebbe essere
ottenuto dal sito Aburto. Compilarlo e eseguirlo in modalità doppia
precisione. Specificare gcc e -O2 come precompilatore e opzioni del
precompilatore.
<item><bf> Risultati:</bf> un indice delle prestazioni dell'unità in
virgola mobile in MWIPS.
</itemize> 

<sect2>Xbench-0.2: 
<p>
<itemize>
<item><bf>Cos'è:</bf> misura le prestazioni dell'X server. 
<item>La misura xStones fornita da xbench è una media pesata di
numerosi test riferiti come indice ad una vecchia Sun station con un
display in bianco e nero. Hmmm... non è inappuntabile come test dei
moderni X server, ma è ancora il miglior strumento che abbia trovato.
<item>Procedura del test: compilare con -O2. Specifichiamo qualche
opzione per una esecuzione più veloce: <tt>./xbench -timegoal 3 &gt; 
results/name_of_your_linux_box.out</tt>. Per avere un punteggio in
xStones, dobbiamo eseguire uno script awk; il modo più semplice è di
digitare <tt>make summary.ms</tt>. Controllare il file summary.ms: il
punteggio in xStone del sistema è nell'ultima colonna della linea con
cui hai specificato il nome della propria macchina durante il test. 
<item><bf>Risultati:</bf> le prestazioni di X misurate in xStones.
<item>Nota: questo test, così com'è è obsoleto. Dovrebbe essere
ricodificato
</itemize> 

<sect2>UnixBench versione 4.01: 
<p>
<itemize>
<item><bf>Cos'è:</bf> misura le prestazioni totali di Unix. Questo
test impegnerà le prestazioni di I/O e le prestazioni di multitasking
del kernel
<item>Ho scartato tutti i risultati dei test aritmetici, tenendo solo
i risultati relativi al sistema.
<item>Procedura di test: compilare con -O2. Eseguire con <tt>./Run
-1</tt> (esegue ogni test una sola volta). Si troverano i risultati in
./results/report file. Calcolare il significato geometrico di EXECL
THROUGHPUT, FILECOPY 1, 2, 3, PIPE THROUGHPUT, PIPE-BASED CONTEXT
SWITCHING, PROCESS CREATION, SHELL SCRIPTS e gli indici di SYSTEM CALL
OVERHEAD. 
<item><bf>Risultati:</bf> un indice di sistema. 
</itemize>

<sect2>BYTE Magazine's BYTEmark benchmarks: 
<p>
<itemize>
<item><bf>Cos'è:</bf> fornisce una buona misurazione delle prestazioni
del processore. Questo è un estratto dalla documentazione: <em>"questi
benchmark hanno la funzione di mostrare il limite superiore teorico di
CPU, FPU e architettura di memoria di un sistema. Non possono misurare
il video, i dischi o il throughput della rete (questi sono dominio di
un'altro set di benchmark). Si dovrebbe, comunque, usare il risultato
di questi test come una parte di un processo di misurazione di un
sistema, non come tutto il processo."</em>
<item>Ho scartato i test in virgola mobile dal momento dal momento che
il test dei Whetstone è più rappresentativo delle prestazioni in
virgola mobile.
<item>Ho diviso i test interi in due parti: quelli più rappresentativi
delle prestazioni di memoria-cache-CPU e i test interi della CPU.
<item>Procedura del test: compilare con -O2. Eseguire il test con 
<tt>./nbench &gt; myresults.dat</tt> o simile. Poi da myresults.dat,
calcolare la media geometrica degli indici della prova STRING
SORT, ASSIGNMENT e BITFIELD ; questo è l'<bf>indice di memoria </bf>;
calcolare la media geometrica degli indici della prova di
NUMERIC SORT, IDEA, HUFFMAN and FP 
EMULATION ; questo è l'<bf>indice intero</bf>. 
<item><bf>Risultati:</bf> un indice di memoria e un indice intero
calcolato come spiegato.
</itemize> 

<sect1>Miglioramenti possibili
<p>
La suite ideale di benchmark dovrebbe terminare in qualche minuto, con
benchmark sintetici che provino ogni sottosistema separatamente e
benchmark applicativi che forniscano risultati per diverse
applicazioni. Dovrebbero anche generare automaticamente un rapporto
completo e eventualmente spedirlo via e-mail ad un database centrale
sul web. 

Qui non siamo davvero interessati alla portabilità, ma dovrebbe almeno
funzionare su tutte le recenti (&gt; 2.0.0) versioni e sapori (i386,
Alpha, Sparc...) di Linux.

Se qualcuno ha un idea circa il benchmarking delle prestazioni di rete
in una maniera semplice e facile, con un test breve (meno di 30 minuti
per impostarlo ed eseguirlo), per favore mi contatti.

<sect1>Modulo LBT
<p>
Dopo i test, la procedura di benchmarking non sarebbe completa senza
un modulo che descrivesse il setup, che così dovrebbe essere (seguendo
le linee guida di comp.benchmarks.faq):  

<code>LINUX  BENCHMARKING TOOLKIT REPORT FORM
</code>
<code>CPU 
== 
Produttore: 
Modello: 
Frequenza di clock: 
Produttore della scheda madre: 
Modello della sk.madre: 
Chipset della sk.madre: 
Tipo di bus: 
Freq. di clock del bus: 
Cache totale: 
Tipo e velocità della cache: 
SMP (numero di processori): 
</code>
<code>RAM 
==== 
Totale: 
Tipo: 
Velocità: 
</code>
<code>Disco 
==== 
Produttore: 
Modello: 
Capienza: 
Interfaccia: 
Driver/Settaggi: 
</code>
<code>Scheda video: 
=========== 
Produttore: 
Modello: 
Bus:
Tipo di Video RAM: 
Totale di Video RAM: 
Produttore X server: 
Versione X server: 
Scelta del chipset nell'X server: 
Risoluzione/freq di refresh verticale: 
Profondità di colore: 
</code>
<code>Kernel 
===== 
Versione: 
Dimensione file di swap:
</code>
<code>gcc 
=== 
Versione: 
Opzioni: 
versione libc: 
</code>
<code>Note al test
==========
</code>
<code>RISULTATI 
======== 
Tempo di compilazione del kernel 2.0.0 
Tempo di compilazione: (minuti e secondi)  
Whetstones: risultati in MWIPS. 
Xbench: risultati in xstones. 
Unixbench Benchmarks 4.01: indice di systema 
BYTEmark: INDEX intero
BYTEmark: INDICE di memoria
</code>
<code>Commenti* 
========= 
* Questo campo è incluso per possibili interpretazioni dei risultati,
e come specificato è opzionale. Potrebbe essere la parte più
significativa del proprio report, specialmente se si stanno
effettuando benchmark comparativi.
</code> 

<sect1>Test delle prestazioni della rete 
<p>
Provare le prestazioni di una rete è un'ardua sfida dal momento che
include almeno due macchine, un server ed un client, quindi il doppio
del tempo per impostarlo e molte molte variabili da controllare,
ecc... Su una rete ethernet, penso che la migliore scelta sarebbe il
pacchetto ttcp. (da espandere) 

<sect1>Test degli SMP (Multi processori simmetrici) 
<p>
I test degli SMP sono un'altra sfida ed ogni benchmark
specificatamente progettato per testare l'SMP avrà un lungo tempo per
dimostarsi valido nelle impostazioni della vita reale, dal momento che
gli algoritmi che possono prendere vantaggio dall'SMP sono difficili
da progettare. Sembra che le ultime versioni del kernel (&gt; 2.1.30 è
successive) faranno un multiprocessing "fine-grained". Ma non ho
informazioni maggiori in questo momento. 

Secondo David Niemi, <em>" ... shell8</em>[parte degli Unixbench 4.01
benchmaks]<em> svolge un buon lavoro nel confrontare combinazioni
simili di hardware e sistemi operativi nei modi SMP e UP"</em> 

<sect>Esempi di esecuzione e risultati
<p>
L'LBT è stato eseguito sulla mia macchina di casa, un sistema Linux di
classe Pentium con il quale ho scritto questo HOWTO. Qui c'è il modulo
di report LBT per il mio sitema
<verb> 
LINUX  BENCHMARKING TOOLKIT REPORT FORM
</verb>
<verb>CPU 
</verb>
<verb>== 
</verb>
<verb>Produttore: Cyrix/IBM 
</verb>
<verb>Modello: 6x86L P166+
</verb>
<verb>Frequenza di clock: 133 MHz
</verb>
<verb>Produttore scheda madre: Elite Computer Systems (ECS)
</verb>
<verb>Sk. madre: P5VX-Be
</verb>
<verb>Chipset: Intel VX
</verb>
<verb>Tipo di bus: PCI
</verb>
<verb>Frequenza di clock del bus: 33 MHz
</verb>
<verb>Cache totale: 256 KB
</verb>
<verb>Cache tipo/velocità: Pipeline burst 6 ns
</verb>
<verb>SMP (numero di processori): 1
</verb>
<verb>RAM 
</verb>
<verb>==== 
</verb>
<verb>Totale: 32 MB
</verb>
<verb>Tipo: EDO SIMMs
</verb>
<verb>Velocità: 60 ns
</verb>
<verb>Disco 
</verb>
<verb>==== 
</verb>
<verb>Produttore: IBM
</verb>
<verb>Modello: IBM-DAQA-33240
</verb>
<verb>Grandezza: 3.2 GB
</verb>
<verb>Interfaccia: EIDE
</verb>
<verb>Driver/Settaggi: Bus Master DMA modo 2
</verb>
<verb>Scheda video 
</verb>
<verb>=========== 
</verb>
<verb>Produttore: Generica S3
</verb>
<verb>Modello: Trio64-V2
</verb>
<verb>Bus: PCI
</verb>
<verb>Tipo Video RAM: EDO DRAM 
</verb>
<verb>Totale Video RAM: 2 MB
</verb>
<verb>Produttore X server: XFree86
</verb>
<verb>Versione X server: 3.3
</verb>
<verb>Scelta chipset dell'X server: S3 accellerato 
</verb>
<verb>Risoluzione/rinfresco verticale: 1152x864 @ 70 Hz
</verb>
<verb>Profondità di colore: 16 bit
</verb>
<verb>Kernel 
</verb>
<verb>===== 
</verb>
<verb>Versione: 2.0.29
</verb>
<verb>File di swap: 64 MB
</verb>
<verb>gcc 
</verb>
<verb>=== 
</verb>
<verb>Versione: 2.7.2.1
</verb>
<verb>Opzioni: -O2
</verb>
<verb>versione libc: 5.4.23 
</verb>
<verb>Note del test 
</verb>
<verb>==========
</verb>
<verb>Carico molto basso. I seguenti risultati sono stati ottenuti abilitando alcune delle speciali features del Cyrix/IBM 6x86
abilitate con il programma setx86: fast ADS,  fast IORT, Enable DTE, fast LOOP, fast Lin. VidMem.
</verb>
<verb>RISULTATI 
</verb>
<verb>======== 
</verb>
<verb>Kernel Linux 2.0.0 Tempo di compilazione: 7m12s
</verb>
<verb>Whetstones: 38.169 MWIPS. 
</verb>
<verb>Xbench: 97243 xStones. 
</verb>
<verb>BYTE Unix Benchmarks 4.01 INDICE di sistema: 58.43
</verb>
<verb>BYTEmark integri INDICE: 1.50
</verb>
<verb>BYTEmark INDICE memoria: 2.50
</verb>
<verb>Commenti
</verb>
<verb>========= 
</verb>
<verb>Questo è un sistema molto stabile con prestazioni omogenee, ideale per l'uso di casa e/o lo sviluppo in Linux. Riporterò al più presto i risultati con un processore 6x86MX appena ne avrò uno fra le mani!
</verb>

<sect>Trappole e inesattezze del benchmarking 
<p>

Dopo aver messo insieme questo HOWTO ho iniziato a comprendere come le
parole "trappole" e "inesattezze" siano così spesso associate al
benchmarking... 

<sect1>Paragonando mele e arance  
<p>

O dovrei dire Apple e PC? Questa è una disputa così vecchia e ovvia
che non andrò avanti nei dettagli. Dubito che il tempo che impieghi
Word a caricarsi su un Mac confrontato con un medio Pentium sia la
misura reale di qualcosa. Lo stesso vale per il confronto tra il tempo
di boot di Linux e Windows NT, ecc ... Provare a confrontare il più
possibile macchine identiche con una singola modifica. 

<sect1>Informazioni incomplete 
<p>

Un singolo esempio illustrerà questo errore molto comune. Spesso si
legge in comp.os.linux.hardware le seguenti frasi, o simili: "Ho
appena montato il processore XYZ a nnn MHz e ora compilare il kernel
di linux prende solo x minuti" (poni pure XYZ , nnn e x come meglio
credi). Questo è irritante, perché nessun altra informazione è data,
ad.es. non sappiamo neanche l'ammontare della RAM, la dimensione dello
swap, gli altri processi in esecuzione nello stesso momento, la
versione del kernel, i moduli selezionati, il tipo di hard disk, la
versione di gcc, ecc... È consigliato di usare il modulo di report LBT
che utilizza almeno una maschera di raccolta dati standard. 

<sect1>Hardware/software proprietario
<p>

Un ben conosciuto produttore di processori una volta pubblicò i
risultati dei benchmarks prodotti da una speciale, personalizzata
versione di gcc. A parte le considerazioni etiche, questi risultati
erano senza senso, dal momento che il 100&percnt; della comunità Linux
continuerebbe ad usare la versione standard di gcc. Lo stesso vale per
l'hardware proprietario. Il Benchmarking è molto più utile quando si
rapporta a hardware comune e software libero (nel significato GNU/GPL
di libero). 

<sect1>Rilevanza 
<p>

Stiamo parlando di Linux, giusto? Così ci dobbiamo scordare dei
benchmark prodotti su altri sistemi operativi (questo è un caso
speciale della trappola "Confrontare mele e arance" spiegata
prima). Allo stesso modo, se si è intenzionati a testare le
prestazioni di un server Web, <bf>non</bf> citare le prestazioni
dell'unità in virgola mobile, o altre informazioni irrilevanti. In
molti casi meno è meglio. Allo stesso modo, <bf>non</bf> c'è bisogno
di menzionare gli anni del tuo gatto, il tuo stato d'animo mentre
stavi effettuando il test, ecc... 

<sect>FAQ (Domande Frequenti) 
<p>
<descrip>
<tag>D1.</tag> C'è un qualsiasi indice di merito per i sistemi Linux?
<tag>A:</tag> No, fortunatamente nessuno è ancora venuto fuori con una
misurazione Lhinuxstone (tm). E se ce ne fosse uno, non avrebbe molto
senso: i sistemi Linux sono usati per tanti differenti compiti, dal
server web pesantemente caricato alla workstation grafica per uso
individuale. Nessun singolo indice di merito può descrivere le
prestazioni di un sistema Linux in differenti situazioni.
<tag>D2.</tag> Quindi perché non una dozzina di indici riassumenti le
prestazioni di diversi sistemi Linux?
<tag>A:</tag> Sarebbe la situazione ideale. Vorrei vedere ciò
diventare realtà. Nessun volontario per un <bf>Linux Benchmarking
Project</bf>? Con un sito web e un database completo e ben progettato? 
<tag>D3.</tag>... BogoMips ...? 
<tag>A:</tag> I BogoMips non hanno <bf>niente</bf> a che fare con le
prestazioni del sistema. Leggere il BogoMips Mini-HOWTO.
<tag>D4.</tag> Qual è il miglior benchmark per Linux?  
<tag>A:</tag> Dipende da quale aspetto prestazionale di linux si vuole 
misurare. Ci sono differenti benchmark per misurare la rete (p.es i
transfer rate), i file server (NFS), l'I/O dei dischi, le prestazioni
sui calcoli in virgola mobile e interi, grafica, 3D, larghezza di
banda della memoria del processore, prestazioni CAD, tempo di
transazione, prestazioni SQL, prestazioni del server Web, prestazioni
in tempo reale, prestazioni del CD-ROM, prestazioni di Quake (!), ecc
... AFAIK nessuna suite di benchmark esiste per linux che supporti
tutti questi test. 
<tag>D5.</tag> Qual è il processore più veloce sotto Linux?  
<tag>A:</tag> Il più veloce in quale processo? Se si è molto orientati
alla masticazione di numeri, un processore Alpha ad alta frequenza di
clock (600 MHz in su) dovrebbe essere più veloce di nessun altro, dal
momento che gli Alpha sono stati progettati proprio per fornire questo
tipo di prestazioni. Se, dall'altro lato, si vuole mettere assieme un
server news davvero veloce, è probabile che la scelta di un veloce
sottosistema di dischi rigidi e molta RAM risulterà in un migliore
aumento di prestazioni che un cambio di processore per la stessa somma
di &dollar;.
<tag>D6.</tag>Fammi riformulare l'ultima domanda, allora: c'è un
processore che è il più veloce per applicazioni generiche?  
<tag>A:</tag>Questa è una domanda trabocchetto ma ha una sola e
semplice risposta: <bf>NO</bf>. Si può sempre disegnare un sistema
veloce anche per applicazioni generiche, indipendentemente dal
processore. Di solito, restando uguali tutte le altre cose, una più
alta frequenza di clock risulterà in maggiori prestazioni del sistema
(e anche più mal di testa). Tirando fuori un vecchio processore a
100Mhz da una motherboard (di solito non) aggiornabile, e inserendo
dentro la versione a 200Mhz, si dovrebbe sentire una grande
differenza. Certamente con solo 16 MB di RAM, lo stesso investimento
sarebbe stato molto più saggiamente speso in DIMMs aggiuntive ... 
<tag>D7.</tag> Ma allora la frequenza di clock influenza le
prestazioni di un sistema?
<tag>A:</tag> Per molti processi, eccetto per i loop NOP vuoti (a
proposito, questi stanno per essere rimossi dai moderni compilatori
ottimizzanti), una maggiorazione nella frequenza di clock non darebbe
un aumento lineare delle prestazioni. Molti piccoli programmi che
fanno un uso intensivo del processore entrano interamente nella cache
primaria del processore (la cache L1, usualmente 16 o 32K) e avranno
un aumento di prestazioni equivalente all'aumento della frequenza di
clock, ma molti "veri" programmi sono molto più larghi di ciò, hanno
cicli che non entrano nella cache L1, condividono la cache di secondo
livello (L2) con altri processi, dipendono da componenti esterni e
daranno un incremento di prestazioni molto minore. Questo è perché la
cache L1 funziona alla stessa frequenza di clock del processore,
mentre molte cache di secondo livello e tutti gli altri sottosistemi
(DRAM per esempio) funzionano in maniera asincrona a minore frequenza
di clock. 
<tag>D8.</tag> OK, poi, un ultima domanda su questa questione: qual è
il processore con il miglior rapporto tra prezzo e prestazioni per un
uso generico di Linux?   
<tag>A:</tag> Definire un "Linux di uso generico" non è una cosa
facile! Per ogni particolare applicazione, c'è sempre un processore
con IL MIGLIORE rapporto prezzo/prestazioni in ogni momento, ma cambia
abbastanza frequentemente così come i produttori rilasciano nuovi
processori, così rispondere Processore XYZ a nnn Mhz sarebbe una
risposta valida solo in quel momento. Comunque il prezzo di un
processore è insignificante se paragonato al prezzo dell'intero
sistema che si sta assemblando. Così, davvero, la questione dovrebbe
come si può massimizzare il rapporto tra prezzo e prestazioni di un
dato sistema? E la risposta a questa domanda dipende fortemente dal
minimo di prestazioni richieste e/o dal prezzo massimo stabilito per
la configurazione che si sta considerando. A volte l'hardware comune
non soddisfa le prestazioni minime richieste e costosi sistemi RISC
sarebbero la sola alternativa. Per l'uso di casa si raccomanda un
sistema bilanciato e omogeneo per tutte le prestazioni (ora vai ad
immaginare che cosa io intendo per bilanciato e omogeneo :-); la
scelta di un processore è una decisione importante, ma non più che
scegliere il tipo di disco fisso e la capacità, il quantitativo di
RAM, la scheda video, ecc ... 
<tag>D9. </tag>Quando un aumento delle prestazioni è considerato
"significativo"?
<tag>A: </tag>Vorrei rispondere che innanzittutto ogni variazione
sotto all'1&percnt; non è significativa (potrebbe essere descritta come
"marginale"). Noi umani, difficilmente percepiamo la differenza tra
due sistemi con un 5&percnt; di differenza nel tempo di
risposta. Certamente alcuni benchmarkers "hard-core" non sono umani e
ti diranno confrontando un sistema con indici di sistema 65.9 e 66.5
che il secondo è sicuramente molto più veloce. 
<tag>D10. </tag>Come posso ottenere "significativi" aumenti nelle
prestazioni al costo minore? 
<tag>A:</tag> Dal momento che molti codici sorgenti per Linux sono
disponibili gratuitamente, l'esame attento e il ridisegno algoritmico
delle subroutine chiave potrebbe aumentare in alcuni casi le
prestazioni. Se ci si trova ad avere a che fare con un progetto
commerciale e non ci si vuole addentrare profondamente nello sviluppo
in codice C <bf>si dovrebbe chiamare un consulente Linux</bf>. Vedere
il Consultants-HOWTO. 
</descrip> 

<sect>Copyright, riconoscimenti e varie
<p>
<sect1>Come è stato scritto questo documento:
<p>

Il primo passo è stato leggere la sezione 4 di "Writing and submitting
a HOWTO" dell'HOWTO Index di Tim Bynum.  

Non conoscevo assolutamente niente di SGML o LaTeX, ma sono stato
tentato di usare un pacchetto automatico di generazione dopo aver
letto i vari commenti sugli SGML-Tools. Comunque inserire i tags
manualmente in un documento mi ricorda i giorni che assemblai a mano
un programma monitor da 512 byte per un, ora defunto, processore a
8bit, così sono entrato in possesso dei codici sorgenti di LyX, li ho
compilati, ed ho usato il suo modo LinuxDoc. Combinazione altamente
raccomandata: <bf>LyX e SGML-Tools</bf>. 

<sect1>Copyright
<p>

The Linux Benchmarking HOWTO is copyright (C) 1997 by André
D. Balsa. Linux HOWTO documents may be reproduced and distributed in
whole or in part, in any medium physical or electronic, as long as
thqs copyright notice is retained on all copies. Commercial
redistribution is allowed and encouraged; however, the author would
like to be notified of any such distributions.

All translations, derivative works, or aggregate works incorporating
any Linux HOWTO documents must be covered under this copyright
notice. That is, you may not produce a derivative work from a HOWTO
and impose additional restrictions on its distribution. Exceptions to
these rules may be granted under certain conditions; please contact
the Linux HOWTO coordinator at the address given below.

In short, we wish to promote dissemination of this information through
as many channels as possible.  However, we do wish to retain copyright
on the HOWTO documents, and would like to be notified of any plans to
redistribute the HOWTOs.  

If you have questions, please contact Tim Bynum, the Linux HOWTO
coordinator, at linux-howto@sunsite.unc.edu via email.

<sect1>Nuove versioni di questo documento
<p>

Le nuove versioni del Linux Benchmarking-HOWTO saranno depositate su
sunsite.unc.edu e siti mirror.  Sono disponibili altri formati, come
una versione Postscript e dvi, nella directory other-formats. Il Linux
Benchmarking-HOWTO è pure dispononibile per client WWW come Grail, un
Web browser scritto in Python. Sarà pure inviato regolarmente a
comp.os.linux.answers.

<sect1>Commenti e critiche
<p>
Sono richiesti suggerimenti, correzioni e aggiunte. Si cercano
contributi e riscontri. Non si cercano flame. 

Posso sempre essere raggiunto a andrewbalsa@usa.net.

<sect1>Riconoscimenti
<p>

David Niemi, l'autore della suite Unixbench, ha provato di essere una
fonte inesauribile di informazioni e di (valide) critiche. 

Voglio anche ringraziare Greg Hankins uno dei maggiori contributori al
pacchetto SGML-tools, Linus Torvalds e l'intera comunità
Linux. Questo HOWTO è il mio modo per ringraziare.

<sect1>Disclaimer
<p>

Your mileage may, and will, vary. Be aware that benchmarking is a
touchy subject and a great time-and-energy consuming activity. 

<sect1>Marchi registrati
<p>

Pentium e Windows NT sono marchi registrati rispettivamente da Intel e
Microsoft.   

BYTE e BYTEmark sono marchi registrati da McGraw-Hill, Inc.

Cyrix e 6x86 sono marchi registrati da Cyrix Corporation.

Linux non è un marchio registrato, e spero che mai lo sarà. :)

</article>
