Gids voor het uitvoeren van zinvolle computerbenchmarktests voor productiviteit

Benchmarkprogramma's proberen de “prestaties” van een computer te analyseren op basis van een welomschreven testomgeving (meestal niet eens in de buurt van de uiteindelijke configuratie van de computer). De benchmarker kan gebruikmaken van de grenzen die moeten worden getoetst, zoals systeembronnen, virtuele softwareomgeving, applicaties, simulatie van verwerkingsbelasting, simulatie van gebruikersbelasting en simulatie van systeemgebruik, onder andere; en doen wat nodig is om dergelijke grenzen te overschrijden en een twijfelachtig resultaat te geven. Nu, “het hebben van een industriestandaard benchmark is altijd een goede zaak, als de benchmarks niet worden gemanipuleerd. Helaas worden veel industriële benchmarks gemanipuleerd. […] Toch lijken veel organisaties hardware te kopen op basis van benchmarks in plaats van hun werklasten te begrijpen en hardware te kopen op basis van hun vereisten en, natuurlijk, budget.” (Newman, 2015) Dit verklaart waarom de klant precies moet weten wat er gemeten moet worden. Een benchmarkprogramma zal nooit in staat zijn om de zogenaamde praktijkervaring weer te geven; het zal alleen weergeven hoe een dergelijk programma op de beoogde computer draait. Het is dus de verantwoordelijkheid van de klant om te bepalen hoe het resultaat in zijn productieomgeving zal worden toegepast.

Verrassend genoeg is het correct uitvoeren van benchmarks erg moeilijk, omdat er veel mogelijkheden zijn om slechte of misleidende resultaten te krijgen en dingen weg te laten. De whitepaper “A Nine Year Study of File System and Storage Benchmarking” vat dit samen:

In dit artikel onderzoeken we 415 bestandssysteem- en opslagbenchmarks uit 106 recente papers. We ontdekten dat de meeste populaire benchmarks gebrekkig zijn en dat veel onderzoekspapers geen duidelijke indicatie geven van de werkelijke prestaties. (Traeger, Zadok, Joukov, & Wright, 2008)

In die whitepaper zijn uitspraken te zien over benchmarks die zouden moeten uitleggen wat er getest gaat worden en waarom, en ze zouden ook een soort analyse van de verwachte systeemprestaties moeten uitvoeren (of vergemakkelijken).

In het artikel “Performance Anti-Patterns” staan enkele belangrijke punten om te bepalen, in dit geval, waarvoor en hoe benchmarks moeten worden uitgevoerd. Daarom zou een goede benchmark het volgende moeten zijn:

• Herhaalbaar, zodat vergelijkende experimenten relatief eenvoudig en met een redelijke mate van precisie kunnen worden uitgevoerd.
• Observeerbaar, zodat als er slechte prestaties worden gezien, de ontwikkelaar een beginpunt heeft om te zoeken. Niets is frustrerender dan een complexe benchmark die één enkel getal oplevert, waardoor de ontwikkelaar geen aanvullende informatie heeft over waar het probleem zou kunnen liggen.
• Portabel, zodat vergelijkingen met uw belangrijkste concurrenten mogelijk zijn (zelfs als het uw eigen vorige releases zijn). Het bijhouden van de prestatiehistorie van eerdere releases is een waardevol hulpmiddel om uw eigen ontwikkelingsproces te begrijpen.
• Gemakkelijk te presenteren, zodat iedereen de vergelijkingen in een korte presentatie kan begrijpen.
• Realistisch, zodat de metingen de realiteit van de klantervaring weerspiegelen.
• Uitvoerbaar, zodat alle ontwikkelaars snel de effecten van hun wijzigingen kunnen vaststellen. Als het dagen duurt om prestatieresultaten te krijgen, zal dit niet erg vaak gebeuren.

