Hur kan en FPGA överträffa en CPU?

CPU ”s är sekventiella bearbetningsenheter. De delar upp en algoritm i en sekvens av operationer och kör dem en i taget.

FPGA” s är (eller kan konfigureras som) parallella bearbetningsenheter. En hel algoritm kan exekveras i ett enda klockfel eller, i värsta fall, mycket färre klockfästingar än det tar en sekventiell processor. En av kostnaderna för den ökade logiska komplexiteten är vanligtvis en nedre gräns för vilken enheten kan klockas.

Med tanke på ovanstående kan FPGA: s överträffa CPU: er som utför vissa uppgifter eftersom de kan göra samma uppgift i mindre klockor, om än med en lägre total klockfrekvens. Vinsterna som kan uppnås är mycket beroende av algoritmen, men åtminstone en storleksordning är inte atypisk för något som en FFT.

Dessutom, eftersom du kan bygga flera parallella exekveringsenheter till en FPGA, om du har en stor datamängd som du vill skicka genom samma algoritm, kan du distribuera data över de parallella exekveringsenheterna och få ytterligare storleksordningar högre genomströmning än vad som kan uppnås med till och med en flerkärnig CPU.

Priset du betalar för fördelarna är strömförbrukning och $$$ ”s.

Kommentarer

• +1; FPGAs dock är inte lika dynamiska som processorer, varför processorer vanligtvis är bättre lämpade för datorer
• ” Priset du betalar för fördelarna är strömförbrukning och $$$ ’ s. ” – Detta är ofta sant, men du kan helt enkelt slå en avancerad multi- $ 1000 Intel Xeon-maskin med en low-end $ 50 Xilinx Spartan-6 för många algoritmer. Men det tar vanligtvis mycket teknisk tid och du kan sluta med en mycket anpassad design som bara fungerar för en applikation och är svår att ändra. Avvägningen är alltså inte bara makt och pengar, utan algoritmutvecklingstid, återanvändbarhet och flexibilitet. (Även om du kan argumentera för tid == pengar.)
• markt, om din sista mening, är ’ inte FPGA mycket lägre effekt än processorer? Det finns ett brett utbud av enheter för både processorer och FPGA, men om vi tittar på de som används för saker som bitmyntbrytning, är ’ t de processorer som används för dem gör mycket mer energikrävande än de FPGA som skulle användas?
• @David: När man talar om Bitcoin-gruvdrift är det relevanta måttet antal hash per watt. Markt pratar om den totala energiförbrukningen. Det vill säga, en given FPGA kan förbruka 3 gånger kraften hos en typisk CPU, men vara mycket mer än 3 gånger snabbare vid Bitcoin-gruvdrift; så för Bitcoin att ’ är en vinst.
• @Billy: antalet haschar per watt · sekund, inte per watt.

Markt har detta mestadels rätt, men jag ska kasta in mina 2 cent här:

Tänk dig att jag sa till dig att jag ville skriva ett program som omvända ordningen på bitar inuti ett 32-bitars heltal. Något liknande:

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 är min implementering inte elegant, men jag är säker på att du håller med om att det skulle vara ett antal operationer involverade i att göra detta, och förmodligen någon form av loop. Det betyder att du i CPU: n har spenderat mycket mer än en cykel för att genomföra denna operation.

I en FPGA kan du helt enkelt koppla upp detta som ett par spärrar. Du får dina data i något register, sedan kopplar du in det i det andra registret i omvänd bitordning. Detta innebär att operationen kommer att slutföras i en enda klockcykel i FPGA. Således, i en enda cykel, har FPGS slutfört en operation som tog din allmänna CPU många tusen cykler att slutföra! Dessutom kan du troligtvis koppla upp några hundra av dessa register parallellt. Så om du kan flytta några hundra siffror till FPGA, kommer det i en enda cykel att avsluta de tusentals operationerna hundratals gånger, allt i en FPGA-klockcykel.

