Linux Benchmarking HOWTO

Linux Benchmarking HOWTO
di Andr� D. Balsa, [email protected]
v0.12, 15 agosto 1997

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 Gian�
luca Pecoraro ([email protected]).

1. Introduzione

"What we cannot speak about we must pass over in silence."

Ludwig Wittgenstein (1889-1951), filosofo austriaco

Benchmarking significa misurare 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� non 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.

1.1. Perch� il benchmarking � cos� importante?

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:

� Come massimizzo le prestazioni per un dato budget?

� Come riduco i costi per un dato livello minimo di prestazioni?

� Come ottengo il miglior rapporto prezzo/prestazioni (entro un dato
budget o una data richiesta di prestazioni?)

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 costo, 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 stabilit� � quasi sempre
pi� importante della velocit�.

1.2. Considerazioni non valide per il benchmarking

Spesso si leggono nei newsgroup e nelle mailing list, sfortunatamente:

1. Reputazione del costruttore (non misurabile e senza senso).

2. Quote di mercato del costruttore (senza senso e irrilevanti).

3. Parametri irrazionali (p.es. la superstizione o il pregiudizio:
compreresti un processore etichettato 171717ZAP e colorato di
rosa?)

4. Valori percepiti (senza senso, non misurabili e irrazionali).

5. 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.

6. Le opinioni del tipo "Tu hai per quello che paghi" sono solo
quello: opinioni. Fornite i fatti per favore.

2. Procedure di benchmarking e interpretazione dei risultati

Qualche raccomandazione semi-ovvia

1. Prima di tutto, identificare i propri obiettivi nel benchmarking.
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?

2. Usare strumenti standard. 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)

3. Dare una completa descrizione del setup (vedere il modulo LBT pi�
avanti).

4. Provare a isolare una singola variabile. Il Benchmark comparativo �
pi� informativo del benchmark "assoluto". Non lo ripeter� mai
abbastanza.

5. Verificare i propri risultati. Fare i propri benchmark pi� di una
volta e verificare le variazioni nei risultati, se ce ne sono.
Variazioni inspiegate invalideranno i risultati.

6. Se si pensa che i propri sforzi nel benchmarking produrrano
informazioni utili, condividerle con la comunit� Linux in una
maniera precisa e concisa.

7. Per favore ci si dimentichi dei BogoMips. Mi sono ripromesso di
implementare un giorno un ASIC davvero veloce con il ciclo dei
BogoMips dentro. Poi vedremo quello che vedremo!

2.1. Capire le scelte di benchmarking

2.1.1. Benchmark sintetici contro applicazioni

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 Whetstone 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 specifico
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.:

"Una unit� in virgola mobile (FPU) accelera il software pro�
gettato 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 proget�
tazione dei processori 6x86 per velocizzare le prestazioni
dei software che mischiano questi due tipi di istruzioni.

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 quat�
tro 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.

L'esame dei test di benchmark rivela che i benchmark sin�
tetici 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"

Cos� la recente moda nel benchmarking � di scegliere applicazioni
comuni ed usare queste per provare le prestazioni di un computer
completo. Per esempio, SPEC, 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.

2.1.2. Benchmark di alto livello contro quelli di basso livello

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&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.

2.2. Benchmark standard disponibili per Linux

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:

"Cambiare A in B porta ad un miglioramento delle prestazioni
di x % nella compilazione del kernel di Linux sotto tale e
tali condizioni".

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 individuale 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 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:

"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."

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
[email protected] <mailto:[email protected]>. Il
Washington Area Unix User Group � anche in procinto di mettere su un
Sito Web per i benchmark Linux.

Inoltre recentemente, Uwe F. Mayer, [email protected]
<mailto:[email protected]> 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 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'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.

2.3. Collegamenti e riferimenti

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 56 differenti benchmark, 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 lmbench suite, di Larry McVoy. Citando David
C. Niemi:

"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.

Un Sito FTP piuttosto completo per benchmark liberamente disponibili �
stato messo su da Alfred Aburto. La Whetstone suite usata nell'LBT pu�
essere trovata a questo sito.

C'� una FAQ in pi� parti di Eugene Miya che viene postata regolarmente
su comp.benchmarks; � un eccellente punto di riferimento.

3. The Linux Benchmarking Toolkit (LBT)

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.

3.1. Razionale

Questo � solo il buonsenso:

1. 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.

2. Tutto il codice sorgente utilizzato per il programma deve essere
liberamente disponibile su internet per ovvie ragioni.

3. I benchmark dovrebbero provvedere semplici indici che rispecchino
le performance misurate.

4. Ci dovrebbe essere un misto di benchmark sintetici e applicativi

5. Ogni benchmark sintetico dovrebbe impiegare il relativo
sottosistema alla sua massima capacit�.

6. I risultati dei benchmark sintetici non dovrebbero essere unificati
in un unico indice (che non rispetta l'intera idea che c'� dietro i
benchmark sintetici, con considerevole perdita di informazioni).

7. I benchmark applicativi dovrebbero consistere in processi eseguiti
comunemente in un sistema Linux

3.2. Selezione dei benchmark