Niet alle geselecteerde benchmarks zullen aan al deze criteria voldoen, maar het is belangrijk dat een aantal ervan dat wel doet. Smaalders nodigt uit om benchmarks te kiezen die werkelijk de behoeften van de klant vertegenwoordigen, anders zullen alle inspanningen leiden tot optimalisatie voor het verkeerde gedrag. Hij moedigt ook aan om de verleiding te weerstaan om te optimaliseren voor de benchmark met als doel de wedstrijd tegen elke prijs te winnen. Dergelijk gedrag zal valse resultaten opleveren die kunnen leiden tot een gebrek aan vertrouwen in het merk of de aanbieder. Over het algemeen zal een benchmark het aspect benadrukken waarvoor wordt geoptimaliseerd, ten koste van andere aspecten die niet worden gemeten (en die belangrijk kunnen zijn voor de klant). (Smaalders, 2006)

Er is nog iets anders bij het vergelijken van verschillende systemen met de intentie om ze te kopen: de prijs-prestatieverhouding. Deze verhouding kan worden gekwantificeerd inclusief de kapitaalkosten van de apparatuur over 5 jaar. (Anon & Gray, 1985)

Eenvoudig testen met benchmarksoftware omvat geen volledige prestatieanalyse. Benchmarkprogramma's werken normaal gesproken in een gecontroleerde omgeving, dus ze kunnen worden gemanipuleerd om een gewenst tarief te verkrijgen — het hoogst mogelijke. Desalniettemin zal een dergelijk tarief NOOIT een goede correlatie geven met de werkelijke klantervaring. De verstrekte statistieken bieden u eerder alleen een score die representatief is voor hoe goed het op een specifieke benchmark draait. Een groot probleem is dat de gebruiker nooit echt weet wat er wordt getest, hoe aspecten van een benchmarkscore worden gemeten, welke vlaggen in de compiler zijn ingesteld, welke code of bibliotheken achter het programma zitten en, belangrijker nog, of wat het programma test het werkelijke beoogde gebruik voor de computer zal weerspiegelen. Er zijn dus enkele punten om op te merken:

• Een benchmark zal nooit het werkelijke gebruik weerspiegelen. Omdat het een volledig geautomatiseerd programma is, zal het op volledig geautomatiseerde wijze taken openen, schrijven, instellen, lezen, opslaan, tonen, bekijken, navigeren, verplaatsen, berekenen, toewijzen en nog veel meer doen. Zo'n manier zal nooit het tempo weerspiegelen waarmee een mens zijn of haar werk doet. Daarom liegt elk benchmarkprogramma dat resultaten belooft op basis van praktijkgebruik.
• Niet alle benchmarks evalueren multitasking-prestaties. De overgrote meerderheid van de benchmarks evalueert alleen serieel uitgevoerde taken. Ze testen één ding en daarna het volgende. Ze zullen nooit een applicatie iets laten doen terwijl een andere applicatie iets anders doet (en als dat zo is, proberen ze normaal gesproken twee of hooguit drie instanties). In het echte leven voeren gebruikers meerdere applicaties tegelijk uit. De meeste gebruikers openen veel applicaties tegelijkertijd (het besturingssysteem voert ook veel taken uit terwijl we onze dagelijkse taken uitvoeren). Het is vermeldenswaard dat een benchmark die slechts één proces/applicatie weerspiegelt, niet lineair schaalt met het tweede, derde en de rest van de processen/applicaties. Daarom is het bij moderne multicore-technologie belangrijk om de resultaten van een benchmarkprogramma met een korreltje zout te nemen.
• “Tarief” is niet hetzelfde als “prestatie”. Tarief is slechts een getal dat door het programma wordt gegeven. Prestatie is iets ingewikkelder. Het tariefgetal hangt af van het benchmarkprogramma en de schaal die door de ontwikkelaars ervan is vastgesteld. Prestatie is de voltooiing van een gegeven taak gemeten aan de hand van vooraf vastgestelde bekende normen voor nauwkeurigheid, volledigheid, kosten en snelheid (The Business Dictionary, 2017). Daarom weerspiegelt geen enkel tarief van een benchmarkprogramma een prestatie-index.
• Benchmarks zijn onnauwkeurig. De variatie in een tarief van een benchmarkprogramma kan oplopen tot 10% (soms meer). Deze benchmarktarieven zijn altijd subjectief, wat in strijd is met de objectieve principes van wetenschap en technologie. Daarom moet een benchmarkprogramma ten minste 3 keer worden uitgevoerd om het gemiddelde van het gegeven tarief te berekenen. Na het bepalen van het gemiddelde wordt een variatie van minimaal +/- 3% van het resultaat verwacht (een dergelijke variatie kan worden berekend op basis van de verzamelde resultaten).
• Benchmarkresultaten kunnen worden gemanipuleerd. Er zijn manieren om de resultaten van een benchmarkprogramma te manipuleren en kunstmatig hoge tarieven aan te bieden om de gebruiker te imponeren. Dit kan worden gedaan via vele technieken, zoals overmatige aanpassingen, instellingen in BIOS, hardware-aanpassing, gebruik van speciale drivers, codemanipulatie en andere. Benchmarktarieven kunnen worden verkregen met onrealistische instellingen in vergelijking met hoe de computer in de praktijk zal worden gebruikt: van het systeem wordt vereist dat het vrij is van programma's en processen en specifieke waarden heeft die afhangen van de betreffende benchmark, en dit weerspiegelt niet de manier waarop de computer bij productiviteit zal worden gebruikt. Zoals Henry Newman verklaarde: “Wat een benchmark ons vertelt is: 1) Hoeveel hardware een leverancier in een doos kan proppen, 2) Hoe goed het leveranciersteam software kan optimaliseren [voor de benchmark], en, 3) Hoe graag de leverancier de deal wil.” (Olds & OrionX, 2011) Als er geen benchmarkprotocol is dat duidelijk door de klant is vastgesteld, staat de deur open voor elke truc die de benchmarker kan uithalen om de gewenste resultaten te bereiken (of te overtreffen) en de klant te imponeren.