Det finns många saker som en allmänt CPU kan göra, men som en begränsning ställer vi in allmänna och enkla instruktioner som nödvändigtvis måste utvidgas till listor med enkla instruktioner för att slutföra vissa uppgifter. Så jag skulle kunna få CPU för allmänna ändamål att ha en instruktion som ”omvänd bitordning för 32-bitarsregister” och ge CPU samma kapacitet som FPGA vi just byggde, men det finns ett oändligt antal sådana möjliga användbara instruktioner, och så vi lägg bara i de som motiverar kostnaden i de populära processorerna.

FPGA, CPLD och ASIC ger dig åtkomst till den råa hårdvaran, vilket gör att du kan definiera galna operationer som ”dekryptera AES256-krypterade byte med nyckel” eller ”avkoda ram för h.264-video”. Dessa har fördröjningar på mer än en klockcykel i en FPGA, men de kan implementeras på mycket effektivare sätt än att skriva ut operationen i miljoner rader med allmänna kod. Detta har också fördelen att göra FPGA / ASIC med fasta ändamål för många av dessa operationer mer energieffektiva eftersom de inte behöver göra så mycket främmande arbete!

Parallelism är den andra delen som marknadsför påpekade, och även om det också är viktigt, är det viktigaste när en FPGA parallelliserar något som redan var dyrt i CPU när det gäller cykler som behövs för att utföra operationen. När du börjar säga ”Jag kan utföra i 10 FPGA-cykler en uppgift som tar min CPU 100 000 cykler, och jag kan utföra den här uppgiften parallellt med 4 objekt åt gången, ”du kan lätt se varför en FPGA kan vara mycket snabbare än en CPU!

Så varför använder vi inte FPGA, CPLD och ASIC för allt? För att det i allmänhet är ett helt chip som inte gör något annat än en operation. Detta innebär att även om du kan få en process för att köra många storleksordningar snabbare i din FPGA / ASIC, kan du inte ändra den senare när den åtgärden inte längre är användbar. Anledningen till att du inte kan (generellt) ändra en FPGA en gång det är i en krets att ledningarna för gränssnittet är fasta, och normalt innehåller kretsen inte komponenter som gör att du kan programmera om FPGA till en mer användbar konfiguration. Det finns några forskare som försöker bygga hybrid FPGA-CPU-moduler, där det finns en del av CPU: n som kan omkopplas / omprogrammeras som en FPGA, så att du kan ”ladda” en effektiv del av CPU: n, men ingen av dessa har någonsin kommit på marknaden (så vitt jag känner till).

Kommentarer

• För exempel på att vända bitar (och alla andra bitar byta / markera uppgifter) det tar ’ det tar verkligen inte en klockcykel, det tar 0. I ditt exempel tar det 1 klockcykel att lagra data i en spärr , vilket inte är samma operation. Det tar 1 klockcykel oavsett om du backar bitarna eller inte. Funktionen för att vända bitarna är 0 klockcykler, ingen overhead, bara olika routing. Skillnaden är inte bara semantik, särskilt när du börjar lägga upp saker. Till exempel, hur lång tid tar det att flytta ett 32-bitars ord nedåt med 3 bitar, byta sedan varannan nippel och sedan vända det?
• ” hybrid FPGA-CP U-modul ” – dessa har funnits på marknaden länge (se xilinx.com/products/silicon-devices/ soc / zynq-7000 / index.htm för en modern framgångsrik), men även utan särskilt stöd, kombinerar man mjukvara & HDL vanligtvis genom att implementera en mjuk CPU inuti FPGA på tyget.
• @wjl Du ’ har rätt att det tekniskt inte tar några cykler för att utföra själva operationen. Jag skulle hävda att ditt exempel bara är semantiskt annorlunda, främst för att göra dessa tre operationer logiskt översätts till ett fast bitmönster (dvs jag börjar med b1b2b3b4 och jag slutar med b3b1b4b2). Detta var typ av min poäng i hela svaret. Jag försökte påpeka att det ofta bara är nödvändigt att beskriva en operation som en serie steg när du har en fast instruktionsuppsättning / grindarrangemang.
• @wjl: Hur David-Gardner ställde frågan, han verkar säga att ” CPU ” motsvarar en Intel eller AMD x86 / x86_64 mycket klockad, pipelined och optimerad CPU. Det finns många mjuka ” CPU ” men jag ingen av dem som är utformade för att sitta i en FPGA kan klockas som en i7, och inte heller de är nästan lika optimerade eller kapabla. När det gäller hybrider menade jag mer något så här: newsroom.intel.com/docs/DOC-1512 som uppenbarligen finns
• Zynq är verkligen inte ’ inte så illa med en processor (ARM Cortex-A9 – samma sak som kör surfplattor, etc), men jag håller med om att det skulle vara mycket mer fantastiskt att ha en integrerad FPGA med x86_64 med hög hastighet. =)

