Benchmarks: hva er det? Hva er det for historie, typer og tips

Benchmarks er en viktig del av vår daglige maskinvareanalyse, de lar oss tilby deg en vitenskapelig sammenlignbar måling mellom forskjellige komponenter som CPUer, grafikkort, lagringsenheter, etc. I dag skal vi vie noen linjer til historien, typene, hvordan de fungerer, hva de måler, hva er de vanligste tiltakene, og vi vil også gi deg noen tips om hvordan du utfører dem og hvilke vi bør stole på.

Det vi i dag kjenner til i PC eller mobilverden som benchmarks er teknikker som er arvet fra det industrielle miljøet som har tillatt, siden begynnelsen av denne revolusjonen, å ta beslutninger basert på sammenlignbare data i et kontrollert miljø.

Verden for moderne databehandling bruker disse teknikkene på nesten hvilket som helst av de mange forskjellige domenene, og hjemmebrukere har også brukt dem som en pålitelig måte å lære om ytelsen og egenskapene til systemene våre, så vel som et viktig informasjonspunkt når å ta viktige beslutninger, for eksempel kjøp av vår nye datamaskin, mobiltelefon, grafikkort, etc.

I dag skal vi snakke om historien til PC-benchmarks, hvilke typer benchmarks som finnes og hvilke komponenter i systemet vårt som er mer egnet for denne typen tester som ikke bare er ytelse.

Innholdsindeks

historie

Referanse- eller målesystemet bruker et kontrollert miljø og gjenkjennelige tiltak som er vitenskapelig sammenlignbare og etterprøvbare og som har eksistert sammen med datamaskinens verden siden den eksisterer. Referansen, som sådan, er blitt demokratisert til det punktet at en del av dens grunnleggende essens er tapt, som er at den kan være revisibel og etterprøvbar av tredjepart. Nå bruker vi den mer som en rask sammenligning av ytelse, men sporbarheten til dens sannhet av tredjepart har helt sikkert gått tapt.

De mest klassiske referansemetodene har alltid referert til datakapasiteten til systemets CPU, selv om den i nyere tid har variert mellom forskjellige komponenter, da disse har fått overvekt og betydning i en datamaskin.

De to mest klassiske måleenhetene som fremdeles brukes, er Dhrystones og Whetstones. Begge har på noen måte blitt grunnlaget for alle syntetiske benchmarks som vi kjenner i dag.

Den eldste er Whetstones (en lokalitet i Storbritannia hvor atomenergiavdelingen til Storbritannias statlige kraftselskap var lokalisert) og Dhrystone kom senere og spilte med navnet på den første (våt og tørr).

Den første ble designet på 70-tallet, og den andre er fra 80-tallet, og begge er grunnlaget for sammenlignende ytelse som vi har hatt i påfølgende år. Whetstones, forenkling, bød på et innblikk i datakraft til prosessoren i flytende punktoperasjoner, operasjoner med stort antall desimaler.

Dhrystone er dens motstykke siden den er dedikert til grunnleggende instruksjoner uten desimaler, begge ga et klart bilde av ytelsen til en prosessor fra to helt forskjellige, men komplementære tilnærminger. Whetstones og Dhrystone er avledet av to konsepter som vi bruker mye mer vanlig i dag, MIPS og FLOP.

Etter disse målingene kom andre som FLOP (Floating-point Arithmetic - floating point arithmetic) som i stor grad er viktigere nå i en datamaskin enn det noen gang har vært fordi det er grunnlaget for avansert beregning i mange moderne teknikker. som kunstig intelligensalgoritmer, medisinske algoritmer, værvarsling, uklar logikk, kryptering, etc.

LINPACK ble utviklet av ingeniøren Jack Dongarra på 1980-tallet og fortsetter å bli brukt i dag for å måle den flytende punktberegningskapasiteten til alle typer systemer. For tiden er det versjoner optimalisert av arkitektur, CPU-produsent, etc.