Ho selezionato cinque differenti suite di benchmarking, tentando il
pi� possibile di eliminare overlap nei test:

1. Compilazione del Kernel 2.0.0 (configurazione di default) usando
gcc.

2. Whetstone suite versione 10/03/97 (ultima versione di Roy
Longbottom).

3. xbench-0.2 (con parametri di esecuzione veloce).

4. UnixBench benchmarks versione 4.01 (risultati parziali).

5. BYTE Magazine's BYTEmark benchmarks beta release 2 (risultati
parziali).

Per i test 4 e 5, "(risultati parziali)" significa che non tutti i
risultati prodotti da questi benchmark vanno considerati.

3.3. Durata dei test

1. Kernel 2.0.0, compilazione: da 5 a 30 minuti, dipende dalle reali
performance del sistema.

2. Whetstone: 100 secondi.

3. Xbench-0.2: < 1 ora.

4. UnixBench benchmarks versione 4.01: approssimativamente 15 minuti.

5. BYTE Magazine's BYTEmark benchmarks: approssimativamente 10 minuti.

3.4. Commenti

3.4.1. Compilazione Kernel 2.0.0:

� Cos'�: � l'unico benchmark applicativo in LBT.

� Il codice � largamente disponibile (p.es. finalmente troverete un
uso per i vostri vecchi cd di linux).

� Molti utenti Linux ricompilano il kernel abbastanza spesso, cos� �
una misura significante delle performance generali del sistema

� 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

� Svolge frequenti operazioni di I/O col disco

� 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
non 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.

� Risultati: tempo di compilazione in minuti e secondi (per favore, �
inutile riportare le frazioni di secondo).

3.4.2. Whetstone:

� Cos'�: 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.
� Test pi� corto del LBT :-).

� � un "vecchio classico" test: punti di riferimento sono
disponibili, i suoi limiti sono ben conosciuti.

� 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.

� Risultati: un indice delle prestazioni dell'unit� in virgola
mobile in MWIPS.

3.4.3. Xbench-0.2:

� Cos'�: misura le prestazioni dell'X server.

� 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.

� Procedura del test: compilare con -O2. Specifichiamo qualche
opzione per una esecuzione pi� veloce: ./xbench -timegoal 3 >
results/name_of_your_linux_box.out. Per avere un punteggio in
xStones, dobbiamo eseguire uno script awk; il modo pi� semplice �
di digitare make summary.ms. 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.

� Risultati: le prestazioni di X misurate in xStones.

� Nota: questo test, cos� com'� � obsoleto. Dovrebbe essere
ricodificato

3.4.4. UnixBench versione 4.01:

� Cos'�: misura le prestazioni totali di Unix. Questo test impegner�
le prestazioni di I/O e le prestazioni di multitasking del kernel

� Ho scartato tutti i risultati dei test aritmetici, tenendo solo i
risultati relativi al sistema.

� Procedura di test: compilare con -O2. Eseguire con ./Run -1 (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.

� Risultati: un indice di sistema.

3.4.5. BYTE Magazine's BYTEmark benchmarks:

� Cos'�: fornisce una buona misurazione delle prestazioni del
processore. Questo � un estratto dalla documentazione: "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."

� Ho scartato i test in virgola mobile dal momento dal momento che il
test dei Whetstone � pi� rappresentativo delle prestazioni in
virgola mobile.

� Ho diviso i test interi in due parti: quelli pi� rappresentativi
delle prestazioni di memoria-cache-CPU e i test interi della CPU.

� Procedura del test: compilare con -O2. Eseguire il test con
./nbench > myresults.dat o simile. Poi da myresults.dat, calcolare
la media geometrica degli indici della prova STRING SORT,
ASSIGNMENT e BITFIELD ; questo � l'indice di memoria ; calcolare la
media geometrica degli indici della prova di NUMERIC SORT, IDEA,
HUFFMAN and FP EMULATION ; questo � l'indice intero.

� Risultati: un indice di memoria e un indice intero calcolato come
spiegato.

3.5. Miglioramenti possibili

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 (> 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.

3.6. Modulo LBT

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):

______________________________________________________________________
LINUX BENCHMARKING TOOLKIT REPORT FORM
______________________________________________________________________

______________________________________________________________________
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):
______________________________________________________________________

______________________________________________________________________
RAM
====
Totale:
Tipo:
Velocit�:
______________________________________________________________________

______________________________________________________________________
Disco
====
Produttore:
Modello:
Capienza:
Interfaccia:
Driver/Settaggi:
______________________________________________________________________

______________________________________________________________________
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:
______________________________________________________________________

______________________________________________________________________
Kernel
=====
Versione:
Dimensione file di swap:
______________________________________________________________________

______________________________________________________________________
gcc
===
Versione:
Opzioni:
versione libc:
______________________________________________________________________

______________________________________________________________________
Note al test
==========
______________________________________________________________________

______________________________________________________________________
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
______________________________________________________________________

______________________________________________________________________
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.
______________________________________________________________________

3.7. Test delle prestazioni della rete

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)

3.8. Test degli SMP (Multi processori simmetrici)

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 (> 2.1.30 �
successive) faranno un multiprocessing "fine-grained". Ma non ho
informazioni maggiori in questo momento.