Alla andra populära svar som presenteras här talar om bokstavliga skillnader mellan FPGA och CPU. De pekar på FPGA: s parallella natur mot en processors sekventiella natur, eller ger exempel på varför vissa algoritmer kan fungera bra på en FPGA. Alla dessa är bra och sanna, men jag föreslår dock att det finns en mer grundläggande skillnad mellan CPU: er och FPGA: er.

Vad är den gemensamma nämnaren mellan en FPGA och en CPU? Det är att de båda är byggda ovanpå kisel. Och i vissa fall bokstavligen samma kiselprocesser.

Den grundläggande skillnaden är abstraktionerna som vi staplar ovanpå det kislet. Det är inte möjligt för en människa att förstå detaljerna i en enda modern CPU-design från kisel till förpackad IC. Så som en del av ingenjörsprocessen delar vi upp det komplexa problemet i mindre hanterbara problem som människor kan linda huvudet runt.

Tänk på vad som krävs för att göra kislet till en fungerande processor. Här är en något förenklad bild av de abstraktionsskikt som är nödvändiga för det målet:

1. Först har vi ingenjörer som vet hur man skapar transistorer från kisel. De vet hur man konstruerar små transistorer som sippar ström och växlar med en hastighet på 10 eller till och med 100-talet gigahertz, och de vet hur man utformar kraftiga transistorer som kan driva signaler med tillräckligt med kraft för att skicka dem från ett IC-paket och över ett PCB till ett annat chip.

2. Sedan har vi digitala logikdesigners som vet hur man sätter ihop dessa transistorer till bibliotek med hundratals olika logikceller. Logiska grindar, flip-flops, muxes och adders, för att nämna några. Allt i en mängd olika konfigurationer.

3. Därefter har vi olika grupper av ingenjörer som vet hur man sätter ihop dessa digitala (och ibland analoga) block för att bilda funktionsblock på högre nivå som höghastighetssändtagare, minnesstyrenheter, grenprediktorer, ALU: er osv.

4. Sedan har vi CPU-designers för att bygga avancerade CPU-design genom att dra ihop de funktionella enheterna till ett komplett system.

Och det stannar inte där. Vid den här tiden har vi en fungerande CPU som kör församlingskod men det är inte ett språk som de flesta programmerare skriver till idag.

5. Vi kan ha en C-kompilator som kompilerar för montering kod (troligen genom någon mellanrepresentation)
6. Vi kan lägga till ytterligare en abstraktion ovanpå C för att få ett objektorienterat språk
7. Vi kan till och med skriva en virtuell maskin ovanpå C eller C ++ så att vi kan tolka saker som Java-byte-kod

Och abstraktionsskikten kan fortsätta därifrån. Den viktiga punkten här är att dessa abstraktionslager kombineras för att ge ett CPU-baserat system som skalas massivt och kostar en liten del av en anpassad kiseldesign.

