Hvordan kan en FPGA overgå en CPU?

CPU “s er sekventielle behandlingsenheder. De opdeler en algoritme i en række af operationer og udfører dem en ad gangen.

FPGA” er (eller kan konfigureres som) parallelle behandlingsenheder. En hel algoritme kan udføres i et enkelt kryds af uret, eller i værste fald langt færre urflåter, end det tager en sekventiel processor. En af omkostningerne ved den øgede logiske kompleksitet er typisk en nedre grænse, hvormed enheden kan klokkes.

Under hensyntagen til ovenstående kan FPGAer overgå CPUer, der udfører bestemte opgaver, fordi de kan udføre den samme opgave i færre urflåter, omend med en lavere samlet urfrekvens. De gevinster, der kan opnås, er meget afhængige af algoritmen, men i det mindste er en størrelsesorden ikke atypisk for noget som en FFT.

Yderligere, fordi du kan bygge flere parallelle eksekveringsenheder til en FPGA, hvis du har en stor mængde data, som du vil passere gennem den samme algoritme, kan du distribuere dataene på tværs af de parallelle eksekveringsenheder og få yderligere størrelsesordrer højere gennemstrømning end der kan opnås med selv en multi-core CPU. p>

Den pris, du betaler for fordelene, er strømforbrug og $$$ “s.

Kommentarer

• +1; FPGAer dog er ikke så dynamiske som CPUer, hvorfor CPUer normalt er bedre egnet til pcer
• ” Prisen, du betaler for fordelene, er strømforbrug og $$$ ‘ s. ” – Dette er ofte sandt, men du kan helt slå en high-end multi- $ 1000 Intel Xeon-maskine med en low-end $ 50 Xilinx Spartan-6 til mange algoritmer. Men det tager typisk meget teknisk tid, og du kan ende med et meget tilpasset design, der kun fungerer til en applikation og er svært at ændre. Så kompromisen er ikke kun magt og penge, men algoritmeudviklingstid, genanvendelighed og fleksibilitet. (Selvom du kan argumentere for tid == penge.)
• markt, om din sidste sætning, er ‘ t FPGAer meget lavere effekt end CPUer? Der er en bred vifte af enheder til både CPUer og FPGAer, men hvis vi ser på dem, der bruges til ting som minedrift, er ‘ t de CPUer, der bruges til dem opgaver meget mere magthungrende end de FPGAer, der ville blive brugt?
• @ David: Når vi taler om Bitcoin-minedrift, er den relevante metric antallet af hashes pr. watt. Markt taler om det samlede strømforbrug. Det vil sige, at en given FPGA kan forbruge 3 gange effekten af en typisk CPU, men være meget mere end 3 gange hurtigere ved Bitcoin-minedrift; så for Bitcoin, at ‘ er en gevinst.
• @Billy: antallet af hashes pr. watt · sekund, ikke pr. watt.

Markt har dette stort set rigtigt, men jeg vil kaste mine 2 cent her:

Forestil dig, at jeg fortalte dig, at jeg ville skrive et program, der vendte rækkefølgen af bits inde i et 32-bit heltal. Noget 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; } 

Nu er min implementering ikke elegant, men jeg er sikker på, at du er enig i, at der vil være et antal operationer involveret i at gøre dette, og sandsynligvis en slags loop. Dette betyder, at du i CPUen har brugt meget mere end 1 cyklus til at gennemføre denne operation.

I en FPGA kan du blot koble dette som et par låse. Du får dine data i noget register, så kabler du det ind i det andet register i omvendt bitrækkefølge. Dette betyder, at operationen afsluttes i en enkelt urcyklus i FPGA. Således har FPGS i en enkelt cyklus gennemført en operation, der tog din generelle formål CPU mange tusinde cykler at gennemføre! Derudover kan du sammenkoble sandsynligvis et par hundrede af disse registre parallelt. Så hvis du kan flytte et par hundrede numre ind på FPGA, vil det i en enkelt cyklus afslutte de tusindvis af operationer hundreder af gange, alt sammen i 1 FPGA-urcyklus.

