Guida per eseguire un test di benchmark del computer significativo per la produttività

I programmi di benchmark tentano di analizzare le "prestazioni" di un computer basandosi su un test bed ben definito (normalmente neanche lontanamente simile alla configurazione finale del computer). Il benchmark può sfruttare dei limiti da confrontare, come le risorse di sistema, l'ambiente software virtuale, le applicazioni, la simulazione del carico di elaborazione, la simulazione del carico dell'utente e la simulazione dell'utilizzo del sistema, tra gli altri; e fare tutto ciò che è necessario per superare tali limiti e dare un risultato discutibile. Ora, "avere un benchmark standard del settore è sempre una buona cosa, se i benchmark non sono truccati. Purtroppo, molti benchmark del settore sono truccati. […] Eppure molte organizzazioni sembrano acquistare hardware basandosi sui benchmark piuttosto che comprendere i propri carichi di lavoro e acquistare hardware in base ai propri requisiti e, naturalmente, al budget." (Newman, 2015) Questo spiega perché il cliente deve sapere esattamente cosa si intende misurare. Un programma di benchmark non sarà mai in grado di riflettere la cosiddetta esperienza nel mondo reale; rifletterà solo quanto bene tale programma gira nel computer previsto. Quindi è responsabilità del cliente determinare come il risultato verrà applicato nel suo ambiente produttivo.

Sorprendentemente, eseguire correttamente i benchmark è qualcosa di molto difficile, perché ci sono molte possibilità di ottenere risultati negativi o fuorvianti e di omettere delle cose. Il white paper “A Nine Year Study of File System and Storage Benchmarking” lo riassume così:

In questo articolo esaminiamo 415 benchmark di file system e archiviazione da 106 documenti recenti. Abbiamo scoperto che la maggior parte dei benchmark popolari sono errati e molti documenti di ricerca non forniscono una chiara indicazione delle prestazioni reali. (Traeger, Zadok, Joukov, & Wright, 2008)

In tale white paper si possono vedere dichiarazioni sul fatto che i benchmark dovrebbero spiegare cosa sta per essere testato e perché, e dovrebbero anche fare (o facilitare) una sorta di analisi delle prestazioni di sistema previste.

Nell'articolo “Performance Anti-Patterns”, ci sono alcuni punti evidenziati per determinare, in questo caso, per cosa e come i benchmark dovrebbero essere eseguiti. Pertanto, un buon benchmark dovrebbe essere:

• Ripetibile, in modo che gli esperimenti di confronto possano essere condotti in modo relativamente semplice e con un ragionevole grado di precisione.
• Osservabile, così che se si riscontrano scarse prestazioni, lo sviluppatore abbia un punto da cui iniziare a cercare. Niente è più frustrante di un benchmark complesso che fornisce un singolo numero, lasciando lo sviluppatore senza alcuna informazione aggiuntiva su dove potrebbe risiedere il problema.
• Portabile, in modo che i confronti siano possibili con i tuoi principali concorrenti (anche se si tratta delle tue versioni precedenti). Mantenere una cronologia delle prestazioni delle versioni precedenti è un valido aiuto per comprendere il proprio processo di sviluppo.
• Facilmente presentabile, in modo che tutti possano comprendere i confronti in una breve presentazione.
• Realistico, in modo che le misurazioni riflettano le realtà vissute dai clienti.
• Eseguibile, in modo che tutti gli sviluppatori possano verificare rapidamente gli effetti delle loro modifiche. Se ci vogliono giorni per ottenere risultati sulle prestazioni, non succederà molto spesso.

Non tutti i benchmark selezionati soddisferanno tutti questi criteri, ma è importante che alcuni di essi lo facciano. Smaalders invita a scegliere benchmark che rappresentino realmente le esigenze del cliente o tutti gli sforzi finiranno per ottimizzare per il comportamento sbagliato. Incoraggia anche a resistere alla tentazione di ottimizzare per il benchmark con l'obiettivo di vincere il concorso a ogni costo. Tale comportamento offrirà risultati falsi che potrebbero portare a una mancanza di fiducia nel marchio o nel fornitore. Generalmente, un benchmark evidenzierà l'aspetto ottimizzato, a scapito di altri aspetti che non vengono misurati (e che potrebbero essere importanti per il cliente). (Smaalders, 2006)