Dock är den viktiga punkten att göra här att varje abstraktion också medför en kostnad själv. Transistordesignern bygger inte den perfekta transistorn för alla användningsfall. Han bygger ett rimligt bibliotek, och ibland används en transistor som förbrukar lite mer kraft eller lite mer kisel än vad som verkligen behövs för jobbet. Och på liknande sätt bygger logikdesignerna inte alla möjliga logikceller. De kan bygga en NAND-grind med 4 ingångar och en NAND-grind med 8 ingångar, men vad händer när en annan ingenjör behöver en 6-ingångs-NAND? Han använder en 8-ingångs NAND-grind och binder av 2 oanvända ingångar vilket resulterar i förlorade kiselresurser och midjekraft. Och så går det upp i kedjan av abstraktioner. Varje lager ger oss ett sätt att hantera komplexiteten, men samtidigt tar vi en extra inkrementell kostnad när det gäller kisel och kraft.

Jämför nu dessa abstraktioner med vad som behövs för en FPGA. I grund och botten stannar FPGA-abstraktionerna vid # 2 i listan ovan. FPGA tillåter utvecklare att arbeta med det digitala logiklagret. Det är något mer sofistikerat än så eftersom CPU: er är ”hårdkodade” vid detta lager och FPGA: er måste konfigureras vid körningstid (vilket, BTW, är därför CPU: er vanligtvis kör mycket högre frekvenser), men den viktiga viktiga sanningen är att det är långt få abstraktioner för FPGA: er än för CPU: er.

Så, Varför kan en FPGA vara snabbare än en CPU? I grund och botten beror det på att FPGA använder mycket färre abstraktioner än en CPU, vilket innebär att designern arbetar närmare kisel. Han betalar inte kostnaderna för alla de många abstraktionslager som krävs för processorer. Han kodar på en lägre nivå och måste arbeta hårdare för att uppnå en viss funktionalitet men belöningen får han högre prestanda.

Men det finns naturligtvis en nedsida för färre abstraktioner också. Alla dessa CPU-abstraktioner finns med goda skäl. De ger oss ett mycket enklare kodningsparadigm vilket innebär att fler lätt kan utveckla för dem. Det innebär i sin tur att det finns många fler CPU-mönster som finns och därmed har vi massiva fördelar med pris / skala / time-to-market från CPU: er.

Så där har du det. FPGA: er har färre abstraktioner och så kan de vara snabbare och mer energieffektiva men svåra att programmera för. Processorer har många abstraktionsdesigner som gör dem lätta att utveckla för, skalbara och billiga. Men de ger upp hastighet och kraft i handeln för dessa fördelar.

Kommentarer

• FPGA ’ s är utformade med enkla repetitiva block som ska utföra enkla logiska uppgifter. De är skräddarsydda för vissa typer av uppgifter.CPU ’ s, OTOH, har många komplexa funktionella delar som alla gör olika saker. Man kan överväga att en CPU är en grupp med många olika FPGA-liknande enheter (trots allt ’ är allt bara kisel, elektronik och matematik). Så det ’ handlar bara inte om abstraktioner, det ’ handlar om komplexitet. CPU ’ är komplexa enheter som består av många olika typer av elektriska enheter medan en FPGA består av några få. En CPU är ett hagelgevär medan en FPGA är ett gevär.

Medan de andra svaren är korrekta , ingen av dem tar ännu upp bitcoinbrytningsexemplet från din fråga, vilket verkligen är ett anständigt exempel. Bitcoin-gruvdrift innebär upprepade gånger att beräkna en kryptografisk hashfunktion, SHA-256 av resultatet av en annan SHA-256-beräkning, av data där endast ett enda 32-bitars heltal ändras tills den resulterande hash har vissa egenskaper. Varje SHA-256 består av 64 repetitioner av samma algoritm som involverar 32-bitars tillägg, bitförskjutningar och några fler bitmanglande operationer.