Der er mange ting, som en CPU til generel brug kan gøre, men som en begrænsning opretter vi generelle og enkle instruktioner, som nødvendigvis skal udvides til lister over enkle instruktioner for at udføre nogle opgaver. Så jeg kunne få den generelle CPU til at have en instruktion som “omvendt bitrækkefølge til 32 bit register” og give CPUen den samme mulighed som den FPGA, vi lige har bygget, men der er et uendeligt antal af sådanne mulige nyttige instruktioner, og så vi kun indsætte dem, der berettiger omkostningerne i de populære CPUer.

FPGAer, CPLDer og ASICer giver dig alle adgang til den rå hardware, som giver dig mulighed for at definere skøre operationer som “dekrypter AES256-krypterede bytes med nøgle” eller “afkod ramme af h.264-video”. Disse har latenstider på mere end en urcyklus i en FPGA, men de kan implementeres på langt mere effektive måder end at udskrive operationen i millioner af linjer med samlekode til generelle formål. Dette har også fordelen ved at gøre FPGA / ASIC med faste formål til mange af disse operationer mere energieffektive, fordi de ikke behøver at udføre så meget fremmet arbejde!

Parallelisme er den anden del, som markedsføres påpegede, og selvom det også er vigtigt, er det vigtigste, når en FPGA paralleliserer noget, der allerede var dyrt i CPUen med hensyn til cyklusser, der var nødvendige for at udføre operationen. Når du begynder at sige “Jeg kan udføre i 10 FPGA-cyklusser en opgave, der tager min CPU 100.000 cyklusser, og jeg kan udføre denne opgave parallelt med 4 emner ad gangen, “du kan let se, hvorfor en FPGA kunne være en masse hurtigere end en CPU!

Så hvorfor bruger vi ikke FPGAer, CPLDer og ASICer til alt? Fordi det generelt er en hel chip, der kun gør en operation. Dette betyder, at selvom du kan få en proces til at køre mange størrelsesordener hurtigere i din FPGA / ASIC, kan du ikke ændre det senere, når denne operation ikke længere er nyttig. Årsagen til at du (generelt) ikke kan ændre en FPGA en gang det er i et kredsløb, at ledningerne til grænsefladen er faste, og normalt inkluderer kredsløbet ikke komponenter, der giver dig mulighed for at omprogrammere FPGA til en mere nyttig konfiguration. Der er nogle forskere, der prøver at bygge hybrid FPGA-CPU-moduler, hvor der er en del af CPUen, der er i stand til at blive kablet / omprogrammeret som en FPGA, så du kan “indlæse” en effektiv del af CPUen, men ingen af disse har nogensinde gjort det på markedet (så vidt jeg ved).

Kommentarer

• For eksempel med at vende bits (og alle andre bit bytte / udvælge opgaver) det tager ‘ ikke rigtig 1 urcyklus, det tager 0. I dit eksempel tager det 1 urcyklus at gemme data i en lås , hvilket ikke er den samme operation. Det tager 1 urcyklus, uanset om du vender bitene eller ej. Operationen med at vende bitene er 0 urcykler, ingen overhead, bare forskellige routing. Forskellen er ikke kun semantik, især når du begynder at tilføje ting. Hvor lang tid tager det f.eks. at skifte et 32-bit ord ned på 3 bit, så bytte hver anden nippel og derefter vende det om?
• ” hybrid FPGA-CP U-modul ” – disse har været på markedet i lang tid (se xilinx.com/products/silicon-devices/ soc / zynq-7000 / index.htm for en moderne succesrig), men selv uden særlig support kombineres software & HDL almindeligvis ved at implementere en blød CPU indeni FPGA på stoffet.
• @wjl Du ‘ har ret i, at det teknisk set ikke tager nogen cykler at udføre selve operationen. Jeg vil hævde, at dit eksempel kun er semantisk anderledes, mest fordi det at gøre disse tre operationer logisk oversættes til et fast bitmønster (dvs. jeg starter med b1b2b3b4 og jeg slutter med b3b1b4b2). Dette var lidt af min pointe i hele svaret. Jeg forsøgte at påpege, at det ofte kun er nødvendigt at beskrive en operation som en række trin, når du har et fast instruktionssæt / gate-arrangement.
• @wjl: Den måde, David-Gardner stillede spørgsmålet på, han ser ud til at sige ” CPU ” svarer til en Intel eller AMD x86 / x86_64 stærkt uret, pipelined og optimeret CPU. Der er mange bløde ” CPUer ” men jeg ingen af dem, der er designet til at sidde i en FPGA, kan klokkes som en i7, og det er heller ikke de næsten lige så optimerede eller i stand. Hvad angår hybrider, mente jeg mere sådan noget: newsroom.intel.com/docs/DOC-1512 som tilsyneladende findes
• Zynq er virkelig ikke ‘ t alt for dårlig af en processor (ARM Cortex-A9 – den samme ting, der kører tablet-computere osv.), Men jeg er enig i, at det ville være langt mere fantastisk at have en integreret FPGA med en høj hastighed x86_64. =)

