Problem
Jeg prøver å beregne CPU / GPU FLOPS ytelse, men jeg er ikke sikker på om jeg gjør det riktig .
La oss si at vi har:
- En Kaby Lake CPU (klokke: 2.8 GHz, kjerner: 4, tråder: 8)
- En Pascal GPU (klokke: 1,3 GHz, kjerner: 768).
Denne Wiki-siden sier at Kaby Lake-prosessorer beregner 32 FLOPS (single precision FP32) og Pascal-kort beregner 2 FLOPS (single precision FP32), noe som betyr at vi kan beregne deres totale FLOPS-ytelse ved hjelp av følgende formler:
CPU:
TOTAL_FLOPS = 2.8 GHz * 4 cores * 32 FLOPS = 358 GFLOPS GPU:
TOTAL_FLOPS = 1.3 GHz * 768 cores * 2 FLOPS = 1996 GFLOPS Spørsmål
-
[LØST] De fleste guider jeg har sett (som denne) bruker fysiske kjerner i formelen. Det jeg ikke forstår er hvorfor ikke bruke tråder (logiske kjerner) i stedet? Var ikke tråder opprettet spesielt for å doble ytelsen til beregning av flytende punkt? Hvorfor ignorerer vi dem da?
-
[LØST] Gjør jeg det i det hele tatt riktig? Jeg kunne ikke finne en pålitelig kilde for beregning av FLOPS, all informasjon på internett er motstridende. For i7 7700HQ Kaby Lake CPU fant jeg FLOPS-verdier så lave som 29 GFLOPS selv om formelen ovenfor gir oss 358 GFLOPS. Jeg vet ikke hva jeg skal tro.
-
Finnes det et plattformbibliotek (Win, Mac, Linux) i Node.js / Python / C ++ som bare returnerer alle GPU-statistikk som skyggekjerner, klokke, tilgjengelige instruksjonssett (eller FP32, FP64 FLOPS-verdier), slik at jeg selv kunne beregne den maksimale teoretiske ytelsen? Det er ganske latterlig at vi ikke kan få FLOPS-statistikken direkte fra CPU / GPU, i stedet for må laste ned og analysere en wiki-side for å få verdien. Selv når du bruker C ++, virker det (jeg vet ikke egentlig) at vi må laste ned 2 GB CUDA-verktøysettet bare for å få tilgang til den grunnleggende Nvidia GPU-informasjonen, som mengden kjerner – noe som vil gjøre det praktisk talt umulig å lage appen tilgjengelig for andre, siden ingen ville laste ned en 2 GB-app.
Kommentarer
- Som et delvis svar jeg tro det du kaller » tråder » er et triks som gjør det mulig for en kjerne å være vert for det som ser ut som to tråder om gangen (hyper mens jeg bare har en faktisk fysisk kjerne å beregne med. Jeg er ikke helt sikker på detaljene i hvordan Intel gjorde dette, men jeg tror det har å gjøre med å fylle ut hull i rørledninger og slikt. Dette vil i prinsippet ikke skje hvis du beregner noe tungt, men for mange mer vanlige brukstilfeller for et stasjonært operativsystem, er det fornuftig. Hvis du er interessert i faktisk beregning, men dette er vanligvis ikke co unted.
- @KyleMandli takk for avklaringen, jeg antar at det gir mening
- En del av den foreslåtte beregningen er frekvens. Jeg antar at du er klar over at det med moderne maskinvare ikke er frekvensen. Driftsfrekvensen vil variere basert på temperatur og strømforbruk (f.eks. De fleste GPUer), eller bruken og bruken av instruksjonssett (f.eks. De fleste x86-CPUer), og muligens alle de nevnte faktorene.
- Du ‘ må erstatte MHz overalt med GHz.
- Det ‘ er ingen enkelt » faktisk » ytelse. Når jeg for eksempel multipliserer store matriser på Volta-GPUer, er » faktisk » ytelsen nær teoretisk, 90 topper / sekund. I mellomtiden trener resnet-50, det ‘ er mer som 20 topper / sekund – medium.com/@yaroslavvb/…
Svar
Du kan beregne GFLOP-priser dette måte, men tallene er ganske meningsløse på dagens maskinvare:
-
Flytpunktsoperasjoner krever et variabelt antall klokkesykluser. Et tillegg er generelt billigere enn en multiplikasjon, men hver generelt tar mer enn en klokkesyklus på 2,8 milliarder sykluser du ganske.
-
Når du har hypertråd, har du to tråder som kjører på en kjerne, men kjernen vil fortsatt ha bare en flytende punkt-tilleggsenhet og slik at de to trådene ikke kan utføre flytende tillegg på samme tid.
-
Flytende punktoperasjoner er energisultne, og energi omdannes til varme. Når du gjør mange FLOP-er, overopphetes prosessorer og trapper ned klokkefrekvensene.
-
Hvis du bruker de riktige instruksjonene, kan du gjøre FMA-operasjoner (floating point multiply-add) som gjør en multiplikasjon-og-tillegg raskere enn å utføre disse operasjonene separat.
-
På samme måte, med SIMD-instruksjoner, kan en kjerne utføre den samme operasjonen på flere datadeler samtidig – si, legg til fire par flytende tall sammen, og gi 4 FLOPs samtidig. Men dette krever å ha et problem der en algoritme faktisk krever at dette skal skje, i stedet for å bruke resultatene av det første tillegget i det andre. Som en konsekvens bidrar SIMD-instruksjoner bare til hastigheten som noen algoritmer kan kjøres på, men ikke andre.
-
Viktigst, du vil generelt ønsker å utføre operasjoner på data fra minnet, men å flytte data fra hovedminnet til prosessoren tar langt langt lenger enn å utføre noen operasjoner på dataene – som en faktor 100 lenger (størrelsesorden). Så du ser generelt ikke en liten brøkdel av den teoretiske ytelsen til prosessorer i reelle applikasjoner: generelt vesentlig mindre enn 10% av den teoretiske toppytelsen.
Beregning av toppytelse har med andre ord blitt en slags meningsløs virksomhet: Det har ikke noe særlig å gjøre med den faktiske ytelsen til en prosessor.
Kommentarer
- Du kan også diskutere hvordan SIMD-enheter med flytende punkt kan øke den teoretiske toppytelsen.
- Takk for innspillene dine, folkens, jeg forstår disse punktene og forstår hvordan avanserte instruksjoner sett påvirker flytende punkt ytelse. Jeg antar at jeg ‘ bare holder meg med det teoretiske maks. det tar for CPU å beregne en bestemt funksjon.
- @AlekseyHoffman Det er ingen formel, bare målinger. div id = «fd68a555a6»>
hvorfor TOPP 500-listen er basert på faktiske målinger av ytelse, ikke teoretisk toppytelse.
Svar
Yoy kan lese på russisk – hvordan man beregner FLOPS .
GHz viser ikke FLOPS. En prosessor med samme GHz kan være mye raskere enn den andre med samme GHz.
P.S. gpu-s » rx 590 » og veldig gammel » r7 250x » har nesten samme GHz. Men … dette er til og med ikke riktig for å sammenligne ytelsen deres)
Kommentarer
- Hei velkommen til scicomp! I stackexchange er det bedre å ha post selvstendig (se her ). For å forbedre innlegget, prøv å redigere svaret med kjerneinformasjonen i artikkelen.