C'è un'altra cosa quando si confrontano vari sistemi con l'intenzione di acquistarli: il rapporto prezzo/prestazioni. Questo tasso può essere quantificato includendo il costo capitale a 5 anni dell'apparecchiatura. (Anon & Gray, 1985)

I test semplici con software di benchmark non comprendono un'analisi completa delle prestazioni. I programmi di benchmark normalmente lavorano in un ambiente controllato, quindi possono essere manipolati per ottenere un tasso desiderato, il più alto possibile. Tuttavia, tale tasso NON ci darà mai una corretta correlazione con l'effettiva esperienza del cliente. Piuttosto, le metriche fornite ti offrono solo un punteggio rappresentativo di quanto bene funzioni su un particolare benchmark. Un grosso problema è che l'utente non sa mai veramente cosa viene testato, come vengono misurati gli aspetti di un punteggio di benchmark, quali flag sono stati impostati nel compilatore, quale codice o librerie sono alla base del programma e, cosa ancora più importante, se ciò che il programma sta testando rifletterà il reale uso previsto per il computer. Ci sono, quindi, alcuni punti da rimarcare:

• Un benchmark non rifletterà mai l'uso nel mondo reale. Essendo un programma completamente automatizzato, aprirà, scriverà, imposterà, leggerà, salverà, mostrerà, guarderà, navigerà, sposterà, calcolerà, assegnerà ed eseguirà molte altre attività in modo completamente automatico. Tale modo non rifletterà mai il ritmo con cui un essere umano svolgerà il proprio lavoro. Pertanto, qualsiasi programma di benchmark che prometta risultati basati sull'utilizzo nel mondo reale sta mentendo.

• Non tutti i benchmark valutano le prestazioni multitasking. La stragrande maggioranza dei benchmark valuta solo attività eseguite in serie. Testano una cosa e, poi, la successiva. Non metteranno mai un'applicazione a fare qualcosa mentre un'altra applicazione sta facendo qualcos'altro (e, se lo fanno, normalmente provano due o, al massimo, tre istanze). Nella vita reale, gli utenti eseguono più applicazioni contemporaneamente. La maggior parte degli utenti apre molte applicazioni alla volta (anche il sistema operativo esegue molte attività mentre svolgiamo le nostre attività quotidiane). Vale la pena ricordare che un benchmark che riflette solo un processo/applicazione non scala linearmente con il secondo, il terzo e il resto dei processi/applicazioni. Pertanto, nella moderna tecnologia multicore, è importante prendere i risultati di un programma di benchmark con cautela.

• "Tasso" non è la stessa cosa di "prestazioni". Il tasso è solo un numero dato dal programma. Le prestazioni sono qualcosa di più complicato. Il numero del tasso dipende dal programma di benchmark e dalla scala stabilita dai suoi sviluppatori. Le prestazioni sono il compimento di una data attività misurato rispetto a standard preimpostati e noti di accuratezza, completezza, costo e velocità (The Business Dictionary, 2017). Pertanto, nessun tasso di programma di benchmark riflette un indice di prestazioni.

• I benchmark sono inaccurati. La variazione in un tasso di un programma di benchmark può arrivare fino al 10% (a volte, di più). Questi tassi di benchmark sono sempre soggettivi, il che è contrario ai principi oggettivi della scienza e della tecnologia. Ecco perché un programma di benchmark dovrebbe essere eseguito almeno 3 volte per calcolare una media del tasso fornito. Dopo aver determinato la media, è prevista almeno una variazione del +/-3% del risultato (tale variazione può essere calcolata in base ai risultati raccolti).