Uiteindelijk is een benchmarkprogramma geen precies hulpmiddel en moet het met zorg worden gebruikt. Zoals Henry Newman citeerde in een persoonlijke communicatie: “Het vergelijken van systeemprestatietools [...] met [...] benchmarks is als appels met vliegende varkens vergelijken.” (Carrier, 2012)

Scores die door een benchmark worden verstrekt, moeten worden gebruikt in combinatie met andere benchmarks en aanvullende details om een volledig inzicht te krijgen in de algehele systeemprestaties. De benchmark meet, in het beste geval, alleen de “snelheid” van een computer, maar er zijn veel andere aspecten waarmee rekening moet worden gehouden: commerciële normen, militaire normen, functionaliteit, functies, certificeringen, prijs, onder andere.

Als de computer die voor aankoop wordt geëvalueerd aan verschillende gebruikersvereisten moet voldoen, is het het beste om de beoogde gebruikssituaties vooraf te bepalen, zodat een gedetailleerde set van passende kwalificatiecriteria kan worden vastgesteld. In de meeste gevallen zal de computer waarschijnlijk in een of meer van de volgende contexten worden gebruikt:

• Zal worden gebruikt met huidige grafische besturingssystemen (Windows 10, of ten minste GNU/Linux-distributies)
  • Of als het zal worden gebruikt met eerdere versies van besturingssystemen, zoals Windows 7 of Windows 8.1, of een eerdere GNU/Linux-distributie.
• Basisproductiviteit (niet meer dan 5 applicaties draaiend, waaronder):
  • Antivirus
  • Tekstverwerking
  • E-mail
  • Licht gebruik van spreadsheets
  • Webgebaseerde applicaties
  • Surfen op het web met niet meer dan 6 tabbladen open.
• Standaard productiviteit (5 tot 10 applicaties draaiend, waaronder):
  • Hetzelfde als basisproductiviteit, en ook...
  • Office-applicaties (tekstverwerking met afbeeldingsmanipulatie, spreadsheets met formules en enkele scripts, presentaties, basisdatabasebeheer)
  • Surfen op het web met maximaal 15 tabbladen
  • Webconferenties
  • Bekijken en eenvoudig bewerken van afbeeldingen en video's
  • Onderwijs
  • Kan uitgaan van veelvuldig gebruik van video's, afbeeldingen, animaties, webtoegang en applicaties die momenteel versneld computergebruik gebruiken.