Alle de andre populære svar, der præsenteres her, taler om bogstavelige forskelle mellem FPGAer og CPUer. De påpeger den parallelle karakter af FPGA versus den sekventielle karakter af en CPU eller giver eksempler på, hvorfor visse algoritmer kan fungere godt på en FPGA. Alle disse er gode og sande, men jeg vil dog foreslå, at der er en mere grundlæggende forskel mellem CPUer og FPGAer.

Hvad er fællesnævneren mellem en FPGA og en CPU? Det er, at de begge er bygget oven på silicium. Og i nogle tilfælde bogstaveligt talt de samme siliciumprocesser.

Den grundlæggende forskel er abstraktionerne, som vi lægger oven på det silicium. Det er ikke muligt for et menneske at forstå den fulde detalje af et enkelt moderne CPU-design fra silicium til pakket IC. Så som en del af ingeniørprocessen deler vi det komplekse problem i mindre håndterbare problemer, som mennesker kan pakke deres hoveder rundt.

Overvej hvad der kræves for at gøre dette silicium til en fungerende CPU. Her er en noget forenklet visning af de abstraktionslag, der er nødvendige for dette mål:

1. Først har vi ingeniører, der ved, hvordan man opretter transistorer af silicium. De ved, hvordan man designer små transistorer, der nipper til strøm og skifter med en hastighed på 10 eller endda 100ere gigahertz, og de ved, hvordan de skal designe bøfede transistorer, der kan drive signaler med tilstrækkelig kraft til at sende dem ud af en IC-pakke og over et print til en anden chip.

2. Så har vi digitale logikdesignere, der ved, hvordan man sætter disse transistorer sammen til biblioteker med hundreder af forskellige logiske celler. Logiske porte, flip flops, muxes og adders, for at nævne nogle få. Alt i en række forskellige konfigurationer.

3. Dernæst har vi forskellige grupper af ingeniører, der ved, hvordan man sætter disse digitale (og undertiden analoge) blokke sammen for at danne funktionelle blokke på højere niveau som højhastigheds transceivere, hukommelsescontrollere, grenprediktorer, ALUer osv.

4. Så har vi CPU-designere til at arkitektere avancerede CPU-design ved at trække disse funktionelle enheder sammen til et komplet system.

Og det stopper ikke der. På dette tidspunkt har vi en fungerende CPU, der kører samlingskode, men det er ikke et sprog, som de fleste programmører skriver til i disse dage.

5. Vi har muligvis en C-compiler, der kompilerer til samling kode (sandsynligvis gennem en mellemliggende repræsentation)
6. Vi kunne tilføje endnu en abstraktion oven på C for at få et objektorienteret sprog
7. Vi kan endda skrive en virtuel maskine oven på C eller C ++ så vi kan fortolke ting som Java-byte-kode

Og abstraktionslagene kan fortsætte derfra. Det vigtige punkt her er, at disse abstraktionslag kombineres for at give et CPU-baseret system, der skalerer massivt og koster en lille brøkdel af et brugerdefineret siliciumdesign.