• I risultati dei benchmark possono essere manipolati. Ci sono modi per manipolare i risultati di un programma di benchmark e offrire tassi artificialmente alti solo per impressionare l'utente. Questo può essere fatto attraverso molte tecniche, come modifiche eccessive, impostazioni nel BIOS, alterazione dell'hardware, uso di cacciaviti speciali, manipolazione del codice e altri. I tassi di benchmark potrebbero essere ottenuti con impostazioni irrealistiche rispetto a come il computer verrà utilizzato in pratica: il sistema deve essere privo di programmi e processi e avere valori specifici che dipendono dal particolare benchmark, e questo non riflette il modo in cui il computer verrà utilizzato nella produttività. Come ha affermato Henry Newman: "Ciò che ci dice un benchmark è: 1) Quanta parte hardware un fornitore può stipare in una scatola, 2) Quanto bene il team del fornitore può ottimizzare il software [per il benchmark] e, 3) Quanto male il fornitore vuole l'affare." (Olds & OrionX, 2011) Se non c'è un protocollo di benchmark chiaramente stabilito dal cliente, la porta sarà aperta per qualsiasi trucco che il benchmarker può fare per raggiungere (o superare) i risultati desiderati e impressionare il cliente.

Alla fine, un programma di benchmark non è uno strumento preciso e dovrebbe essere usato con cautela. Come ha citato Henry Newman in una comunicazione personale, "Confrontare gli strumenti di prestazione del sistema […] con […] i benchmark è come confrontare le mele con i maiali volanti." (Carrier, 2012)

I punteggi forniti da un benchmark dovrebbero essere utilizzati insieme ad altri benchmark e dettagli aggiuntivi per ottenere una comprensione completa delle prestazioni complessive del sistema. Il benchmark, nel migliore dei casi, sta solo "misurando la velocità" di un computer, ma ci sono molti altri aspetti da prendere in considerazione: standard commerciali, standard militari, funzionalità, caratteristiche, certificazioni, prezzo, tra gli altri.

Se il computer valutato per l'acquisto deve soddisfare una varietà di diversi requisiti dell'utente, è meglio predeterminare i casi d'uso previsti in modo da stabilire una serie dettagliata di criteri di qualificazione appropriati. Nella maggior parte dei casi, il computer sarà probabilmente utilizzato in uno o più dei seguenti contesti:

• Sarà utilizzato con attuali ambienti operativi grafici (Windows 10, o distribuzioni GNU/Linux almeno)
  • O se sarà utilizzato con versioni precedenti di sistemi operativi, come Windows 7 o Windows 8.1, o una precedente distribuzione GNU/Linux.
• Produttività di base (Non più di 5 applicazioni in esecuzione, tra cui):
  • Antivirus
  • Elaborazione testi
  • Email
  • Uso leggero di fogli di calcolo
  • Applicazioni basate sul web
  • Navigazione web con non più di 6 schede aperte.
• Produttività standard (Da 5 a 10 applicazioni in esecuzione, tra cui):
  • Come per la Produttività di base, e anche…
  • Applicazioni Office (Elaborazione testi con manipolazione di immagini, fogli di calcolo con formule e alcuni script, Presentazioni, Gestione database di base)
  • Navigazione web con un massimo di 15 schede
  • Conferenze web
  • Visualizzazione e modifica semplice di immagini e video
  • Istruzione
  • Si può presumere un uso copioso di video, immagini, animazioni, accesso al web e applicazioni che attualmente utilizzano l'informatica accelerata.
• Power User (Più di 10 applicazioni in esecuzione, tra cui):
  • Come per la Produttività standard, e anche…
  • Sviluppo di applicazioni
    • Utilizzo di linguaggi e ambienti di programmazione
    • Creazione, gestione e test di database
    • Test bed con virtualizzazione
    • Ambienti di test controllati
  • Programmi per la ricerca scientifica
    • Applicazioni specializzate
    • Applicazioni ingegneristiche e scientifiche
    • Realtà virtuale