Om du programmerar den här slingan på en 32-bitars (eller mer) CPU , hittar du dess instruktionsuppsättning mycket lämplig för uppgiften — SHA-256 var utformad för att fungera effektivt på processorer. Fortfarande kommer du bara att använda kanske 2% av en modern CPU: s kiselarea, med områdesintensiv funktion som cachning, multiplikation, division, flytande punktoperation, förgrening och brach-förutsägelse etc., antingen inte används alls eller inte kan ge betydande prestandaförbättring för just den här uppgiften.

I konfigurerbar hårdvara som en FPGA implementerar du bara dessa 2% och optimerar ytterligare genom att glömma allt om kodkörning, snarare utformar grindar för att direkt beräkna var och en av de ofta upprepade underfunktionerna. Rörledas så att var och en av dem skickar ett resultat till nästa varje klockcylcke, och upprepas 128 gånger (och med någon speciell extra logik där varje SHA-256 börjar och slutar), får du ett resultat var klockcykel (för kanske 100 miljoner hashes per sekund på en FPGA som annonseras för att stödja 300 MHz på enklare logik än detta) medan du är på en modern CPU, kan du förvänta dig ett resultat med några tusen klockcykler per kärna, säg 10 miljoner hashes per sekund på en flerkärnig processor med flera GHz.

Om det här exemplet är av intresse för dig kanske du vill titta på min relaterade svara om internt hos ASIC-gruvarbetare på bitcoin.stackexchange, eftersom många FPGA-gruvarbetare arbetar på samma sätt med konfigurerbar snarare än skräddarsydd hårdvara. Bara för fullständighetens skull: Det finns andra möjligheter, som att begränsa eller undvika rörledningen som jag beskrev till förmån för en mer trivial parallellisering genom att använda flera oberoende SHA-256-hasherer. , som till och med kan ge bättre prestanda även om det skulle vara mindre effektivt när det gäller grindräkning och dirigeringskostnader om du hade perfekt frihet att utforma hela chipet, inte bara en FPGA-konfiguration.

Kommentarer

• Att ’ är en mycket bra punkt om användning av kisel.
• Men kanske (oavsiktligt!) vilseledande, med tanke på att en FPGA består av något komplexa celler med många fysiska grindar, av vilka en typisk applikation bara använder en bråkdel, vilket gör att deras tillverkare kan annonsera motsvarande grindräkningar i ett försök att berätta hur mycket allt detta kan vara värt i en ” typisk ” applikation …

Svaren ovan, medan de är korrekta, saknar poängen om varför FPGA (och anpassade ASIC) är särskilt bra för bitcoinberäkningar.

Den verkliga fördelen är att en stor del av SHA-256-beräkningarna är logiska operationer (till exempel bitförskjutningar) som kan göras i ledningar. När det görs på detta sätt kräver de 0 klockcykler.

En annan viktig fördel är att FPGA: er är mycket mer energieffektiva (dvs MIPS per Watt) än processorer, så den mängd energi som krävs för beräkningarna är mycket mindre. Detta är viktigt eftersom kostnaden för att bryta bitcoin beror på hur mycket el du använder för att göra det.

ASIC-chips är mer energieffektiva än FPGA, så att de kan utföra samma kod mycket billigare. Du kan också klämma in fler exekveringsenheter ombord för att göra dem snabbare. Nackdelen är att kostnaden för att skapa en anpassad ASIC är mycket hög, så du måste sälja en hel del marker för att täcka tillverkningskostnaden.

GPU: er används också för att tillverka bitcoins, men eftersom de är mycket mindre energieffektiva har de tappat marken för FPGA och anpassade ASIC.

Kommentarer

• Om du tittar på Monero-hashingalgoritmen aka cryptonight, kommer du att se att en FPGA-implementering är nästan omöjlig på grund av den höga minnet behövs för att nås slumpmässigt (2 MB). En processor har fördelen i det här fallet.
• @ lucas92 kan du inte integrera RAM i FPGA för att tillgodose mängden minne som behövs?
• Du har förmodligen vunnit ’ t har tillräckligt med logiska element i FPGA för det.