• Power User (Meer dan 10 applicaties draaiend, waaronder):
  • Hetzelfde als standaard productiviteit, en ook...
  • Applicatieontwikkeling
    • Gebruik van programmeertalen en omgevingen
    • Maken, beheren en testen van databases,
    • Testomgeving met virtuele machine
    • Gecontroleerde testomgevingen
  • Programma's voor wetenschappelijk onderzoek
    • Gespecialiseerde applicaties
    • Engineering- en wetenschappelijke applicaties
    • Virtual Reality
• Alleen voor algemene kennis: games worden momenteel beschouwd als high-performance computing (Stevenson, Le Du, & El Afrit, 2011)
• Andere criteria
  • Is een laag stroomverbruik vereist?
  • Is de ruimte die de computer inneemt belangrijk of beperkt?
  • Is mobiliteit vereist?
  • Is batterijduur belangrijk?
  • Is gewicht belangrijk?
  • Bepaalde andere toepassingen die draagbaar gebruik impliceren in ruwe, stoffige of lawaaierige omgevingen

De term in de titel van dit gedeelte lijkt misschien vreemd, maar in feite is het een probleem dat over het algemeen wordt genegeerd of verwaarloosd. Het verwijst naar de volgende vraag: welke responstijd is echt belangrijk voor de gebruiker? Snelheid en prestaties zijn in feite relatieve termen. Ilya Grigorik stelt een interessant concept voor van wat het woord “prestatie” betekent.

“Prestatie is niet alleen milliseconden, frames en megabytes. Het gaat ook over hoe deze milliseconden, frames en megabytes zich vertalen naar hoe de gebruiker de applicatie waarneemt.” (Grigorik, 2014)

Elke applicatie schrijft zijn eigen set vereisten voor op basis van bedrijfscriteria, context, gebruikersverwachtingen en perceptuele verwerkingstijdconstanten die volledig op de gebruiker zijn gericht. Nogmaals, gebruikersverwachtingen hebben een relatie met de eerste wet van Maister; “Tevredenheid is gelijk aan perceptie minus verwachting.” (Maister, 1985) Hoezeer het leven ook versnelt, of tenminste wordt waargenomen als versnellend (1 frame per 66ms), onze reactietijden blijven constant. Als we bedenken dat een gebruiker volgens traditionele studies rond de 15 frames per seconde kan zien (Thorpe, Fize, & Marlot, 1996), geeft de volgende tabel (gebaseerd op de Military Standard 1472G) een duidelijk beeld van de responstijd die een gebruiker normaal verwacht. Dit ongeacht het type applicatie (geïnstalleerd op de computer of online) of media (laptop, desktop of mobiel apparaat).

Werkelijke tijd en gebruikersperceptie (Seow, 2008)

• 0 – 100 ms: Instant
• 100 – 500 ms: Onmiddellijk
• 500 – 1000 ms: Snel
• 1 – 10 s: Een vertraging wordt waargenomen, maar de gebruiker verliest de focus niet.
• +10 s: De computer is te traag om de aandacht van de gebruiker vast te houden.

Om de reactie op een gebruikersverzoek als snel te laten ervaren, moet deze in minder dan een seconde aankomen. Als het een seconde of langer duurt, kan de gebruiker een zekere vertraging waarnemen, maar haar aandacht zal niet worden afgeleid van de taak. Na 10 seconden – tenzij het programma enige vorm van informatie aan de gebruiker verstrekt – zal de taak normaal gesproken worden afgebroken en zal de gebruiker irritatie ervaren. Als de computer die wordt geëvalueerd reacties kan leveren in een vergelijkbare tijd of in minder dan 10 seconden, zal de gebruiker meer uit de computer halen. Deze drempels zijn in de echte wereld veel nuttiger dan de resultaten van benchmarkprogramma's, die geen duidelijke richtlijnen bieden wat betreft hun betekenis.

Dat gezegd hebbende, zou de klant in een effectieve benchmark moeten weten: hoe deze wordt toegepast, de analyse en de conclusies die eruit zullen worden verkregen. Voor de analyse is het belangrijk om te begrijpen of mee te brengen:

• Een drempel of referentie van het minimaal verwachte resultaat
• Wat er getest gaat worden
• Wat de beperkende factoren zijn
• Elke verstoring die de resultaten zou kunnen beïnvloeden
• De details van het geteste systeem
• De prijs (althans, het gemiddelde) van het geteste systeem
• Welke conclusies met de resultaten worden beoogd

De drempel kan worden verkregen van openbare sites (zoals Futuremark) of het kan lokaal worden gemaakt van een computer die momenteel in gebruik is en met een goede configuratie om de basislijn voor elke benchmark in te stellen vanaf de computers die aangeboden gaan worden. Noteer de details van de configuratie van deze computer die als basislijn wordt gebruikt (processor, geheugen [hoeveelheid, snelheid, configuratie, timings], opslag, grafische kaart en monitor) om er een duidelijk beeld van te hebben.

De analyse van benchmarks vereist tijd en ervaring om correct te worden uitgevoerd. Zoals gezegd is het belangrijkste onderdeel het bepalen wat er gemeten gaat worden en of de behaalde resultaten zinvol zijn voor het beoogde gebruik van de computers.

Het volgende is een voorgesteld benchmarkprotocol om — voor zover mogelijk — eerlijke en realistische resultaten van de geselecteerde of toegepaste benchmarks te garanderen.

Het wordt aanbevolen voor de configuratie- en benchmarkprocessen om de benchmarker niet alleen te laten, vooral als de benchmarker een derde partij is. De klant moet een getuige aanstellen die noteert wat de benchmarker doet met de machine om deze te configureren voor het benchmarkproces. Bovendien moet de getuige ook eventuele wijzigingen of aanpassingen noteren die de benchmarker na elk type benchmarktest aanbrengt. Als u, als klant, een goed gedefinieerd protocol heeft, dan mag de benchmarker dit niet schenden om het benchmarkproces te winnen. De benchmarker en de getuige mogen niet dezelfde persoon zijn, wederom vooral als de benchmarker een derde partij is.

Ongeacht het merk of de aangeboden hardware, moeten alle computers voldoen aan de configuratiecriteria:

• Als u om fysieke quad-core processors heeft gevraagd, moeten ze allemaal vier fysieke cores hebben.
• Als u om een bepaalde hoeveelheid, snelheid en configuratie van RAM heeft gevraagd, controleer dan of alle computers dezelfde configuratie hebben. Noteer eventuele verschillen:
  • Grootte
  • Snelheid (MT/s)
  • Timings en latenties (CAS, RAS, tRAS, tRC, Frequentie).
  • Single channel vs Dual Channel
• Als u om een bepaald type opslag heeft gevraagd, controleer dan of alle computers dat soort opslag bevatten. Noteer eventuele gevonden verschillen (doorvoer, zoektijden en schrijftijden):
  • Standaard roterende harde schijf (5400RPM, 7200RPM, 10000RPM, SSHD)
  • SSD
• De videokaart moet voldoen aan Shader Model 6.1 (DirectX 12.1) voor Windows 10 of Shader Model 5 (DirectX 11) voor eerdere versies van Windows.
• De monitor moet in elke computer aan dezelfde kenmerken voldoen
  • Ververssnelheid
  • Responstijden (ms)
  • Resolutie (hogere resoluties kunnen lagere benchmarknummers opleveren)
  • Kleurdiepte
• Het besturingssysteem moet van dezelfde versie en compilatie zijn.
  • In Windows kunt u de versie en compilatie bekijken door winver en Return te typen in het Cortana-vak of nadat u op Windows+R heeft gedrukt om het venster Uitvoeren te openen.