• Solo per conoscenza generale, i giochi sono attualmente considerati calcolo ad alte prestazioni (Stevenson, Le Du, & El Afrit, 2011)
• Altri criteri
  • È richiesto un basso consumo energetico?
  • È importante o limitato lo spazio occupato dal computer?
  • È richiesta la mobilità?
  • È importante la durata della batteria?
  • Il peso è importante?
  • Alcuni altri usi che implicano un uso portatile in ambienti difficili, polverosi o rumorosi

Il termine nel titolo di questa sezione può sembrare strano, ma in realtà è una questione che viene generalmente ignorata o trascurata. Si riferisce alla seguente domanda: Quale tempo di risposta conta davvero per l'utente? Velocità e prestazioni sono in realtà termini relativi. Ilya Grigorik propone un concetto interessante di cosa significhi la parola "prestazioni".

"Le prestazioni non sono solo millisecondi, fotogrammi e megabyte. È anche come questi millisecondi, fotogrammi e megabyte si traducono in come l'utente percepisce l'applicazione." (Grigorik, 2014)

Ogni applicazione prescrive il proprio insieme di requisiti in base a criteri aziendali, contesto, aspettative dell'utente e costanti di tempo di elaborazione percettiva interamente orientate all'utente. Ancora una volta, le aspettative dell'utente hanno una relazione con la prima legge di Maister; "La soddisfazione è uguale alla percezione meno l'aspettativa." (Maister, 1985) Non importa quanto la vita accelera, o almeno viene percepita come un'accelerazione (1 fotogramma ogni 66ms), i nostri tempi di reazione rimangono costanti. Se consideriamo che un utente può vedere circa 15 fotogrammi al secondo secondo gli studi tradizionali (Thorpe, Fize, & Marlot, 1996), la seguente tabella (basata sullo standard militare 1472G) fornisce una chiara idea del tempo di risposta che un utente si aspetta normalmente. Questo indipendentemente dal tipo di applicazione (installata sul computer o online) o dal supporto (laptop, desktop o dispositivo mobile).

Tempo effettivo e percezione dell'utente (Seow, 2008)

• 0 – 100 ms: Istantaneo
• 100 – 500 ms: Immediato
• 500 – 1000 ms: Veloce
• 1 – 10 s: Si percepisce un ritardo, ma l'utente non perde la concentrazione.
• +10 s: Il computer è troppo lento per mantenere l'attenzione dell'utente.

Affinché la risposta a una richiesta dell'utente sia percepita come veloce, deve arrivare in meno di un secondo. Se ci vuole un secondo o più, l'utente potrebbe percepire un certo ritardo, ma la sua attenzione non verrà distolta dall'attività. Dopo 10 secondi, a meno che il programma non fornisca un qualche tipo di informazione all'utente, l'attività verrà normalmente abbandonata e l'utente proverà fastidio. Se il computer valutato può fornire risposte in tempi comparabili o in meno di 10 secondi, l'utente otterrà di più dal computer. Queste soglie sono molto più utili nel mondo reale rispetto ai risultati dei programmi di benchmark, che non offrono una guida chiara sui loro significati.

Detto questo, in un benchmark efficace il cliente dovrebbe sapere: come applicarlo, l'analisi e le conclusioni che se ne otterranno. Per l'analisi, è importante comprendere o portare:

• Una soglia o riferimento del risultato minimo atteso
• Cosa sta per essere testato
• Quali sono i fattori limitanti
• Qualsiasi perturbazione che potrebbe influenzare i risultati
• I dettagli del sistema testato
• Il prezzo (almeno, la media) del sistema testato
• Quali conclusioni si cercano di raggiungere con i risultati

La soglia può essere ottenuta da siti pubblici (come Futuremark) o può essere creata localmente da un computer attualmente in uso e con una buona configurazione al fine di impostare la base di riferimento per ogni benchmark dai computer che stanno per essere offerti. Annota i dettagli della configurazione di questo computer utilizzato come base di riferimento (processore, memoria [quantità, velocità, configurazione, temporizzazioni], archiviazione, grafica e monitor) per averne un'idea chiara.