FLOPS fyller artiklene våre på grafikkort (sikkert den enkle eller doble presisjonen høres kjent ut), prosessorer og er grunnlaget for å beregne strømbehov og maskinvareutvikling for enhver superdatamaskin som er i drift eller utvikling.

FLOP er i dag den mest nødvendige ytelsesmåleenheten i bransjen, men den har alltid blitt kombinert med MIPS (Millioner av instruksjoner per sekund), som er et interessant målingstiltak, siden det gir oss antall instruksjoner Grunnleggende aritmetikk som en prosessor kan utføre per sekund, men det avhenger mer av arkitekturen til prosessoren (ARM, RISC, x86, etc.) og programmeringsspråket enn andre måleenheter.

Etter hvert som ytelsen har avansert har multiplikatorene skjedd. Vi måler nå ytelsen til hjemme-CPUer i GIPS og GFLOPS. Basen forblir den samme, klassiske aritmetiske operasjoner. Sisoft Sandra fortsetter å tilby oss denne typen målinger i noen av sine syntetiske benchmarks.

MIPS har også blitt mer relatert til CPU som et klassisk element, og FLOP har utvidet seg til andre blomstrende områder som prosesskapasitet eller generell beregning av tidligere prosessorer som er veldig orientert om spesifikke oppgaver som GPU-er som vi alle monterer på prosessorene våre eller på våre dedikerte utvidelseskort.

Til disse grunnleggende konseptene har tiden lagt til nye måleenheter som er like mye eller viktigere enn disse i en moderne datamaskin eller superdatamaskin. Dataoverføring er et av disse tiltakene som har blitt veldig viktig og måles for øyeblikket i IOPs (input and output operations per sekund) og også i andre former som MB / GB / TB lagringstiltak sammenlignet med tiden det tar å overføring fra ett punkt til et annet (MBps - Megabyte per sekund).

AS-SSD kan måle ytelsen til en harddisk i MBps eller IOP-er.

For øyeblikket bruker vi også overføringsmålet, i dets forskjellige multiplikatorer, som en måte å tolke hastigheten på informasjonsoverføring mellom to punkter når vi skal avgi viss informasjon vi faktisk må ha generert litt mer informasjon. Dette avhenger av protokollen som brukes for overføring av informasjon.

Et tydelig eksempel, og at vi bruker mye, er i PCI Express-grensesnittet. I henhold til denne protokollen må vi for hver åtte bits med informasjon som vi vil flytte (0 eller 1s) generere 10 biter med informasjon, siden den ekstra informasjonen er for kontroll av kommunikasjonen som blir sendt for feilretting, dataintegritet, etc.

Andre kjente protokoller som også introduserer dette "tapet" av ekte informasjon er IP-en, den du bruker for å lese denne artikkelen, og som gjør at 300MT / s-forbindelsen din faktisk tilbyr litt under 300 Mbps hastighet.

Derfor bruker vi Gigatransfer eller overføringen når vi viser til rå informasjon sendt av grensesnittet, og ikke til informasjonen som faktisk blir behandlet i mottakeren. En 8GT / s PCI Express 3.0-databuss sender faktisk 6, 4 GBps informasjon for hver linje som er koblet mellom punktene. Overføring har blitt veldig viktig med integrasjonen av PCI Express-protokollen i alle hovedbussene til en hjemme- og profesjonell datamaskin.

I nyere tid begynte vi også å kombinere tiltak som en måte å relatere prosessorkraften med andre veldig viktige faktorer i moderne databehandling, med forbruk som et av disse tiltakene som blir introdusert som en sammenlignende skala mellom ytelsen til to systemer. Energieffektiviteten er i dag like mye eller viktigere enn prosesskraften, og derfor er det lett å se benchmarks som sammenligner prosesskraften i henhold til wattets forbruk av elementet i målingen.