Det vigtige punkt, der skal gøres her, er imidlertid, at hver abstraktion også selv bærer en pris. Transistordesigneren bygger ikke den perfekte transistor til enhver brugssag. Han bygger et rimeligt bibliotek, og så nogle gange bruges en transistor, der bruger lidt mere strøm eller lidt mere silicium, end der virkelig er behov for det aktuelle job. Og på samme måde bygger logikdesignerne ikke alle mulige logiske celler. De bygger muligvis en NAND-gate med 4 input og en NAND-gate med 8 input, men hvad sker der, når en anden ingeniør har brug for en NAND med 6 input? Han bruger en NAND-port med 8 input og binder 2 ubrugte input, hvilket resulterer i mistede siliciumressourcer og taljekraft. Og så går det op ad abstraktionskæden. Hvert lag giver os en måde at håndtere kompleksiteten på, men samtidig opkræver vi yderligere ekstraomkostninger med hensyn til silicium og kraft.

Sammenlign nu disse abstraktioner med, hvad der er nødvendigt for en FPGA. I det væsentlige stopper FPGA-abstraktionerne ved nr. 2 i listen ovenfor. FPGA giver udviklere mulighed for at arbejde med det digitale logiske lag. Det er noget mere sofistikeret end det, fordi CPUer er hårdkodede i dette lag, og FPGAer skal konfigureres ved kørselstid (hvilket BTW er, hvorfor CPUer typisk kører meget højere frekvenser), men den vigtige vigtige sandhed er, at det er langt få abstraktioner for FPGAer end for CPUer.

Så, Hvorfor kan en FPGA være hurtigere end en CPU? I bund og grund er det fordi FPGA bruger langt færre abstraktioner end en CPU, hvilket betyder, at designeren arbejder tættere på silicium. Han betaler ikke omkostningerne for alle de mange abstraktionslag, der kræves til CPUer. Han koder på et lavere niveau og skal arbejde hårdere for at opnå en given funktionalitet, men belønningen får han højere ydeevne.

Men selvfølgelig er der en ulempe for færre abstraktioner også. Alle disse CPU-abstraktioner er der med god grund. De giver os et meget enklere kodningsparadigme, hvilket betyder, at flere mennesker let kan udvikle sig for dem. Det betyder igen, at der findes mange flere CPU-design, og derfor har vi enorme fordele ved pris / skala / time-to-market fra CPUer.

Så der har du det. FPGAer har færre abstraktioner, og de kan derfor være hurtigere og mere energieffektive, men vanskelige at programmere for. CPUer har mange abstraktionsdesign, der gør dem nemme at udvikle til, skalerbare og billige. Men de opgiver hastighed og magt i handel for disse fordele.

Kommentarer

• Også FPGA ‘ s er designet ved hjælp af enkle gentagne blokke, der skal udføre enkle logiske opgaver. De er skræddersyet til bestemte typer opgaver.CPU ‘ s, OTOH, har mange komplekse funktionelle dele, der alle gør forskellige ting. Man kunne overveje, at en CPU er en gruppe af mange forskellige FPGA-lignende enheder (det er jo ‘ alt bare silicium, elektronik og matematik). Så det ‘ handler bare ikke om abstraktioner, det ‘ handler om kompleksitet. CPU ‘ er komplekse enheder, der består af mange forskellige typer elektriske enheder, mens en FPGA består af nogle få. En CPU er en haglgevær, mens en FPGA er en riffel.

Mens de andre svar er alle korrekte , ingen af dem behandler endnu bitcoin-minedrifteksemplet fra dit spørgsmål, hvilket faktisk er et anstændigt eksempel. Bitcoin-minedrift involverer gentagne gange beregning af en kryptografisk hash-funktion, SHA-256 af resultatet af en anden SHA-256-beregning, af data, hvor kun et enkelt 32-bit heltal ændres, indtil den resulterende hash har visse egenskaber. Hver SHA-256 består af 64 gentagelser af den samme algoritme, der involverer 32-bit tilføjelser, bitshifts og nogle flere bit-mangling-operationer.

