Hvordan kan en FPGA overgå en CPU? (Norsk)

CPU «s er sekvensielle prosesseringsenheter. De deler en algoritme opp i en sekvens av operasjoner og utfører dem en om gangen.

FPGA» er (eller kan konfigureres som) parallelle prosesseringsenheter. En hel algoritme kan utføres med et enkelt kryss av klokken, eller i verste fall langt færre klokker enn det tar en sekvensiell prosessor. En av kostnadene for den økte logiske kompleksiteten er vanligvis en nedre grense der enheten kan klokkes.

Med tanke på det ovennevnte kan FPGAs utkonkurrere CPUer som gjør visse oppgaver fordi de kan gjøre den samme oppgaven i mindre klokker, om enn med en lavere samlet klokkehastighet. Gevinstene som kan oppnås er avhengig av algoritmen, men i det minste er en størrelsesorden ikke atypisk for noe som en FFT.

Videre fordi du kan bygge flere parallelle utførelsesenheter til en FPGA, hvis du har et stort datamengde som du vil sende gjennom den samme algoritmen, kan du distribuere dataene over de parallelle kjøringsenhetene og få ytterligere størrelsesordener høyere gjennomstrømning enn det som kan oppnås med til og med en flerkjerners CPU. p>

Prisen du betaler for fordelene er strømforbruk og $$$ «s.

Kommentarer

• +1; FPGAs imidlertid er ikke like dynamiske som CPUer, og derfor er CPUer vanligvis bedre egnet for PCer
• » Prisen du betaler for fordelene er strømforbruk og $$$ ‘ s. » – Dette er ofte sant, men du kan slå en high-end multi- $ 1000 Intel Xeon-maskin med en low-end $ 50 Xilinx Spartan-6 for mange algoritmer. Men det tar vanligvis mye teknisk tid, og du kan ende opp med en veldig tilpasset design som bare fungerer for en applikasjon og er vanskelig å endre. Så kompromisset er ikke bare makt og penger, men tid for algoritmeutvikling, gjenbrukbarhet og fleksibilitet. (Selv om du kan krangle tid == penger.)
• markt, om din siste setning, er ‘ t FPGAer mye lavere effekt enn CPUer? Det er et bredt spekter av enheter for både CPUer og FPGAer, men hvis vi ser på de som brukes til ting som gruvedrift, er det ikke ‘ t CPUene som brukes til de oppgaver mye mer sult enn FPGA-ene som ville blitt brukt?
• @David: Når vi snakker om Bitcoin-gruvedrift, er den aktuelle beregningen antall hashes per watt. Markt snakker om det totale strømforbruket. Det vil si at en gitt FPGA kan forbruke 3 ganger kraften til en typisk CPU, men være mye mer enn 3 ganger raskere ved Bitcoin-gruvedrift; så for Bitcoin at ‘ er en gevinst.
• @Billy: antall hashes per watt · sekund, ikke per watt.

Markt har dette stort sett riktig, men jeg skal kaste inn mine 2 cent her:

Tenk deg at jeg fortalte deg at jeg ønsket å skrive et program som reverserte rekkefølgen på biter inne i et 32-biters heltall. Noe som dette:

int reverseBits(int input) { output = 0; for(int i = 0;i < 32;i++) { // Check if the lowest bit is set if(input & 1 != 0) { output = output | 1; // set the lowest bit to match in the output! } input = input >> 1; output = output << 1; } return output; } 

Nå er implementeringen min ikke elegant, men jeg er sikker på at du er enig i at det vil være noen operasjoner involvert i å gjøre dette, og sannsynligvis en slags løkke. Dette betyr at du i CPU har brukt mye mer enn 1 syklus for å implementere denne operasjonen.

I en FPGA kan du ganske enkelt koble dette opp som et par låser. Du får dataene dine inn i noe register, så kobler du dem inn i det forskjellige registeret i omvendt bitrekkefølge. Dette betyr at operasjonen vil fullføres i en enkelt klokkesyklus i FPGA. Dermed, i en enkelt syklus, har FPGS fullført en operasjon som tok din generelle CPU for mange tusen sykluser å fullføre! I tillegg kan du koble opp noen hundre av disse registerene parallelt. Så hvis du kan bevege deg noen få hundre tall på FPGA, vil den i en enkelt syklus fullføre de tusenvis av operasjoner hundrevis av ganger, alt sammen i en FPGA-klokke.

Det er mange ting som en generell CPU kan gjøre, men som en begrensning setter vi opp generelle og enkle instruksjoner som nødvendigvis må utvides til lister med enkle instruksjoner for å fullføre noen oppgaver. Så jeg kunne få CPU til generell bruk til å ha en instruksjon som «omvendt bitrekkefølge for 32-biters register» og gi CPU-en den samme muligheten som FPGA vi nettopp bygde, men det er uendelig mange slike nyttige instruksjoner, og så vi bare sett inn de som garanterer kostnadene i de populære CPUene.

FPGAer, CPLDer og ASIC-er gir deg tilgang til rå maskinvare, som lar deg definere sprø operasjoner som «dekrypter AES256-krypterte byte med nøkkel» eller «dekoder ramme av h.264-video». Disse har forsinkelser på mer enn en klokkesyklus i en FPGA, men de kan implementeres på mye mer effektive måter enn å skrive ut operasjonen i millioner av linjer med generell monteringskode. Dette har også fordelen av å gjøre FPGA / ASIC med faste formål for mange av disse operasjonene mer energieffektive fordi de ikke trenger å gjøre så mye fremmet arbeid!

Parallelisme er den andre delen som markedsfører påpekt, og selv om det også er viktig, er det viktigste når en FPGA parallelliserer noe som allerede var dyrt i CPU-en når det gjelder sykluser som trengs for å utføre operasjonen. Når du begynner å si «Jeg kan utføre i 10 FPGA-sykluser en oppgave som tar min CPU 100 000 sykluser, og jeg kan gjøre denne oppgaven parallelt med 4 elementer om gangen, «du kan enkelt se hvorfor en FPGA kan være mye raskere enn en CPU!

Så hvorfor bruker vi ikke FPGA, CPLD og ASIC for alt? For generelt sett er det en hel chip som ikke gjør annet enn en operasjon. Dette betyr at selv om du kan få en prosess for å kjøre mange størrelsesordener raskere i FPGA / ASIC, kan du ikke endre den senere når den operasjonen ikke lenger er nyttig. Årsaken til at du (generelt) ikke kan endre en FPGA en gang det er i en krets at ledningene til grensesnittet er faste, og normalt inkluderer kretsen ikke komponenter som lar deg omprogrammere FPGA til en mer nyttig konfigurasjon. Det er noen forskere som prøver å bygge hybrid FPGA-CPU-moduler, der det er en del av CPU-en som er i stand til å bli kablet / omprogrammert som en FPGA, slik at du kan «laste» en effektiv del av CPU-en, men ingen av disse har noen gang kommet på markedet (så vidt jeg vet).

Kommentarer

• For eksempel på reversering av bits (og alle andre bit bytte / velge oppgaver) det tar ‘ det tar egentlig ikke en klokkesyklus, det tar 0. I ditt eksempel tar det 1 klokkesyklus å lagre data i en lås , som ikke er den samme operasjonen. Det tar en tidssyklus om du reverserer bitene eller ikke. Operasjonen med å reversere bitene er 0 kloksykluser; ingen overhead, bare forskjellige rutinger. Forskjellen er ikke bare semantikk, spesielt når du begynner å legge til ting. Hvor lang tid tar det for eksempel å flytte et 32-biters ord ned på 3 biter, så bytte annenhver nipp, og deretter reversere det?
• » hybrid FPGA-CP U-modul » – disse har vært på markedet i lang tid (se xilinx.com/products/silicon-devices/ soc / zynq-7000 / index.htm for en moderne vellykket), men selv uten spesiell støtte, kombineres programvare & HDL ofte ved å implementere en myk CPU inne FPGA på stoffet.
• @wjl Du ‘ har rett i at det teknisk sett ikke tar noen sykluser for å utføre selve operasjonen. Jeg vil hevde at eksemplet ditt bare er semantisk annerledes, hovedsakelig fordi det å gjøre disse tre operasjonene logisk oversettes til et fast bitmønster (dvs. jeg starter med b1b2b3b4 og jeg slutter med b3b1b4b2). Dette var litt av poenget mitt i hele svaret. Jeg prøvde å påpeke at å beskrive en operasjon som en serie trinn ofte ofte bare er nødvendig når du har et fast instruksjonssett / portarrangement.
• @wjl: Slik David-Gardner stilte spørsmålet, han ser ut til å si » CPU » tilsvarer en Intel eller AMD x86 / x86_64 høyt klokket, rørledd og optimalisert CPU. Det er mange myke » CPUer » men jeg ingen av de som er designet for å sitte i en FPGA kan klokkes som en i7, og er heller ikke de nesten like optimaliserte eller i stand. Når det gjelder hybrider, mente jeg mer noe slikt: newsroom.intel.com/docs/DOC-1512 som tilsynelatende finnes
• Zynq er egentlig ikke ‘ ikke så ille av en prosessor (ARM Cortex-A9 – det samme som kjører nettbrett osv.), Men jeg er enig i at det ville være mye mer fantastisk å ha en integrert FPGA med høy hastighet x86_64. =)

Alle de andre populære svarene som presenteres her, snakker om bokstavelige forskjeller mellom FPGA og CPU. De peker på den parallelle karakteren til FPGA mot den sekvensielle karakteren til en CPU, eller gir eksempler på hvorfor visse algoritmer kan fungere bra på en FPGA. Alle disse er gode og sanne, men jeg vil imidlertid foreslå at det er en mer grunnleggende forskjell mellom CPUer og FPGAer.

Hva er fellesnevneren mellom en FPGA og en CPU? Det er at de begge er bygget på toppen av silisium. Og i noen tilfeller bokstavelig talt de samme silisiumprosessene.

Den grunnleggende forskjellen er abstraksjonene vi legger på toppen av det silisiumet. Det er ikke mulig for et menneske å forstå detaljene i et enkelt moderne CPU-design fra silisium til pakket IC. Så som en del av ingeniørprosessen deler vi det komplekse problemet i mindre håndterbare problemer som mennesker kan pakke hodet rundt.

Vurder hva som skal til for å gjøre det silisiumet til en fungerende CPU. Her er et noe forenklet syn på abstraksjonene som er nødvendige for det målet:

1. Først har vi ingeniører som vet hvordan man lager transistorer fra silisium. De vet hvordan de skal designe bittesmå transistorer som nipper til strøm og bytter med en hastighet på 10 eller til og med 100-tallet gigahertz, og de vet hvordan de skal designe kraftige transistorer som kan drive signaler med nok kraft til å sende dem ut av en IC-pakke og over et PCB til en annen brikke.

2. Så har vi digitale logikkdesignere som vet hvordan de skal sette disse transistorene sammen til biblioteker med hundrevis av forskjellige logiske celler. Logiske porter, flip flops, muxes og adders, for å nevne noen. Alt i en rekke konfigurasjoner.

3. Deretter har vi forskjellige grupper av ingeniører som vet hvordan de skal settes sammen (og noen ganger analoge) blokker for å danne funksjonelle blokker på høyere nivå som høyhastighets-mottakere, minnekontrollere, grenprediktorer, ALUer osv.

4. Så har vi CPU-designere til å arkitektere high-end CPU-design ved å trekke sammen de funksjonelle enhetene til et komplett system.

Og det stopper ikke der. På dette tidspunktet har vi en fungerende CPU som kjører monteringskode, men det er ikke et språk de fleste programmerere skriver til i disse dager.

5. Vi kan ha en C-kompilator som kompilerer til montering kode (sannsynligvis gjennom noen mellomrepresentasjon)
6. Vi kan legge til en annen abstraksjon på toppen av C for å få et objektorientert språk
7. Vi kan til og med skrive en virtuell maskin på toppen av C eller C ++ slik at vi kan tolke ting som Java-byte-kode

Og abstraksjonslagene kan fortsette derfra. Det viktige poenget her er at disse abstraksjonslagene kombineres for å gi et CPU-basert system som skalerer massivt og koster en liten brøkdel av et tilpasset silisiumdesign.

Det viktige poenget som skal gjøres her er imidlertid at hver abstraksjon også bærer en kostnad selv. Transistordesigneren bygger ikke den perfekte transistoren for enhver brukstilfelle. Han bygger et rimelig bibliotek, og noen ganger brukes det en transistor som bruker litt mer kraft eller litt mer silisium enn det som virkelig er nødvendig for jobben. Og på samme måte bygger ikke logikkdesignerne alle mulige logiske celler. De bygger kanskje en NAND-port med 4 innganger og en NAND-port med 8 innganger, men hva skjer når en annen ingeniør trenger en NAND med 6 innganger? Han bruker en 8-inngangs NAND-port og binder av 2 ubrukte innganger som resulterer i tapte silisiumressurser og midjekraft. Og slik går det opp i kjeden av abstraksjoner. Hvert lag gir oss en måte å håndtere kompleksiteten på, men samtidig belaste oss en ekstra inkrementell kostnad når det gjelder silisium og kraft.

Sammenlign nå disse abstraksjonene med det som trengs for en FPGA. I hovedsak stopper FPGA-abstraksjonene på # 2 i listen ovenfor. FPGA lar utviklere jobbe med det digitale logiske laget. Det er noe mer sofistikert enn det fordi CPUer er hardkodet på dette laget og FPGA-er må konfigureres på kjøretid (som, BTW, er grunnen til at CPU-er vanligvis kjører mye høyere frekvenser), men den viktige viktige sannheten er at det er langt få abstraksjoner for FPGAer enn for CPUer.

Så, Hvorfor kan en FPGA være raskere enn en CPU? I hovedsak er det fordi FPGA bruker langt færre abstraksjoner enn en CPU, noe som betyr at designeren jobber nærmere silisiumet. Han betaler ikke kostnadene for alle de mange abstraksjonslagene som kreves for CPUer. Han koder på et lavere nivå og må jobbe hardere for å oppnå en gitt funksjonalitet, men belønningen får han høyere ytelse.

Men selvfølgelig er det en nedside for færre abstraksjoner også. Alle disse CPU-abstraksjonene er der med god grunn. De gir oss et mye enklere kodingsparadigme som betyr at flere enkelt kan utvikle seg for dem. Det betyr igjen at det eksisterer mange flere CPU-design, og dermed har vi enorme pris / skala / time-to-market fordeler fra CPUer.

Så der har du det. FPGA-er har færre abstraksjoner, og de kan derfor være raskere og mer strømeffektive, men vanskelige å programmere for. CPUer har mange abstraksjoner som gjør dem enkle å utvikle for, skalerbare og billige. Men de gir opp hastighet og kraft i handel for disse fordelene.

Kommentarer

• Også FPGA ‘ s er designet ved hjelp av enkle repeterende blokker som skal utføre enkle logiske oppgaver. De er skreddersydd for visse typer oppgaver.CPU ‘ s, OTOH, har mange komplekse funksjonelle deler som alle gjør forskjellige ting. Man kan tenke at en CPU er en gruppe med mange forskjellige FPGA-lignende enheter (det er tross alt ‘ alt bare silisium, elektronikk og matematikk). Så det ‘ handler bare ikke om abstraksjoner, det ‘ handler om kompleksitet. CPU ‘ er komplekse enheter som består av mange forskjellige typer elektriske enheter, mens en FPGA består av noen få. En CPU er en hagle mens en FPGA er en rifle.

Mens de andre svarene er riktige , ingen av dem adresserer enda bitcoineksempler fra spørsmålet ditt, som faktisk er et anstendig eksempel. Bitcoin-gruvedrift innebærer gjentatte ganger å beregne en kryptografisk hashfunksjon, SHA-256 av resultatet av en annen SHA-256-beregning, av data der bare et enkelt 32-biters heltall endres, til den resulterende hash har visse egenskaper. Hver SHA-256 består av 64 repetisjoner av den samme algoritmen som involverer 32-biters tillegg, bitshifts og noen flere bit-mangling-operasjoner.

Hvis du programmerer denne sløyfen på en 32-biters (eller mer) CPU , vil du finne instruksjonssettet sitt veldig godt egnet for oppgaven — SHA-256 ble designet for å kjøre effektivt på CPUer. Likevel vil du bare bruke kanskje 2% av en moderne CPUs silisiumområde, med arealintensiv funksjonalitet som caching, multiplikasjon, divisjon, flytende punktoperasjon, forgrening og prediksjon, etc., enten ikke brukt i det hele tatt eller ikke kan gi betydelig ytelsesforbedring for denne spesifikke oppgaven.

I konfigurerbar maskinvare som en FPGA, implementerer du bare bare de 2%, og optimaliserer ytterligere ved å glemme alt om kodeutførelse, i stedet for å designe porter for å direkte beregne hver enkelt av de ofte gjentatte underfunksjonene. Rørledd slik at hver av dem overfører et resultat til neste klokke, og gjentas 128 ganger (og med noen spesiell tilleggslogikk der hver SHA-256 begynner og slutter), ender du opp med å få et resultat hver klokkesyklus (for kanskje 100 millioner hashes per sekund på en FPGA som er annonsert for å støtte 300 MHz på enklere logikk enn dette) mens du er på en moderne CPU, kan du forvente ett resultat noen få tusen klokkesykluser per kjerne, si 10 millioner hashes per sekund på en multi-core multi-GHz CPU.

Hvis dette spesielle eksemplet er av interesse for deg, kan det være lurt å ta en titt på den relaterte svar om internene til ASIC-gruvearbeidere på bitcoin.stackexchange, siden mange FPGA-gruvearbeidere arbeider på samme måte ved hjelp av konfigurerbar snarere enn skreddersydd maskinvare. Bare for fullstendighets skyld: Det er andre muligheter, som å begrense eller unngå rørledningen jeg beskrev til fordel for en mer triviell parallellisering ved å bruke flere uavhengige SHA-256-hasherer. Avhengig av begrensningene gitt av FPGAs interner og dens totale størrelse , som til og med kan gi bedre ytelse, selv om det ville være mindre effektivt når det gjelder porttelling og ruting overhead hvis du hadde perfekt frihet til å designe hele brikken, ikke bare en FPGAs konfigurasjon.

Kommentarer

• At ‘ er et veldig godt poeng om bruk av silisium.
• Men kanskje (utilsiktet!) misvisende, vurderer at en FPGA består av noe komplekse celler med mange fysiske porter, hvorav en typisk applikasjon igjen bare bruker en brøkdel, slik at produsentene deres kan annonsere tilsvarende portteller i et forsøk på å fortelle deg hvor mye alt dette kan være verdt i en » typisk » applikasjon …

Svarene ovenfor, mens de er korrekte, savner poenget ca. hvorfor FPGAer (og egendefinerte ASICer) er spesielt gode for bitcoin-beregninger.

Den virkelige fordelen er at en stor andel av SHA-256-beregningene er logiske operasjoner (for eksempel bitskift) som kan gjøres i ledninger. Når du er ferdig på denne måten, krever de 0 kloksykluser.

En annen viktig fordel er at FPGA-er er mye mer energieffektive (dvs. MIPS per watt) enn CPUer, så mengden energi som kreves for beregningene er mye mindre. Dette er viktig fordi kostnadene ved gruvedrift av bitcoin avhenger av hvor mye strøm du bruker for å lage det.

ASIC-chips er mer energieffektive enn FPGAer, slik at de kan utføre den samme koden mye billigere. Du kan også stappe flere kjøringsenheter ombord for å gjøre dem raskere. Ulempen er at kostnadene ved å lage en tilpasset ASIC er veldig høye, så du må selge ganske mange sjetonger for å dekke produksjonskostnadene.

GPUer brukes også til å lage bitcoins, men siden de er mye mindre energieffektive har de mistet terreng for FPGAer og tilpassede ASIC-er.

Kommentarer

• Hvis du ser på Monero-hashing-algoritmen aka cryptonight, vil du se at en FPGA-implementering er nesten umulig på grunn av den høye mengden minnet måtte nås tilfeldig (2 MB). En CPU har fordelen i dette tilfellet.
• @ lucas92 kan du ikke integrere RAM i FPGA for å imøtekomme mengden minne som trengs?
• Du vant sannsynligvis ‘ t har nok logiske elementer i FPGA til det.