Faktisk refererer en av de store lister over superdatamaskiner ikke så mye til datamaskinens bruttokraft blant alle dens databehandlingsnoder, men til utviklingen av den kraften basert på watt eller energi forbrukt av hele systemet. Green500-listen (FLOPS per watt - FLOPS per watt) er et tydelig eksempel på hvordan forbruket nå er grunnleggende for ethvert selvrespektende mål, selv om vi uten tvil fortsetter å se nøye på TOP500-listen som ikke har denne faktoren som en konditionerende faktor.

Typer referanser

Selv om vi kan snakke om mange flere familier eller typer benchmarks, vil jeg forenkle listen i de to vanligste klassene til de som er nærmest oss alle som mer eller mindre avanserte brukere.

På den ene siden har vi de syntetiske målestokkene som stort sett er de som tilbyr oss tiltak som vi har snakket om før. Syntetiske benchmarks er programmer som utfører kontrollerte tester med en mer eller mindre stabil programkode orientert for en spesifikk plattform og arkitektur. De er programmer som utfører veldig spesifikke tester som kan integrere en eller flere av komponentene våre, men der den samme testen eller testene alltid blir utført, uten endringer.

Bildegjengivelse har alltid vært en god metode for å kjenne ytelsen til en CPU i et moderne system, siden det er en krevende oppgave. Cinebench R15 har også flere tester, en for GPU og to for CPU, hvor vi kan kjenne ytelsen til systemer med flere kjerner og prosesstråder.

De tilbyr et kontrollert testmiljø, der det ikke er endringer bortsett fra versjoner og hvor disse endringene er korrekt dokumentert slik at brukeren vet hvilke versjoner som kan sammenlignes med hverandre. Disse programmene kan teste forskjellige delsystemer på datamaskinen vår separat, med andre kodestykker eller spesifikke referansepunkter for å utføre en viss type test, eller kombinert som kan påvirkes av ytelsen til en, to eller flere systemkomponenter. Referansen som er integrert i et spill, eller programmer som Cinebench, Sisoft Sandra, SuperPI, 3DMark,… er klare eksempler på syntetiske benchmarks.

Andre syntetiske benchmarks som vi ikke skal forveksle med ekte benchmarks er de som simulerer utførelsen av virkelige programmer, eller som utfører handlingsskript i virkelige programmer, de er også syntetiske siden det ikke er noen tilfeldighet i testen. PC Mark er et tydelig eksempel på en syntetisk referanseprogram som vi kan forveksle med et ekte referanseindeks.

Selve målestokken er en veldig annen testmetode fordi den godtar tilfeldigheten ved å bruke et program for å måle ytelsen. Spillere er vant til å utføre denne typen benchmarks eller ytelsestest når vi justerer kvalitetsparametrene til et spill til mulighetene for maskinvaren vår.

Å måle ytelsen til et spill mens du spiller er en virkelig målestokk.

Når du åpner FPS som spillet gir og prøver å oppnå ønsket 60FPS kontinuerlig, utfører de et skikkelig mål. Det samme kan ekstrapoleres til alle andre typer programmer, og hvis du er en utvikler, når du optimaliserer koden til programmet ditt, så gjør du også virkelige benchmark-tester der det som endres er koden din, eller måten å utføre den på, på en plattform av stabil eller variabel maskinvare.

Begge typer benchmarks er viktige, de første lar oss sammenligne systemet vårt med andre i et kontrollert miljø, og de andre er en måte å optimalisere driften vår der også to viktige faktorer legges til, tilfeldigheten i utførelsen og den menneskelige faktoren. Begge faktorene gir et ekstra synspunkt på ytelsen til komponenten eller komponentene som vi vil teste.

Hensyn ved benchmarking

For at en målestokk skal være nyttig og effektiv, må vi ta hensyn til visse faktorer som er veldig viktige. Sammenligning mellom forskjellige plattformer og arkitekturer introduserer en viktig usikkerhetsfaktor, og det er grunnen til at denne typen benchmarks som gir deg muligheten til å sammenligne iOS-mobiltelefoner med Windows x86-datamaskiner, for å gi et eksempel, må du ta dem med pinsett siden det ikke bare endres operativsystemkjernen, men prosessorarkitekturer er veldig forskjellige. Utviklerne av denne typen benchmarks (for eksempel Geekbench) introduserer korreksjonsfaktorer mellom de forskjellige versjonene som knapt er kontrollerbare.