L'analisi dei benchmark richiede tempo ed esperienza per essere eseguita correttamente. Come detto, la parte più importante è determinare cosa sta per essere misurato e se i risultati ottenuti sono significativi per l'uso previsto dei computer.

Di seguito è riportato un protocollo di benchmarking proposto al fine di garantire, per quanto possibile, risultati equi e realistici dei benchmark selezionati o applicati.

Si raccomanda che i processi di configurazione e benchmarking non lascino il benchmarker da solo, specialmente se il benchmarker è una parte terza. Il cliente deve assegnare un testimone per annotare tutto ciò che il benchmarker fa con la macchina per configurarla per il processo di benchmark. Inoltre, il testimone dovrebbe anche notare eventuali modifiche o alterazioni che il benchmarker effettua dopo ogni tipo di test di benchmark. Se tu, come cliente, hai un protocollo ben definito, allora il benchmarker non deve violarlo solo per vincere il processo di benchmark. Il benchmarker e il testimone non dovrebbero essere la stessa persona, ancora una volta specialmente se il benchmarker è una parte terza.

Indipendentemente dal marchio o dall'hardware offerto, tutti i computer dovrebbero soddisfare i criteri di configurazione:

• Se hai richiesto processori quad-core fisici, tutti dovrebbero avere quattro core fisici.
• Se hai richiesto una certa quantità, velocità e configurazione di RAM, verifica che tutti i computer abbiano la stessa configurazione. Annota eventuali differenze:
  • Dimensione
  • Velocità (MT/s)
  • Temporizzazioni e latenze (CAS, RAS, tRAS, tRC, Frequenza).
  • Canale singolo vs Dual Channel
• Se hai richiesto un certo tipo di archiviazione, verifica che tutti i computer includano tale tipo di archiviazione. Annota eventuali differenze riscontrate (throughput, tempi di ricerca e tempi di scrittura):
  • Hard Disk rotazionale standard (5400RPM, 7200RPM, 10000RPM, SSHD)
  • SSD
• La scheda video dovrebbe soddisfare Shader Model 6.1 (DirectX 12.1) per Windows 10 o Shader Model 5 (DirectX 11) per versioni precedenti di Windows.
• Il monitor dovrebbe soddisfare le stesse caratteristiche in ogni computer
  • Tempi di aggiornamento
  • Tempi di risposta (ms)
  • Risoluzione (risoluzioni più elevate potrebbero portare a numeri di benchmark inferiori)
  • Profondità di colore
• Il sistema operativo dovrebbe essere della stessa versione e compilazione.
  • In Windows puoi vedere la versione e la compilazione digitando winver e Invio nella casella Cortana o dopo aver premuto Windows+R per richiamare la finestra Esegui.
• Ogni computer dovrebbe avere installato solo i driver correnti approvati dal produttore del computer. Nota: Non consentire l'uso di cacciaviti speciali o driver modificati forniti da un produttore di componenti, poiché potrebbero portare a risultati falsi. Evita l'uso di driver diversi da quelli convalidati e pubblicamente disponibili nel sito web o nello strumento di configurazione del produttore del computer.
• Configura il computer in modalità Bilanciata. Questo è il modo in cui i computer sono destinati ad essere utilizzati dal cliente, ed è il modo più fedele per ottenere risultati dai benchmark.
• Installa le applicazioni comunemente utilizzate dal cliente. Non importa che non verranno utilizzate nel test, è il modo in cui i computer verranno utilizzati.
• Installa qualsiasi altro software (come antivirus e strumenti) richiesto dal cliente. Questo imposterà la configurazione il più vicino possibile a quella che l'utente finale utilizzerà.
• Installa i programmi di benchmark.