Hvis du programmerer denne loop på en 32-bit (eller mere) CPU , finder du dets instruktionssæt meget velegnet til opgaven — SHA-256 blev designet til at køre effektivt på CPUer. Stadig bruger du kun måske 2% af en moderne CPUs siliciumareal med områdekrævende funktionalitet som caching, multiplikation, division, flydende punktoperation, forgrening og prædiktion osv., Enten ikke brugt overhovedet eller ude af stand til at giver en betydelig ydeevne boost til denne særlige opgave.

I konfigurerbar hardware som en FPGA implementerer du simpelthen kun disse 2% og optimerer yderligere ved at glemme alt om kodeudførelse, snarere designe porte til direkte at beregne hver enkelt af disse ofte gentagne underfunktioner. Rørledt således, at hver af dem sender et resultat til det næste hver urcylcke, og gentaget 128 gange (og med en speciel ekstra logik, hvor hver SHA-256 begynder og slutter), ender du med at få et resultat hver urcyklus (for måske 100 millioner hashes pr. sekund på en FPGA, der annonceres for at understøtte 300 MHz på enklere logik end dette) mens du er på en moderne CPU, kan du forvente et resultat hvert par tusinde urcykler pr. kerne, siger 10 millioner hashes pr. sekund on på en multi-core multi-GHz CPU.

Hvis dette særlige eksempel er af interesse for dig, kan du se på min relaterede svar om interner fra ASIC-minearbejdere på bitcoin.stackexchange, da mange FPGA-minearbejdere arbejder på samme måde ved hjælp af konfigurerbar snarere end specialfremstillet hardware. Bare for fuldstændighedens skyld: Der er andre muligheder, som at begrænse eller undgå rørledningen, som jeg beskrev til fordel for en mere triviel parallelisering ved at bruge flere uafhængige SHA-256-hasherer. Afhængig af de begrænsninger, der er givet af dine FPGAs interner og dens samlede størrelse , der endda kan give bedre ydeevne, selvom det ville være mindre effektivt med hensyn til porttælling og routing overhead, hvis du havde perfekt frihed til at designe hele chippen, ikke kun en FPGAs konfiguration.

Kommentarer

• At ‘ er et meget godt punkt om anvendelse af silicium.
• Men måske (utilsigtet!) vildledende, i betragtning af at en FPGA består af noget komplekse celler med mange fysiske porte, hvoraf en typisk applikation kun igen bruger en brøkdel, hvilket giver deres producenter mulighed for at reklamere for tilsvarende porttællinger i et forsøg på at fortælle dig, hvor meget alt dette kan være værd i div id = “8675ac3c8a”>

Svarene ovenfor, mens de er korrekte, savner punktet ca. hvorfor FPGAer (og brugerdefinerede ASICer) er særligt gode til bitcoin-beregninger.

Den reelle fordel er, at en stor del af SHA-256-beregningerne er logiske operationer (for eksempel bitskift), som kan udføres i ledningsføring. Når det er gjort på denne måde, kræver de 0 urcyklusser.

En anden vigtig fordel er, at FPGAer er meget mere energieffektive (dvs. MIPS pr. Watt) end CPUer, så den krævede mængde energi til beregningerne er meget mindre. Dette er vigtigt, fordi omkostningerne ved minedrift af bitcoin afhænger af, hvor meget elektricitet du bruger til at fremstille det.

ASIC-chips er mere energieffektive end FPGAer, så de kan udføre den samme kode meget billigere. Du kan også proppe flere eksekveringsenheder om bord for at gøre dem hurtigere. Ulempen er, at omkostningerne ved at lave en brugerdefineret ASIC er meget høje, så du bliver nødt til at sælge en hel del chips for at dække produktionsomkostningerne.

GPUer bruges også til fremstilling af bitcoins, men da de er meget mindre energieffektive har de mistet terræn til FPGAer og tilpassede ASICer.

Kommentarer

• Hvis du ser på Monero hashing algoritme aka cryptonight, vil du se, at en FPGA implementering er næsten umulig på grund af den høje mængde hukommelse skal tilgås tilfældigt (2 MB). En CPU har fordelen i dette tilfælde.
• @ lucas92 kan du ikke integrere RAM i FPGA for at rumme den nødvendige mængde hukommelse?
• Du vandt sandsynligvis ‘ t har nok logiske elementer i FPGA til det.