Derfor er den første nøkkelen for et benchmark som kan sammenlignes mellom forskjellig maskinvare, at testøkosystemet er så likt som mulig referanseplattformen, operativsystemet, driverne og programvareversjonen. Det vil helt sikkert være elementer her som vi ikke kan kontrollere homogenisering, som grafikkontrolleren hvis vi tester AMD-grafikk mot Nvidia-grafikk, men resten må vi prøve å ha det så stabilt som mulig. I dette tilfellet vil vi også inkludere maskinvare, for å sammenligne grafikkort, er din ting å bruke det samme operativsystemet, den samme prosessoren, de samme minnene og alle operasjonsparametrene, ved å holde dem de samme, inkludert parametrene for kvalitet, oppløsning og test i målestokken. Jo mer stabilt testøkosystemet vårt er, desto mer pålitelige og sammenlignbare blir resultatene våre.

Vi anbefaler å lese Hvordan vite om prosessoren min har en flaskehals?

En annen ting vi må ta hensyn til er at benchmark-tester normalt har en stressfaktor på maskinvaren som vi skal teste og normalt utsetter denne maskinvaren for situasjoner som normalt ikke vil oppstå ved normal bruk av systemet. Hver referanse som vi tar fra harddisken, grafikkortet eller prosessoren vår, sender dem til situasjoner som kan være farlige for maskinvaren, så vi må etablere passende tiltak slik at spenningspunktet ikke blir et bruddpunkt eller også i et element i ytelsesreduksjon siden mange komponenter har beskyttelsessystemer som de reduserer ytelsen sin i tilfelle for eksempel temperaturer utenfor bruksområdet. Tilstrekkelig avkjøling, hvileperioder mellom tester, korrekt mating av komponentene som testes… alt skal være i en ideell situasjon for at testen skal gå jevnt.

På den annen side bruker vi også nettopp denne typen benchmarks for å utsette systemet for stress for å se stabiliteten i denne typen situasjoner, det er en annen måte å anvende et referanseindeks siden det ikke bare søker å vite ytelsen, men også om systemet er stabilt og enda mer, hvis systemet fungerer som det skal i disse stressende situasjonene.

konklusjon

For de av oss som er dedikert til å teste maskinvare profesjonelt, er referanseindeksen et arbeidsverktøy, og takket være det har brukerne en vitenskapelig og etterprøvbar måte å sammenligne eller kjenne ytelsen til vår neste datamaskin i hvert av sine delsystemer med presisjon. sammenlignbart med verktøy som brukes på industrielt nivå.

En testtabel, som den du ser på bildet, søker å standardisere testmetoden nøyaktig, slik at det sammenlignende referanseporteføljen er så pålitelig som mulig og kan testes når du introduserer variasjoner som endrer resultatene.

Men som alle "laboratorietester", for at den skal være pålitelig, må de rette forholdene være på plass for at den skal kunne utføres, og enda mer for at den skal kunne sammenlignes mellom forskjellige systemer.

I dag har vi fortalt deg litt om historien til denne typen programmer, dens forskjellige typer, hvordan de fungerer og hvordan du kan få pålitelig informasjon fra dem. De er nyttige, men for meg er de bare ett stykke informasjon å huske på, og jeg vil alltid legge den bak personlig erfaring og aktiv testing med virkelige programmer som vi skal bruke hver dag.

En målestokk er greit å legge inn et minimumsdata for data i beslutningsprosessen vår, men de bør ikke være definerende for disse beslutningene, og som et siste tips, unngå syntetiske benchmarks som hevder å kunne sammenligne ytelse mellom arkitekturer, operativsystemer, etc.