Una volta installati i computer, si consiglia di eseguire un hot benchmarking. Un hot benchmarking richiede un ingegnere (Ingegnere, non un tecnico) che prenda nota di tutto ciò che sta accadendo durante il processo di benchmark (parti saltate del test, passaggi mancanti, malfunzionamenti dello schermo, figure o immagini disegnate male, e così via). Tali anomalie dovrebbero essere annotate e segnalate. È consigliabile evitare il cold benchmarking (eseguire semplicemente il benchmark, allontanarsi dal computer e, quindi, tornare solo per annotare il risultato) perché non verrebbe notata alcuna prova di comportamento strano durante il benchmark. Come affermato, ci sono modi per manipolare i tassi di benchmark ed eseguire un cold benchmark è il modo migliore per perdere questo tipo di pratiche.

Poiché i tassi di benchmark potrebbero portare a variazioni dal 5 al 15%, si raccomanda di eseguire ogni test almeno 3 volte. Ogni volta richiederà un riavvio del computer, attendere circa 5 minuti dopo che appare il desktop e, quindi, eseguire di nuovo il benchmark. Dopo ogni esecuzione di benchmark, si raccomanda di fare un'acquisizione dello schermo del risultato per salvare la prova. Questo dovrebbe essere fatto in ogni programma di benchmark selezionato.

Spetta al cliente decidere se i diversi tassi ottenuti attraverso ogni esecuzione di ogni benchmark verranno mediati, o prendendo il valore più alto o più basso. Qualunque decisione prenda il cliente, è raccomandato applicarla a tutti i diversi benchmark utilizzati. Come suggerimento, scegli la media.

Dopo aver ottenuto tali risultati, questi possono essere normalizzati (come nel corpo di questo documento) e, quindi, convertiti linearmente in tempi. Con il prezzo dei computer, il cliente può anche valutare quale dei sistemi offre il miglior rapporto prezzo/prestazioni.

Un processo di benchmarking richiede tempo, esperienza e pazienza. Se ben fatti, i programmi di benchmark possono dare una buona idea delle prestazioni previste del computer. Tutto ciò che viene annotato dal testimone sarà utile per determinare cosa il concorrente dovrà fornire in caso di selezione. La configurazione (processore, RAM [quantità, velocità, temporizzazioni, modalità canale], archiviazione [tipo, throughput, capacità], monitor, fattore di forma, ecc.) annotata durante il processo di benchmarking sarà utile per garantire che il computer consegnato sia configurato esattamente come testato. Questo è importante perché alcuni fornitori abusivi possono consegnare un computer configurato appositamente solo per il processo di test, e uno molto diverso alla fine. Pertanto, questo aiuterà il cliente ad ottenere esattamente ciò che è stato testato.

Da tutta la discussione precedente, si può concludere quanto segue:

• Gli acquisti che il cliente sta facendo sono per computer, non solo per un processore o un determinato componente. È quindi necessario tenere conto del sistema complessivo (olisticamente) quando si prende una decisione di acquisto.
• Le prestazioni di un computer derivano da tutti i suoi elementi. Questo include hardware e software. Le prestazioni complessive del computer saranno sempre uguali alle prestazioni del suo elemento più lento.
• È necessario tenere conto delle misure di risparmio energetico, della generazione di calore, della stabilità del computer, delle sue certificazioni per uso aziendale e dei servizi di sicurezza che offre. Più che la semplice velocità basata sui benchmark, la tecnologia attuale richiede che vengano forniti un consumo energetico ridotto e servizi di sicurezza.
• È importante essere consapevoli del fatto che le nuove tecnologie integrate nelle applicazioni e nei sistemi operativi sfruttano molto più del semplice processore. Piuttosto, si concentrano maggiormente su altri componenti come la CPU, la GPGPU, i bus, la velocità della RAM e la velocità di trasferimento del disco.

Una vera misura della potenza di calcolo si ottiene quando il computer viene misurato olisticamente, non solo nell'area dell'elaborazione seriale o della CPU. Il cliente che utilizza strumenti per ufficio, browser web, compressione file, lettori video, strumenti di teleconferenza, applicazioni basate sul web e cose simili trarrà vantaggio da tutte le caratteristiche di queste nuove tecnologie con architettura eterogenea.