• Elke computer mag alleen de huidige drivers hebben geïnstalleerd die zijn goedgekeurd door de fabrikant van de computer. Let op: sta het gebruik van speciale drivers of aangepaste drivers van een componentfabrikant niet toe, omdat deze valse resultaten kunnen opleveren. Vermijd het gebruik van drivers buiten de drivers die zijn gevalideerd en openbaar beschikbaar zijn op de website of de setup-tool van de computerfabrikant.
• Configureer de computer in de modus Balanced. Dit is de manier waarop de computers door de klant bedoeld zijn om te worden gebruikt, en is de meest getrouwe manier om resultaten van de benchmarks te krijgen.
• Installeer de veelgebruikte applicaties van de klant. Ongeacht of ze niet in de test zullen worden gebruikt, het is de manier waarop de computers zullen worden gebruikt.
• Installeer alle andere software (zoals antivirus en tools) die door de klant wordt vereist. Dit zal de configuratie zo dicht mogelijk instellen bij hoe de eindgebruiker deze zal gebruiken.
• Installeer de benchmarkprogramma's.

Zodra de computers zijn geïnstalleerd, is het raadzaam om een hot benchmarking uit te voeren. Een hot benchmarking heeft een ingenieur nodig (ingenieur, geen technicus) die alles noteert wat er tijdens het benchmarkproces gebeurt (overgeslagen delen van de test, ontbrekende stappen, fouten in het scherm, slecht getekende figuren of afbeeldingen, enzovoort). Dergelijke afwijkingen moeten worden genoteerd en gerapporteerd. Het is raadzaam om cold benchmarking te vermijden (gewoon de benchmark uitvoeren, weglopen van de computer en daarna terugkomen om alleen het resultaat te noteren) omdat er geen bewijs van vreemd gedrag tijdens de benchmark zal worden genoteerd. Zoals gezegd zijn er manieren om benchmarktarieven te manipuleren en een cold benchmark uitvoeren is de beste manier om dit soort praktijken te missen.

Omdat benchmarktarieven kunnen leiden tot variaties van 5 tot 15%, is het raadzaam om elke test ten minste 3 keer uit te voeren. Elke keer is een herstart van de computer nodig, ongeveer 5 minuten wachten nadat het bureaublad verschijnt en dan de benchmark opnieuw uitvoeren. Na elke benchmark-run is het raadzaam om een screenshot van het resultaat te maken om het bewijs op te slaan. Dit moet worden gedaan in elk geselecteerd benchmarkprogramma.

Het is aan de klant om te beslissen of de verschillende tarieven verkregen via elke run van elke benchmark worden gemiddeld, of dat de hoogste of laagste waarde wordt genomen. Welke beslissing de klant ook neemt, het is aan te raden deze toe te passen op alle verschillende gebruikte benchmarks. Als suggestie: kies voor het gemiddelde.

Na het verkrijgen van dergelijke resultaten kunnen deze worden genormaliseerd (zoals in de tekst van dit document) en vervolgens lineair worden omgezet in tijden. Met de prijs van de computers kan de klant ook evalueren welk van de systemen de beste prijs-prestatieverhouding biedt.

Een benchmarkingproces vereist tijd, ervaring en geduld. Als ze goed worden uitgevoerd, kunnen benchmarkprogramma's een goed beeld geven van de verwachte prestaties van de computer. Alles wat door de getuige is genoteerd, zal nuttig zijn om te bepalen wat de deelnemer moet leveren in geval van selectie. De configuratie (processor, RAM [hoeveelheid, snelheid, timings, kanaalmodus], opslag [type, doorvoer, capaciteit], monitor, vormfactor, enz.) die tijdens het benchmarkingproces is genoteerd, zal nuttig zijn om ervoor te zorgen dat de geleverde computer exact zo geconfigureerd is als getest. Dit is belangrijk omdat sommige kwaadwillende aanbieders een speciaal geconfigureerde computer alleen voor het testproces kunnen leveren, en aan het einde een heel andere. Daarom zal dit de klant helpen om precies te krijgen wat er getest is.

Uit de hele voorgaande discussie kan het volgende worden geconcludeerd:

• De aankopen die de klant doet zijn voor computers, niet alleen voor een processor of een bepaald onderdeel. Het is daarom noodzakelijk om het hele systeem (holistisch) in overweging te nemen bij het nemen van een aankoopbeslissing.
• De prestaties van een computer komen voort uit al zijn elementen. Dit omvat hardware en software. De algehele prestatie van de computer zal altijd gelijk zijn aan de prestatie van zijn traagste element.
• Het is noodzakelijk om rekening te houden met energiebesparende maatregelen, warmteontwikkeling, de stabiliteit van de computer, de certificeringen voor zakelijk gebruik en de beveiligingsdiensten die het biedt. Meer dan alleen snelheid op basis van benchmarks, vereist huidige technologie dat energieverbruik wordt verminderd en beveiligingsdiensten worden geleverd.
• Het is belangrijk om je ervan bewust te zijn dat de nieuwe technologieën die in applicaties en besturingssystemen zijn geïntegreerd, veel meer benutten dan alleen de processor. Ze richten zich eerder meer op andere componenten zoals de CPU, GPGPU, bussen, RAM-snelheid en schijfoverdrachtssnelheid.

Een echte maatstaf voor rekenkracht wordt verkregen wanneer de computer holistisch wordt gemeten, niet alleen op het gebied van seriële verwerking of de CPU. De klant die office-tools, webbrowsers, bestandscompressie, videospelers, teleconferentietools, webgebaseerde applicaties en dergelijke gebruikt, zal profiteren van alle functies van deze nieuwe technologieën met heterogene architectuur.

Een laatste opmerking hierover is dat een drempel of referentie altijd nodig is om een beter beeld te krijgen van de prestatieverbeteringen die men gaat ontvangen. Als u niet de basismaatstaf wilt gebruiken die door FutureMark wordt aangeboden voor een “Reference Office PC” tot op heden, kunt u uw basiscomputer op uw kantoor meten op basis van uw eigen criteria (misschien een computer waarmee u zich comfortabel voelt met zijn standaardprestaties). Zodra u de benchmark uitvoert om de resultaten te krijgen, kunt u die resultaten vervolgens gebruiken als een drempel om een minimaal verwachte tarieven van de aangeboden oplossingen te hebben. Nog een ding om op te merken is dat “tarieven” niet hetzelfde is als “prestatie”. Een “tarief” geeft slechts een kwalificatie van de processen die door het benchmarkprogramma worden uitgevoerd. “Prestatie” is het werkelijke resultaat dat u zult verkrijgen wanneer u die computer voor uw eigen taken gebruikt.

Anon, E. A., & Gray, J. (Februari 1985). A Measure of Transaction Processing Power. Opgehaald op 22 maart 2015, van Internet Archive: https://archive.org/details/bitsavers_ta...

Carrier, J. (24 april 2012). HPCS I/O Scenarios. Opgehaald van OpenSFS: http://cdn.opensfs.org/wp-content/upload...

Computerhope. (15 maart 2015). Thrashing. Opgehaald van Computer hope: http://www.computerhope.com/jargon/t/thr...

Gregg, B. (2014). Systems Performance Enterprise and the Cloud (1e editie). VS: Pearson Education.

Grigorik, I. (12 maart 2014). Speed, Performance, and Human Perception. (Fluent, Ed.) San Francisco, CA, VS. Opgehaald op 22 maart 2015, van https://www.youtube.com/watch?v=7ubJzEi3...

Hoff. (30 december 2006). Multicore, SMP and SMT Processors. Opgehaald op 22 maart 2015, van HoffmanLabs: http://labs.hoffmanlabs.com/node/13

Maister, D. (1985). The Psychology of Waiting Lines. (T. S. Encounter, Ed.) Opgehaald op 22 maart 2015, van 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, VS: UMI.

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

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

Osterhage, W. (2013). Computer Performance Optimization (1e editie). (Springer-Verlag, Vert.) Niederbachem, Duitsland: Springer-Verlag Berlin Heidelberg.

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

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

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

The Business Dictionary. (2017). Performance. Opgehaald van The Business Dictionary: http://www.businessdictionary.com/defini...

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

Traeger, A., Zadok, E., Joukov, N., & Wright, C. (Mei 2008). A Nine Year Study of File System and Storage Benchmarking. Opgehaald op 22 maart 2015, van File systems and Storage Lab (FSL): http://www.fsl.cs.sunysb.edu/docs/fsbenc...

Vieira, L. (3 oktober 2011). The Perception of Performance. Opgehaald op 22 maart 2015, van Sitepoint: http://www.sitepoint.com/the-perception-...