Linux Benchmarking HOWTO di André D. Balsa, andrewbalsa@usa.net 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 (atahualpa@altavista.net). ______________________________________________________________________ Indice Generale 1. Introduzione 1.1 Perché il benchmarking è così importante? 1.2 Considerazioni non valide per il benchmarking 2. Procedure di benchmarking e interpretazione dei risultati 2.1 Capire le scelte di benchmarking 2.1.1 Benchmark sintetici contro applicazioni 2.1.2 Benchmark di alto livello contro quelli di basso livello 2.2 Benchmark standard disponibili per Linux 2.3 Collegamenti e riferimenti 3. The Linux Benchmarking Toolkit (LBT) 3.1 Razionale 3.2 Selezione dei benchmark 3.3 Durata dei test 3.4 Commenti 3.4.1 Compilazione Kernel 2.0.0: 3.4.2 Whetstone: 3.4.3 Xbench-0.2: 3.4.4 UnixBench versione 4.01: 3.4.5 BYTE Magazine's BYTEmark benchmarks: 3.5 Miglioramenti possibili 3.6 Modulo LBT 3.7 Test delle prestazioni della rete 3.8 Test degli SMP (Multi processori simmetrici) 4. Esempi di esecuzione e risultati 5. Trappole e inesattezze del benchmarking 5.1 Paragonando mele e arance 5.2 Informazioni incomplete 5.3 Hardware/software proprietario 5.4 Rilevanza 6. FAQ (Domande Frequenti) 7. Copyright, riconoscimenti e varie 7.1 Come è stato scritto questo documento: 7.2 Copyright 7.3 Nuove versioni di questo documento 7.4 Commenti e critiche 7.5 Riconoscimenti 7.6 Disclaimer 7.7 Marchi registrati ______________________________________________________________________ 11.. IInnttrroodduuzziioonnee _"_W_h_a_t _w_e _c_a_n_n_o_t _s_p_e_a_k _a_b_o_u_t _w_e _m_u_s_t _p_a_s_s _o_v_e_r _i_n _s_i_l_e_n_c_e_._" _L_u_d_w_i_g _W_i_t_t_g_e_n_s_t_e_i_n _(_1_8_8_9_-_1_9_5_1_)_, _f_i_l_o_s_o_f_o _a_u_s_t_r_i_a_c_o Benchmarking significa mmiissuurraarree 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ò nnoonn 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. 11..11.. PPeerrcchhéé iill bbeenncchhmmaarrkkiinngg èè ccoossìì iimmppoorrttaannttee?? 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 ccoossttoo, 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 ssttaabbiilliittàà è quasi sempre più importante della velocità. 11..22.. CCoonnssiiddeerraazziioonnii nnoonn vvaalliiddee ppeerr iill bbeenncchhmmaarrkkiinngg 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. 22.. PPrroocceedduurree ddii bbeenncchhmmaarrkkiinngg ee iinntteerrpprreettaazziioonnee ddeeii rriissuullttaattii Qualche raccomandazione semi-ovvia 1. Prima di tutto, iiddeennttiiffiiccaarree ii pprroopprrii oobbiieettttiivvii nneell bbeenncchhmmaarrkkiinngg. 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. UUssaarree ssttrruummeennttii ssttaannddaarrdd. 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 ccoommpplleettaa ddeessccrriizziioonnee del setup (vedere il modulo LBT più avanti). 4. Provare a iissoollaarree uunnaa ssiinnggoollaa vvaarriiaabbiillee. Il Benchmark comparativo è più informativo del benchmark "assoluto".. NNoonn lloo rriippeetteerròò mmaaii aabbbbaassttaannzzaa.. 5. VVeerriiffiiccaarree ii pprroopprrii rriissuullttaattii. 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, ccoonnddiivviiddeerrllee con la comunità Linux in una maniera pprreecciissaa e ccoonncciissaa. 7. Per favore ccii ssii ddiimmeennttiicchhii ddeeii BBooggooMMiippss. Mi sono ripromesso di implementare un giorno un ASIC davvero veloce con il ciclo dei BogoMips dentro. Poi vedremo quello che vedremo! 22..11.. CCaappiirree llee sscceellttee ddii bbeenncchhmmaarrkkiinngg 22..11..11.. BBeenncchhmmaarrkk ssiinntteettiiccii ccoonnttrroo aapppplliiccaazziioonnii 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 WWhheettssttoonnee 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 ssppeecciiffiiccoo 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.: _"_U_n_a _u_n_i_t_à _i_n _v_i_r_g_o_l_a _m_o_b_i_l_e _(_F_P_U_) _a_c_c_e_l_e_r_a _i_l _s_o_f_t_w_a_r_e _p_r_o_­ _g_e_t_t_a_t_o _p_e_r _u_s_a_r_e _i_l _c_a_l_c_o_l_o _m_a_t_e_m_a_t_i_c_o _i_n _v_i_r_g_o_l_a _m_o_b_i_l_e_: _t_i_p_i_c_a_m_e_n_t_e _p_r_o_g_r_a_m_m_i _C_A_D_, _f_o_g_l_i _e_l_e_t_t_r_o_n_i_c_i_, _g_i_o_c_h_i _3_D _e _a_p_p_l_i_c_a_z_i_o_n_i _d_i _d_i_s_e_g_n_o_. _F_a_t_t_o _s_t_a_, _c_h_e _o_g_g_i _m_o_l_t_e _t_r_a _l_e _p_i_ù _p_o_p_o_l_a_r_i _a_p_p_l_i_c_a_z_i_o_n_i _p_e_r _p_c _f_a_n_n_o _u_s_o _d_i _e_n_t_r_a_m_b_e _l_e _i_s_t_r_u_z_i_o_n_i _i_n _v_i_r_g_o_l_a _m_o_b_i_l_e _e _i_n_t_e_r_e_. _C_o_m_e _r_i_s_u_l_t_a_t_o_, _C_y_r_i_x _h_a _s_c_e_l_t_o _d_i _e_n_f_a_t_i_z_z_a_r_e _i_l _"_p_a_r_a_l_l_e_l_i_s_m_o_" _n_e_l_l_a _p_r_o_g_e_t_­ _t_a_z_i_o_n_e _d_e_i _p_r_o_c_e_s_s_o_r_i _6_x_8_6 _p_e_r _v_e_l_o_c_i_z_z_a_r_e _l_e _p_r_e_s_t_a_z_i_o_n_i _d_e_i _s_o_f_t_w_a_r_e _c_h_e _m_i_s_c_h_i_a_n_o _q_u_e_s_t_i _d_u_e _t_i_p_i _d_i _i_s_t_r_u_z_i_o_n_i_. _I_l _m_o_d_e_l_l_o _d_i _e_c_c_e_z_i_o_n_e _d_e_l _f_l_o_a_t_i_n_g _p_o_i_n_t _x_8_6 _p_e_r_m_e_t_t_e _a_l_l_e _i_s_t_r_u_z_i_o_n_i _i_n_t_e_r_e _d_i _i_n_i_z_i_a_r_e _e _c_o_m_p_l_e_t_a_r_s_i _m_e_n_t_r_e _u_n _i_s_t_r_u_z_i_o_n_e _i_n _v_i_r_g_o_l_a _m_o_b_i_l_e _è _a_n_c_o_r_a _i_n _e_l_a_b_o_r_a_z_i_o_n_e_. _I_n _c_o_n_t_r_a_s_t_o_, _u_n_a _s_e_c_o_n_d_a _i_s_t_r_u_z_i_o_n_e _i_n _v_i_r_g_o_l_a _m_o_b_i_l_e _n_o_n _p_u_ò _i_n_i_z_i_a_r_e _l_a _s_u_a _e_s_e_c_u_z_i_o_n_e _m_e_n_t_r_e _u_n_a _p_r_e_c_e_d_e_n_t_e _i_s_t_r_u_z_i_o_n_e _è _a_n_c_o_r_a _i_n _e_s_e_c_u_z_i_o_n_e_. _P_e_r _r_i_m_u_o_v_e_r_e _q_u_e_s_t_o _l_i_m_i_t_e _a_l_l_e _p_r_e_s_t_a_z_i_o_n_i_, _i_l _6_x_8_6 _p_u_ò _s_p_e_c_u_l_a_r_m_e_n_t_e _i_n_i_z_i_a_r_e _f_i_n_o _a _q_u_a_t_­ _t_r_o _i_s_t_r_u_z_i_o_n_i _i_n _v_i_r_g_o_l_a _m_o_b_i_l_e _a_l_l_a _F_P_U _n_e_l _c_h_i_p _m_e_n_t_r_e _c_o_n_t_i_n_u_a _a_d _i_n_i_z_i_a_r_e _e_d _e_s_e_g_u_i_r_e _i_s_t_r_u_z_i_o_n_i _i_n_t_e_r_e_. _P_e_r _e_s_e_m_p_i_o_, _i_n _u_n_a _s_e_q_u_e_n_z_a _d_i _c_o_d_i_c_e _c_o_n _d_u_e _i_s_t_r_u_z_i_o_n_i _i_n _v_i_r_g_o_l_a _m_o_b_i_l_e _(_F_L_T_) _s_e_g_u_i_t_e _d_a _s_e_i _i_s_t_r_u_z_i_o_n_i _i_n_t_e_r_e _(_I_N_T_) _s_e_g_u_i_t_e _d_a _d_u_e _F_L_T_, _i_l _p_r_o_c_e_s_s_o_r_e _6_x_8_6 _p_u_ò _i_n_i_z_a_r_e _a_d _e_s_e_g_u_i_r_e _t_u_t_t_e _e _d_i_e_c_i _l_e _i_s_t_r_u_z_i_o_n_i _c_o_n _l_'_a_p_p_r_o_p_r_i_a_t_a _u_n_i_t_à _d_i _e_s_e_c_u_z_i_o_n_e _p_r_i_m_a _a_n_c_o_r_a _d_e_l _c_o_m_p_l_e_t_a_m_e_n_t_o _d_e_l_l_'_e_s_e_c_u_z_i_o_n_e _d_e_l _p_r_i_m_o _F_L_T_. _S_e _n_e_s_s_u_n_a _d_e_l_l_e _i_s_t_r_u_z_i_o_n_i _f_a_l_l_i_s_c_e _(_i_l _c_a_s_o _t_i_p_i_c_o_)_, _l_'_e_s_e_c_u_z_i_o_n_e _c_o_n_t_i_n_u_a _c_o_n _e_n_t_r_a_m_b_e _l_e _u_n_i_t_à _i_n_t_e_r_a _e_d _a _v_i_r_g_o_l_a _m_o_b_i_l_e _c_h_e _c_o_m_p_l_e_t_a_n_o _i_n _p_a_r_a_l_l_e_l_o _l_e _i_s_t_r_u_z_i_o_n_i_. _S_e _u_n_o _d_e_g_l_i _F_L_T _f_a_l_l_i_s_c_e _(_c_a_s_o _a_t_i_p_i_c_o_)_, _l_a _c_a_p_a_c_i_t_à _d_i _e_s_e_c_u_z_i_o_n_e _s_p_e_c_u_l_a_t_i_v_a _d_e_l _6_x_8_6 _p_e_r_m_e_t_t_e _c_h_e _l_o _s_t_a_t_o _d_e_l _p_r_o_c_e_s_s_o_r_e _s_i_a _r_e_s_t_a_u_r_a_t_o _i_n _u_n_a _m_a_n_i_e_r_a _c_h_e _s_i_a _c_o_m_p_a_t_i_b_i_l_e _c_o_n _i_l _m_o_d_e_l_l_o _d_i _e_c_c_e_z_i_o_n_e _d_e_l_l_'_x_8_6_. _L_'_e_s_a_m_e _d_e_i _t_e_s_t _d_i _b_e_n_c_h_m_a_r_k _r_i_v_e_l_a _c_h_e _i _b_e_n_c_h_m_a_r_k _s_i_n_­ _t_e_t_i_c_i _d_e_l_l_'_u_n_i_t_à _i_n _v_i_r_g_o_l_a _m_o_b_i_l_e _u_s_a_n_o _u_n _'_c_o_d_e _s_t_r_e_a_m_' _i_n _p_u_r_a _v_i_r_g_o_l_a _m_o_b_i_l_e _c_h_e _n_o_n _s_i _t_r_o_v_a _n_e_l_l_e _a_p_p_l_i_c_a_z_i_o_n_i _d_e_l _m_o_n_d_o _r_e_a_l_e_. _Q_u_e_s_t_o _t_i_p_o _d_i _b_e_n_c_h_m_a_r_k _n_o_n _t_r_a_e _v_a_n_t_a_g_g_i_o _d_a_l_l_e _p_o_s_s_i_b_i_l_i_t_à _d_i _e_s_e_c_u_z_i_o_n_e _s_p_e_c_u_l_a_t_i_v_a _d_e_i _p_r_o_c_e_s_s_o_r_i _6_x_8_6_. _C_y_r_i_x _c_r_e_d_e _c_h_e _i _b_e_n_c_h_m_a_r_k _n_o_n _s_i_n_t_e_t_i_c_i _b_a_s_a_t_i _s_u_l_l_e _a_p_p_l_i_c_a_z_i_o_n_i _d_e_l _m_o_n_d_o _r_e_a_l_e _r_i_f_l_e_t_t_a_n_o _m_e_g_l_i_o _l_e _a_t_t_u_a_l_i _p_r_e_s_t_a_z_i_o_n_i _c_h_e _g_l_i _u_t_e_n_t_i _o_t_t_e_r_r_a_n_n_o_. _L_e _a_p_p_l_i_c_a_z_i_o_n_i _d_e_l _m_o_n_d_o _r_e_a_l_e _c_o_n_t_e_n_g_o_n_o _f_u_n_z_i_o_n_i _i_n_t_e_r_e _e _a _v_i_r_g_o_l_a _m_o_b_i_l_e _m_i_s_t_e_, _e _q_u_i_n_d_i _b_e_n_e_f_i_c_i_e_r_a_n_n_o _d_e_l_l_a _c_a_p_a_c_i_t_à _d_i _e_s_e_c_u_z_i_o_n_e _s_p_e_c_u_l_a_t_i_v_a _d_e_l _6_x_8_6_" Così la recente moda nel benchmarking è di scegliere applicazioni comuni ed usare queste per provare le prestazioni di un computer completo. Per esempio, SSPPEECC, 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. 22..11..22.. BBeenncchhmmaarrkk ddii aallttoo lliivveelllloo ccoonnttrroo qquueellllii ddii bbaassssoo lliivveelllloo 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. 22..22.. BBeenncchhmmaarrkk ssttaannddaarrdd ddiissppoonniibbiillii ppeerr LLiinnuuxx 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 iinnddiivviidduuaallee 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: _"_G_l_i _o_r_i_g_i_n_a_l_i _e _l_e_g_g_e_r_m_e_n_t_e _m_o_d_i_f_i_c_a_t_i _B_Y_T_E _U_n_i_x _b_e_n_c_h_m_a_r_k_s _s_o_n_o _r_o_t_t_i _i_n _u_n _n_u_m_e_r_o _t_a_l_e _d_i _m_o_d_i _c_h_e _f_a_n_n_o _d_i _l_o_r_o _u_n _i_n_d_i_c_a_t_o_r_e _s_t_r_a_n_a_m_e_n_t_e _n_o_n _s_t_a_b_i_l_e _d_e_l_l_e _p_e_r_f_o_r_m_a_n_c_e _d_e_l _s_i_s_t_e_m_a_. _I_n_t_e_n_z_i_o_n_a_l_m_e_n_t_e _h_o _f_a_t_t_o _s_e_m_b_r_a_r_e _i _m_i_e_i _v_a_l_o_r_i _i_n_d_i_c_e _m_o_l_t_o _d_i_f_f_e_r_e_n_t_i _p_e_r _e_v_i_t_a_r_e _c_o_n_f_u_s_i_o_n_i _c_o_n _i _v_e_c_c_h_i _b_e_n_c_h_m_a_r_k_s_._" 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 majordomo@wauug.erols.com . Il Washington Area Unix User Group è anche in procinto di mettere su un Sito Web per i benchmark Linux. Inoltre recentemente, Uwe F. Mayer, 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 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. 22..33.. CCoolllleeggaammeennttii ee rriiffeerriimmeennttii 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 5566 ddiiffffeerreennttii bbeenncchhmmaarrkk, 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: _"_L_i_n_u_s _e _D_a_v_i_d _M_i_l_l_e_r _l_a _u_s_a_n_o _m_o_l_t_o _p_e_r_c_h_é _f_a _m_o_l_t_e _u_t_i_l_i _m_i_s_u_r_a_z_i_o_n_i _d_i _b_a_s_s_o _l_i_v_e_l_l_o _e _p_u_ò _a_n_c_h_e _m_i_s_u_r_a_r_e _i_l _t_h_r_o_u_g_h_p_u_t _d_i _r_e_t_e _e _l_a _l_a_t_e_n_z_a _s_e _s_i _h_a_n_n_o _2 _s_i_s_t_e_m_i _d_a _t_e_s_t_a_r_e_. Un Sito FTP piuttosto completo per benchmark lliibbeerraammeennttee disponibili è stato messo su da Alfred Aburto. La Whetstone suite usata nell'LBT può essere trovata a questo sito. C'è una FFAAQQ iinn ppiiùù ppaarrttii ddii EEuuggeennee MMiiyyaa che viene postata regolarmente su comp.benchmarks; è un eccellente punto di riferimento. 33.. TThhee LLiinnuuxx BBeenncchhmmaarrkkiinngg TToooollkkiitt ((LLBBTT)) 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. 33..11.. RRaazziioonnaallee 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 ssiinntteettiiccoo dovrebbe impiegare il relativo sottosistema alla sua massima capacità. 6. I risultati dei benchmark ssiinntteettiiccii nnoonn 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 33..22.. SSeelleezziioonnee ddeeii bbeenncchhmmaarrkk 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. 33..33.. DDuurraattaa ddeeii tteesstt 1. Kernel 2.0.0, compilazione: da 5 a 30 minuti, dipende dalle rreeaallii 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. 33..44.. CCoommmmeennttii 33..44..11.. CCoommppiillaazziioonnee KKeerrnneell 22..00..00:: · CCooss''èè:: È 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 nnoonn 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. · RRiissuullttaattii:: tempo di compilazione in minuti e secondi (per favore, è inutile riportare le frazioni di secondo). 33..44..22.. WWhheettssttoonnee:: · CCooss''èè:: 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. · RRiissuullttaattii:: un indice delle prestazioni dell'unità in virgola mobile in MWIPS. 33..44..33.. XXbbeenncchh--00..22:: · CCooss''èè:: 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. · RRiissuullttaattii:: le prestazioni di X misurate in xStones. · Nota: questo test, così com'è è obsoleto. Dovrebbe essere ricodificato 33..44..44.. UUnniixxBBeenncchh vveerrssiioonnee 44..0011:: · CCooss''èè:: 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. · RRiissuullttaattii:: un indice di sistema. 33..44..55.. BBYYTTEE MMaaggaazziinnee''ss BBYYTTEEmmaarrkk bbeenncchhmmaarrkkss:: · CCooss''èè:: fornisce una buona misurazione delle prestazioni del processore. Questo è un estratto dalla documentazione: _"_q_u_e_s_t_i _b_e_n_c_h_m_a_r_k _h_a_n_n_o _l_a _f_u_n_z_i_o_n_e _d_i _m_o_s_t_r_a_r_e _i_l _l_i_m_i_t_e _s_u_p_e_r_i_o_r_e _t_e_o_r_i_c_o _d_i _C_P_U_, _F_P_U _e _a_r_c_h_i_t_e_t_t_u_r_a _d_i _m_e_m_o_r_i_a _d_i _u_n _s_i_s_t_e_m_a_. _N_o_n _p_o_s_s_o_n_o _m_i_s_u_r_a_r_e _i_l _v_i_d_e_o_, _i _d_i_s_c_h_i _o _i_l _t_h_r_o_u_g_h_p_u_t _d_e_l_l_a _r_e_t_e _(_q_u_e_s_t_i _s_o_n_o _d_o_m_i_n_i_o _d_i _u_n_'_a_l_t_r_o _s_e_t _d_i _b_e_n_c_h_m_a_r_k_)_. _S_i _d_o_v_r_e_b_b_e_, _c_o_m_u_n_q_u_e_, _u_s_a_r_e _i_l _r_i_s_u_l_t_a_t_o _d_i _q_u_e_s_t_i _t_e_s_t _c_o_m_e _u_n_a _p_a_r_t_e _d_i _u_n _p_r_o_c_e_s_s_o _d_i _m_i_s_u_r_a_z_i_o_n_e _d_i _u_n _s_i_s_t_e_m_a_, _n_o_n _c_o_m_e _t_u_t_t_o _i_l _p_r_o_c_e_s_s_o_._" · 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'iinnddiiccee ddii mmeemmoorriiaa ; calcolare la media geometrica degli indici della prova di NUMERIC SORT, IDEA, HUFFMAN and FP EMULATION ; questo è l'iinnddiiccee iinntteerroo. · RRiissuullttaattii:: un indice di memoria e un indice intero calcolato come spiegato. 33..55.. MMiigglliioorraammeennttii ppoossssiibbiillii 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. 33..66.. MMoodduulloo LLBBTT 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. ______________________________________________________________________ 33..77.. TTeesstt ddeellllee pprreessttaazziioonnii ddeellllaa rreettee 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) 33..88.. TTeesstt ddeeggllii SSMMPP ((MMuullttii pprroocceessssoorrii ssiimmmmeettrriiccii)) 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, _" _._._. _s_h_e_l_l_8[parte degli Unixbench 4.01 benchmaks] _s_v_o_l_g_e _u_n _b_u_o_n _l_a_v_o_r_o _n_e_l _c_o_n_f_r_o_n_t_a_r_e _c_o_m_b_i_n_a_z_i_o_n_i _s_i_m_i_l_i _d_i _h_a_r_d_w_a_r_e _e _s_i_s_t_e_m_i _o_p_e_r_a_t_i_v_i _n_e_i _m_o_d_i _S_M_P _e _U_P_" 44.. EEsseemmppii ddii eesseeccuuzziioonnee ee rriissuullttaattii 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! 55.. TTrraappppoollee ee iinneessaatttteezzzzee ddeell bbeenncchhmmaarrkkiinngg Dopo aver messo insieme questo HOWTO ho iniziato a comprendere come le parole "trappole" e "inesattezze" siano così spesso associate al benchmarking... 55..11.. PPaarraaggoonnaannddoo mmeellee ee aarraannccee 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. 55..22.. IInnffoorrmmaazziioonnii iinnccoommpplleettee 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. 55..33.. HHaarrddwwaarree//ssooffttwwaarree pprroopprriieettaarriioo 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). 55..44.. RRiilleevvaannzzaa 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, nnoonn citare le prestazioni dell'unità in virgola mobile, o altre informazioni irrilevanti. In molti casi meno è meglio. Allo stesso modo, nnoonn c'è bisogno di menzionare gli anni del tuo gatto, il tuo stato d'animo mentre stavi effettuando il test, ecc... 66.. FFAAQQ ((DDoommaannddee FFrreeqquueennttii)) DD11.. C'è un qualsiasi indice di merito per i sistemi Linux? AA:: 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. DD22.. Quindi perché non una dozzina di indici riassumenti le prestazioni di diversi sistemi Linux? AA:: Sarebbe la situazione ideale. Vorrei vedere ciò diventare realtà. Nessun volontario per un LLiinnuuxx BBeenncchhmmaarrkkiinngg PPrroojjeecctt? Con un sito web e un database completo e ben progettato? DD33.. ... BogoMips ...? AA:: I BogoMips non hanno nniieennttee a che fare con le prestazioni del sistema. Leggere il BogoMips Mini-HOWTO. DD44.. Qual è il miglior benchmark per Linux? AA:: 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. DD55.. Qual è il processore più veloce sotto Linux? AA:: 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 $. DD66.. Fammi riformulare l'ultima domanda, allora: c'è un processore che è il più veloce per applicazioni generiche? AA:: Questa è una domanda trabocchetto ma ha una sola e semplice risposta: NNOO. 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 ... DD77.. Ma allora la frequenza di clock influenza le prestazioni di un sistema? AA:: 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. DD88.. 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? AA:: 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 ... DD99.. Quando un aumento delle prestazioni è considerato "significativo"? AA:: 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. DD1100.. Come posso ottenere "significativi" aumenti nelle prestazioni al costo minore? AA:: 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 ssii ddoovvrreebbbbee cchhiiaammaarree uunn ccoonnssuulleennttee LLiinnuuxx. Vedere il Consultants-HOWTO. 77.. CCooppyyrriigghhtt,, rriiccoonnoosscciimmeennttii ee vvaarriiee 77..11.. CCoommee èè ssttaattoo ssccrriittttoo qquueessttoo ddooccuummeennttoo:: 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: LLyyXX ee SSGGMMLL--TToooollss. 77..22.. CCooppyyrriigghhtt 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. 77..33.. NNuuoovvee vveerrssiioonnii ddii qquueessttoo ddooccuummeennttoo 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. 77..44.. CCoommmmeennttii ee ccrriittiicchhee Sono richiesti suggerimenti, correzioni e aggiunte. Si cercano contributi e riscontri. Non si cercano flame. Posso sempre essere raggiunto a andrewbalsa@usa.net. 77..55.. RRiiccoonnoosscciimmeennttii 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. 77..66.. DDiissccllaaiimmeerr Your mileage may, and will, vary. Be aware that benchmarking is a touchy subject and a great time-and-energy consuming activity. 77..77.. MMaarrcchhii rreeggiissttrraattii 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à. :)