Una nota finale a riguardo è che una soglia o un riferimento è sempre necessario per avere un'idea migliore dei miglioramenti delle prestazioni che si stanno per ricevere. Se non vuoi utilizzare la misura di base offerta da FutureMark per un “Reference Office PC” fino alla data attuale, puoi misurare il tuo computer di base nel tuo ufficio in base ai tuoi criteri (forse, un computer con cui ti senti a tuo agio con le sue prestazioni standard). Una volta eseguito il benchmark per ottenere i suoi risultati, puoi, quindi, utilizzare tali risultati come soglia per avere un minimo di tassi attesi delle soluzioni offerte. Solo un'altra cosa da notare è che i "tassi" non sono la stessa cosa delle "prestazioni". Un "tasso" fornisce solo una qualificazione dei processi eseguiti dal programma di benchmark. Le "prestazioni" sono il risultato reale che otterrai mentre utilizzi tale computer nelle tue attività.

Anon, E. A., & Gray, J. (Febbraio, 1985). A Measure of Transaction Processing Power. Recuperato il 22 marzo 2015, da Internet Archive: https://archive.org/details/bitsavers_ta...

Carrier, J. (24 aprile 2012). HPCS I/O Scenarios. Recuperato da OpenSFS: http://cdn.opensfs.org/wp-content/upload...

Computerhope. (15 marzo 2015). Thrashing. Recuperato da Computer hope: http://www.computerhope.com/jargon/t/thr...

Gregg, B. (2014). Systems Performance Enterprise and the Cloud (1 ed.). USA: Pearson Education.

Grigorik, I. (12 marzo 2014). Speed, Performance, and Human Perception. (Fluent, Ed.) San Francisco, CA, USA. Recuperato il 22 marzo 2015, da https://www.youtube.com/watch?v=7ubJzEi3...

Hoff. (30 dicembre 2006). Multicore, SMP and SMT Processors. Recuperato il 22 marzo 2015, da HoffmanLabs: http://labs.hoffmanlabs.com/node/13

Maister, D. (1985). The Psychology of Waiting Lines. (T. S. Encounter, Ed.) Recuperato il 22 marzo 2015, da David Maister: Professional Business, Professional Life: http://davidmaister.com/wp-content/theme...

Mallik, A. (2007). Hollistic Computer Architectures based on Application, User, and Process Characteristics. Evanston, Illinois, USA: UMI.

Newman, H. (2015). Data Storage Issues: Big Data Benchmarking. Recuperato da InfoStor: http://www.infostor.com/index/blogs_new/...

Olds, D., & OrionX. (19 dicembre 2011). Benchmarks are $%#&@!! Recuperato da The Register: http://www.theregister.co.uk/2011/12/19/...

Osterhage, W. (2013). Computer Performance Optimization (1 ed.). (Springer-Verlag, Trans.) Niederbachem, Germany: Springer-Verlag Berlin Heidelberg.

Seow, S. (2008). Designing and Engineering Time. Boston, USA: Prentice Hall.

Smaalders, B. (23 febbraio 2006). Performance Anti-Patterns. doi:1542-7790/06/0200

Stevenson, A., Le Du, Y., & El Afrit, M. (Marzo, 2011). High Performance Computing on Gamer PCs. Recuperato da ArsTechnica: http://arstechnica.com/science/2011/03/h...

The Business Dictionary. (2017). Performance. Recuperato da The Business Dictionary: http://www.businessdictionary.com/defini...

Thorpe, S., Fize, D., & Marlot, C. (6 giugno 1996). Speed of processing in the human visual system. Nature, 381, 520-522. Recuperato da Quora: http://cns.bu.edu/Profiles/Mingolla.html...

Traeger, A., Zadok, E., Joukov, N., & Wright, C. (2008, Maggio). A Nine Year Study of File System and Storage Benchmarking. Recuperato il 22 marzo 2015, da File systems and Storage Lab (FSL): http://www.fsl.cs.sunysb.edu/docs/fsbenc...

Vieira, L. (3 ottobre 2011). The Perception of Performance. Recuperato il 22 marzo 2015, da Sitepoint: http://www.sitepoint.com/the-perception-...