Secondo David Niemi, " ... shell8[parte degli Unixbench 4.01
benchmaks] svolge un buon lavoro nel confrontare combinazioni simili
di hardware e sistemi operativi nei modi SMP e UP"

4. Esempi di esecuzione e risultati

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

LINUX BENCHMARKING TOOLKIT REPORT FORM

CPU

==

Produttore: Cyrix/IBM

Modello: 6x86L P166+

Frequenza di clock: 133 MHz

Produttore scheda madre: Elite Computer Systems (ECS)

Sk. madre: P5VX-Be

Chipset: Intel VX

Tipo di bus: PCI

Frequenza di clock del bus: 33 MHz

Cache totale: 256 KB

Cache tipo/velocit�: Pipeline burst 6 ns

SMP (numero di processori): 1

RAM

====

Totale: 32 MB

Tipo: EDO SIMMs

Velocit�: 60 ns

Disco

====

Produttore: IBM

Modello: IBM-DAQA-33240

Grandezza: 3.2 GB

Interfaccia: EIDE

Driver/Settaggi: Bus Master DMA modo 2

Scheda video

===========

Produttore: Generica S3

Modello: Trio64-V2

Bus: PCI

Tipo Video RAM: EDO DRAM

Totale Video RAM: 2 MB

Produttore X server: XFree86

Versione X server: 3.3

Scelta chipset dell'X server: S3 accellerato

Risoluzione/rinfresco verticale: 1152x864 @ 70 Hz

Profondit� di colore: 16 bit

Kernel

=====

Versione: 2.0.29

File di swap: 64 MB

gcc

===

Versione: 2.7.2.1

Opzioni: -O2

versione libc: 5.4.23

Note del test

==========

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.

RISULTATI

========

Kernel Linux 2.0.0 Tempo di compilazione: 7m12s

Whetstones: 38.169 MWIPS.

Xbench: 97243 xStones.

BYTE Unix Benchmarks 4.01 INDICE di sistema: 58.43

BYTEmark integri INDICE: 1.50

BYTEmark INDICE memoria: 2.50

Commenti

=========

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!

5. Trappole e inesattezze del benchmarking

Dopo aver messo insieme questo HOWTO ho iniziato a comprendere come le
parole "trappole" e "inesattezze" siano cos� spesso associate al
benchmarking...

5.1. Paragonando mele e arance

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.

5.2. Informazioni incomplete

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.

5.3. Hardware/software proprietario

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% 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).

5.4. Rilevanza

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, non citare le prestazioni dell'unit� in virgola mobile, o
altre informazioni irrilevanti. In molti casi meno � meglio. Allo
stesso modo, non c'� bisogno di menzionare gli anni del tuo gatto, il
tuo stato d'animo mentre stavi effettuando il test, ecc...

6. FAQ (Domande Frequenti)

D1.
C'� un qualsiasi indice di merito per i sistemi Linux?

A: 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.

D2.
Quindi perch� non una dozzina di indici riassumenti le
prestazioni di diversi sistemi Linux?

A: Sarebbe la situazione ideale. Vorrei vedere ci� diventare
realt�. Nessun volontario per un Linux Benchmarking Project? Con
un sito web e un database completo e ben progettato?

D3.
... BogoMips ...?

A: I BogoMips non hanno niente a che fare con le prestazioni del
sistema. Leggere il BogoMips Mini-HOWTO.

D4.
Qual � il miglior benchmark per Linux?

A: 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.

D5.
Qual � il processore pi� veloce sotto Linux?

A: 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 $.

D6.
Fammi riformulare l'ultima domanda, allora: c'� un processore
che � il pi� veloce per applicazioni generiche?

A: Questa � una domanda trabocchetto ma ha una sola e semplice
risposta: NO. 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 ...

D7.
Ma allora la frequenza di clock influenza le prestazioni di un
sistema?

A: 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.

D8.
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?

A: 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 ...

D9.
Quando un aumento delle prestazioni � considerato
"significativo"?

A: Vorrei rispondere che innanzittutto ogni variazione sotto all'1%
non � significativa (potrebbe essere descritta come
"marginale"). Noi umani, difficilmente percepiamo la differenza
tra due sistemi con un 5% 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.

D10.
Come posso ottenere "significativi" aumenti nelle prestazioni al
costo minore?

A: 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 si dovrebbe chiamare un consulente Linux.
Vedere il Consultants-HOWTO.

7. Copyright, riconoscimenti e varie

7.1. Come � stato scritto questo documento:

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: LyX e SGML-Tools.

7.2. Copyright

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 [email protected] via email.

7.3. Nuove versioni di questo documento

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.

7.4. Commenti e critiche

Sono richiesti suggerimenti, correzioni e aggiunte. Si cercano
contributi e riscontri. Non si cercano flame.

Posso sempre essere raggiunto a [email protected].

7.5. Riconoscimenti

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.

7.6. Disclaimer

Your mileage may, and will, vary. Be aware that benchmarking is a
touchy subject and a great time-and-energy consuming activity.

7.7. Marchi registrati

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�. :)