Hoe kan een FPGA beter presteren dan een CPU?

CPU “s zijn sequentiële verwerkingsapparaten. Ze splitsen een algoritme op in een reeks bewerkingen en voeren ze een voor een uit.

FPGAs zijn (of kunnen worden geconfigureerd als) parallelle verwerkingsapparaten. Een heel algoritme kan worden uitgevoerd in een enkele tik van de klok, of, in het ergste geval, veel minder kloktikken dan een sequentiële processor. Een van de kosten van de toegenomen logische complexiteit is doorgaans een ondergrens waarop het apparaat kan worden geklokt.

Met het bovenstaande in gedachten kunnen FPGAs beter presteren dan CPUs bij het uitvoeren van bepaalde taken, omdat ze het kunnen doen dezelfde taak in minder kloktikken, zij het met een lagere algehele kloksnelheid. De winsten die kunnen worden behaald, zijn sterk afhankelijk van het algoritme, maar een orde van grootte is in ieder geval niet atypisch voor zoiets als een FFT.

Verder, omdat je meerdere parallelle uitvoeringseenheden in een FPGA kunt bouwen, Als u een grote hoeveelheid gegevens heeft die u door hetzelfde algoritme wilt laten gaan, kunt u de gegevens over de parallelle uitvoeringseenheden verdelen en nog meer ordes van grootte hogere doorvoer halen dan zelfs met een multi-core CPU kan worden bereikt.

De prijs die u betaalt voor de voordelen is stroomverbruik en $$$ “s.

Reacties

• +1; FPGAs echter zijn niet zo dynamisch als CPUs, daarom zijn CPUs meestal beter geschikt voor pcs.
• ” De prijs die u betaalt voor de voordelen is stroomverbruik en $$$ ‘ s. ” – Dit is vaak waar, maar je kunt een high-end multi- $ 1000 Intel Xeon-machine absoluut verslaan met een low-end $ 50 Xilinx Spartan-6 voor veel algoritmen. Maar dat kost doorgaans veel engineeringtijd en u kunt eindigen met een zeer aangepast ontwerp dat slechts voor één toepassing werkt en moeilijk te veranderen is. De afweging is dus niet alleen macht en geld, maar ook de ontwikkelingstijd van algoritmen, herbruikbaarheid en flexibiliteit. (Hoewel je over tijd == geld kunt discussiëren.)
• markt, over je laatste zin, zijn ‘ t FPGAs veel lager dan CPUs? Er is een breed scala aan apparaten voor zowel CPUs als FPGAs, maar als we kijken naar de apparaten die worden gebruikt voor zaken als bit-coin mining, zijn ‘ niet de CPUs die daarvoor worden gebruikt taken die veel meer energie verbruiken dan de FPGAs die zouden worden gebruikt?
• @David: Als we het hebben over Bitcoin-mijnbouw, is de relevante statistiek het aantal hashes per watt. Markt heeft het over het totale stroomverbruik. Dat wil zeggen, een bepaalde FPGA kan 3x de kracht van een typische CPU verbruiken, maar veel meer dan 3x sneller zijn bij Bitcoin-mining; dus voor Bitcoin is dat ‘ een overwinning.
• @Billy: het aantal hashes per watt · seconde, niet per watt.

Markt heeft dit grotendeels goed, maar ik ga mijn 2 cent hier:

Stel je voor dat ik je vertelde dat ik een programma wilde schrijven dat de volgorde van bits binnen een 32-bits geheel getal omkeerde. Iets als dit:

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 is mijn implementatie niet elegant, maar ik” ben er zeker van dat u het ermee eens bent dat er een aantal bewerkingen bij betrokken zijn om dit te doen, en waarschijnlijk een soort lus. Dit betekent dat je in de CPU veel meer dan 1 cyclus hebt besteed aan het implementeren van deze bewerking.

In een FPGA kun je dit eenvoudig aansluiten als een paar vergrendelingen. U krijgt uw gegevens in een register, en vervolgens zet u ze in omgekeerde bitvolgorde in het andere register. Dit betekent dat de operatie in de FPGA in één klokcyclus wordt voltooid. Dus in een enkele cyclus heeft de FPGS een operatie voltooid die de CPU voor algemeen gebruik vele duizenden cycli in beslag nam! Bovendien kunt u waarschijnlijk een paar honderd van deze registers parallel aansluiten. Dus als je met een paar honderd nummers naar de FPGA kunt gaan, zal het in een enkele cyclus die duizenden bewerkingen honderden keren voltooien, alles in 1 FPGA-klokcyclus.

Er zijn veel dingen die een CPU voor algemeen gebruik kan doen, maar als beperking stellen we algemene en eenvoudige instructies op die noodzakelijkerwijs moeten worden uitgebreid tot lijsten met eenvoudige instructies om sommige taken te voltooien. Dus ik zou de CPU voor algemene doeleinden een instructie kunnen geven als omgekeerde bitvolgorde voor 32-bits register en de CPU dezelfde mogelijkheden geven als de FPGA die we zojuist hebben gebouwd, maar er is een oneindig aantal van dergelijke mogelijke nuttige instructies, en dus plaats alleen degene die de kosten in de populaire CPUs garanderen.

FPGAs, CPLDs en ASICs geven je allemaal toegang tot de onbewerkte hardware, waarmee je gekke bewerkingen kunt definiëren zoals “decodeer AES256 gecodeerde bytes met sleutel” of “decodeer frame van h.264 video”. Deze hebben latenties van meer dan één klokcyclus in een FPGA, maar ze kunnen op veel efficiëntere manieren worden geïmplementeerd dan de bewerking uit te schrijven in miljoenen regels algemene montagecode. Dit heeft ook het voordeel dat de vaste FPGA / ASIC voor veel van deze bewerkingen energiezuiniger wordt omdat ze niet zoveel extern werk hoeven te doen!

Parallellisme is het andere deel dat markt aangegeven, en hoewel dat ook belangrijk is, is het belangrijkste wanneer een FPGA iets parallel stelt dat al duur was in de CPU in termen van cycli die nodig zijn om de bewerking uit te voeren. Zodra je begint te zeggen: “Ik kan presteren in 10 FPGA-cycli, een taak die mijn CPU 100.000 cycli kost, en ik kan deze taak parallel uitvoeren met 4 items tegelijk, “je kunt gemakkelijk zien waarom een FPGA veel sneller zou kunnen zijn dan een CPU!

Dus waarom gebruiken we niet overal FPGAs, CPLDs en ASICs voor? Omdat het over het algemeen een hele chip is die niets anders doet dan één bewerking. Dit betekent dat hoewel u een proces vele ordes van grootte sneller kunt laten uitvoeren in uw FPGA / ASIC, u dit later niet kunt wijzigen wanneer die bewerking niet langer nuttig is. De reden waarom u een FPGA (over het algemeen) niet één keer kunt wijzigen het zit in een circuit dat de bedrading voor de interface vast is, en normaal bevat het circuit geen componenten waarmee je de FPGA opnieuw kunt programmeren in een meer bruikbare configuratie. Er zijn enkele onderzoekers die hybride FPGA-CPU-modules proberen te bouwen, waarbij er een gedeelte van de CPU is dat opnieuw kan worden bedraad / opnieuw geprogrammeerd als een FPGA, waardoor je een effectief gedeelte van de CPU kunt laden, maar geen van deze ooit op de markt zijn gekomen (voor zover ik weet).

Opmerkingen

• Voor het voorbeeld van het omkeren van bits (en alle andere bits swap- / selectietaken) het ‘ duurt niet echt 1 klokcyclus, het duurt 0. In uw voorbeeld duurt het 1 klokcyclus om gegevens op te slaan in een latch , wat niet dezelfde bewerking is. Er is 1 klokcyclus nodig, of je de bits nu omkeert of niet. De bewerking van het omkeren van de bits is 0 klokcycli; geen overhead, alleen andere routing. Het verschil is niet alleen semantiek, vooral wanneer je begint dingen op te tellen. Hoe lang duurt het bijvoorbeeld om een 32-bits woord 3 bits naar beneden te verschuiven, dan elke andere knabbel om te wisselen en dan om te keren?
• ” hybride FPGA-CP U module ” – deze zijn al een hele tijd op de markt (zie xilinx.com/products/silicon-devices/ soc / zynq-7000 / index.htm voor een moderne succesvolle), maar zelfs zonder speciale ondersteuning, wordt het combineren van software & HDL gewoonlijk gedaan door een zachte CPU binnenin te implementeren de FPGA op de stof.
• @wjl Je ‘ hebt gelijk dat er technisch gezien geen cycli nodig zijn om de bewerking zelf uit te voeren. Ik zou echter willen zeggen dat je voorbeeld alleen semantisch anders is, vooral omdat het uitvoeren van die drie bewerkingen zich logisch vertaalt in een vast bitpatroon (d.w.z. ik begin met b1b2b3b4 en ik eindig met b3b1b4b2). Dit was een beetje mijn punt in het hele antwoord. Ik probeerde erop te wijzen dat het beschrijven van een operatie als een reeks stappen vaak alleen nodig is als je een vaste instructieset / poortopstelling hebt.
• @wjl: Zoals david-gardner de vraag stelde, hij lijkt te zeggen dat ” CPU ” equivalent is aan een Intel of AMD x86 / x86_64 sterk geklokte, gepijplijnde en geoptimaliseerde CPU. Er zijn veel zachte ” CPUs “, maar geen van degenen die zijn ontworpen om in een FPGA te zitten, kan worden geklokt als een i7, en dat geldt ook voor ze zijn bijna net zo geoptimaliseerd of capabel. Wat betreft hybriden, ik bedoelde eerder zoiets als dit: newsroom.intel.com/docs/DOC-1512 die blijkbaar wel bestaat
• de Zynq is echt niet ‘ slecht voor een processor (ARM Cortex-A9 – hetzelfde als waarop tabletcomputers draaien, enz.), Maar ik ben het ermee eens dat het veel leuker zou zijn om een geïntegreerde FPGA met een hoge snelheid x86_64. =)

Alle andere populaire antwoorden die hier worden gepresenteerd, hebben betrekking op letterlijke verschillen tussen FPGAs en CPUs. Ze wijzen op de parallelle aard van de FPGA versus de sequentiële aard van een CPU, of geven voorbeelden van waarom bepaalde algoritmen goed zouden kunnen werken op een FPGA. Deze zijn allemaal goed en waar, maar ik zou echter willen suggereren dat er een fundamenteler verschil is tussen CPUs en FPGAs.

Wat is de gemene deler tussen een FPGA en een CPU? Het is dat ze allebei op silicium zijn gebouwd. En in sommige gevallen letterlijk dezelfde siliciumprocessen.

Het fundamentele verschil zijn de abstracties die we bovenop dat silicium stapelen. Het is niet mogelijk voor één mens om de volledige details van een enkel modern CPU-ontwerp te begrijpen, van silicium tot verpakte IC. Dus als onderdeel van het engineeringproces verdelen we dat complexe probleem in kleinere beheersbare problemen waar mensen hun hoofd omheen kunnen slaan.

Bedenk wat er nodig is om van dat silicium een functionerende CPU te maken. Hier is een ietwat vereenvoudigde weergave van de abstractielagen die nodig zijn voor dat doel:

1. Ten eerste hebben we ingenieurs die weten hoe ze transistors van silicium kunnen maken. Ze weten hoe ze kleine transistors moeten ontwerpen die stroom slurpen en schakelen met een snelheid van 10 of zelfs 100 gigahertz, en ze weten hoe ze vette transistors moeten ontwerpen die signalen kunnen sturen met voldoende kracht om ze uit een IC-pakket en over een PCB te sturen. naar een andere chip.

2. Dan hebben we ontwerpers van digitale logica die weten hoe ze die transistors moeten samenvoegen in bibliotheken met honderden verschillende logische cellen. Logische poorten, flip-flops, muxes en adders, om er maar een paar te noemen. Allemaal in verschillende configuraties.

3. Vervolgens hebben we verschillende groepen ingenieurs die weten hoe ze die digitale (en soms analoge) blokken moeten samenvoegen om functionele blokken van een hoger niveau te vormen, zoals supersnelle transceivers, geheugencontrollers, branch voorspellers, ALUs, etc.

4. Dan hebben we CPU-ontwerpers om high-end CPU-ontwerpen te ontwerpen door die functionele eenheden samen te voegen tot een compleet systeem.

En daar stopt het niet. Op dit moment hebben we een werkende CPU die assembly-code uitvoert, maar dat is niet de taal waar de meeste programmeurs tegenwoordig naar schrijven.

5. We hebben misschien een C-compiler die compileert naar assembly code (waarschijnlijk via een tussenliggende representatie)
6. We zouden nog een abstractie bovenop C kunnen toevoegen om een objectgeoriënteerde taal te krijgen
7. We zouden zelfs een virtuele machine kunnen schrijven bovenop C of C ++ zodat we zaken als Java-bytecode kunnen interpreteren

En de abstractielagen kunnen van daaruit verder gaan. Het belangrijke punt hier is dat die abstractielagen worden gecombineerd om een CPU-gebaseerd systeem op te leveren dat enorm schaalbaar is en een kleine fractie kost van een aangepast siliciumontwerp.

ECHTER, het belangrijke punt dat hier moet worden gemaakt, is dat elke abstractie zelf ook een prijs met zich meebrengt. De transistorontwerper bouwt niet voor elke toepassing de perfecte transistor. Hij bouwt een redelijke bibliotheek, en daarom wordt soms een transistor gebruikt die iets meer stroom of een beetje meer silicium verbruikt dan echt nodig is voor de klus. En op dezelfde manier bouwen de logica-ontwerpers niet elke mogelijke logische cel. Ze kunnen een NAND-poort met 4 ingangen en een NAND-poort met 8 ingangen bouwen, maar wat gebeurt er als een andere ingenieur een NAND-poort met 6 ingangen nodig heeft? Hij gebruikt een NAND-poort met 8 ingangen en bindt 2 ongebruikte ingangen af, wat resulteert in verloren siliciumbronnen en verminderde stroom. En zo gaat het omhoog in de keten van abstracties. Elke laag geeft ons een manier om met de complexiteit om te gaan, maar brengt ons tegelijkertijd extra incrementele kosten in termen van silicium en stroom in rekening.

Vergelijk nu die abstracties met wat nodig is voor een FPGA. In wezen stoppen de FPGA-abstracties bij # 2 in de bovenstaande lijst. De FPGA stelt ontwikkelaars in staat om op de digitale logische laag te werken. Het is iets geavanceerder dan dat, omdat CPUs op deze laag hard gecodeerd zijn en FPGAs tijdens runtime moeten worden geconfigureerd (wat trouwens de reden is waarom CPUs doorgaans veel hogere frequenties gebruiken), maar de essentiële belangrijke waarheid is dat dat ver weinig abstracties voor FPGAs dan voor CPUs.

Dus, Waarom kan een FPGA sneller zijn dan een CPU? In wezen is het omdat de FPGA gebruikt veel minder abstracties dan een CPU, waardoor de ontwerper dichter bij het silicium werkt. Hij betaalt niet de kosten van alle vele abstractielagen die nodig zijn voor CPUs. Hij codeert op een lager niveau en moet harder werken om een bepaald stukje functionaliteit te bereiken, maar de beloning krijgt hij hogere prestaties.

Maar natuurlijk is er een keerzijde voor minder abstracties. Al die CPU-abstracties zijn er om een goede reden. Ze geven ons een veel eenvoudiger coderingsparadigma, wat betekent dat meer mensen zich gemakkelijk voor hen kunnen ontwikkelen. Dat betekent op zijn beurt dat er veel meer CPU-ontwerpen bestaan en dus hebben we enorme voordelen op het gebied van prijs / schaal / time-to-market van CPUs.

Dus daar heb je het. FPGAs hebben minder abstracties en kunnen daarom sneller en energiezuiniger zijn, maar moeilijk te programmeren. CPUs hebben veel abstracties om ze gemakkelijk te ontwikkelen, schaalbaar en goedkoop te maken. Maar ze geven snelheid en kracht in de handel op voor die voordelen.

Reacties

• Ook FPGA ‘ s zijn ontworpen met behulp van eenvoudige herhalende blokken die eenvoudige logische taken moeten uitvoeren. Ze zijn op maat gemaakt voor bepaalde soorten taken.CPU ‘ s, OTOH, hebben veel complexe functionele onderdelen die allemaal verschillende dingen doen. Je zou kunnen denken dat een CPU een groep van veel verschillende FPGA-achtige apparaten is (het is tenslotte ‘ gewoon silicium, elektronica en wiskunde). Dus het ‘ gaat gewoon niet over abstracties, het ‘ gaat over complexiteit. CPU ‘ s zijn complexe apparaten die bestaan uit veel verschillende soorten elektrische apparaten, terwijl een FPGA uit een paar bestaat. Een CPU is een jachtgeweer terwijl een FPGA een geweer is.

Terwijl de andere antwoorden allemaal correct zijn , geen van hen gaat nog in op het bitcoin mining-voorbeeld uit uw vraag, wat inderdaad een behoorlijk voorbeeld is. Bitcoin-mining omvat het herhaaldelijk berekenen van een cryptografische hash-functie, SHA-256 van het resultaat van een andere SHA-256-berekening, van gegevens waarbij slechts één 32-bits geheel getal verandert, totdat de resulterende hash bepaalde eigenschappen heeft. Elke SHA-256 bestaat uit 64 herhalingen van hetzelfde algoritme met 32-bit toevoegingen, bitshifts en wat meer bit-mangling-bewerkingen.

Als je deze lus programmeert op een 32-bit (of meer) CPU , zult u merken dat de instructieset zeer geschikt is voor de taak — SHA-256 is ontworpen om efficiënt te werken op CPUs. Toch gebruik je misschien maar 2% van het siliciumgebied van een moderne CPU, met gebiedsintensieve functionaliteit zoals caching, vermenigvuldiging, deling, drijvende-kommabewerking, vertakking en brach-voorspelling, enz., Ofwel helemaal niet gebruikt of niet in staat zorgen voor een aanzienlijke prestatieverbetering voor deze specifieke taak.

In configureerbare hardware zoals een FPGA, implementeert u gewoon die 2%, en optimaliseert u verder door alles over code-uitvoering te vergeten, in plaats van poorten te ontwerpen om elk van deze direct te berekenen die vaak herhaalde subfuncties. Pijplijn zodanig dat elk van hen een resultaat doorgeeft aan de volgende klokcyclus, en 128 keer herhaald (en met een speciale extra logica waarbij elke SHA-256 begint en eindigt), krijg je uiteindelijk een resultaat elke klokcyclus (voor misschien 100 miljoen hashes per seconde op een FPGA die wordt geadverteerd om 300 MHz te ondersteunen op eenvoudiger logica dan deze) terwijl je op een moderne CPU één resultaat zou kunnen verwachten om de paar duizend klokcycli per kern, zeg 10 miljoen hashes per seconde ond op een multi-core multi-GHz CPU.

Als dit specifieke voorbeeld interessant voor je is, wil je misschien eens kijken naar mijn gerelateerde antwoord over de internals van ASIC-mijnwerkers op bitcoin.stackexchange, aangezien veel FPGA-mijnwerkers op dezelfde manier werken met configureerbare in plaats van op maat gemaakte hardware. Ter wille van de volledigheid: er zijn andere mogelijkheden, zoals het beperken of vermijden van de pipelining die ik beschreef ten gunste van een meer triviale parallellisatie door meerdere onafhankelijke SHA-256 hashers te gebruiken. , dat zelfs betere prestaties kan geven, hoewel het minder efficiënt zou zijn in termen van poorttelling en routing overhead als je perfecte vrijheid had bij het ontwerpen van de hele chip, niet alleen de configuratie van een FPGA.

Opmerkingen

• Dat ‘ is een heel goed punt over het gebruik van silicium.
• Maar misschien (onbedoeld!) misleidend, gezien het feit dat een FPGA bestaat uit enigszins complexe cellen met veel fysieke poorten, waarvan een typische toepassing weer slechts een fractie gebruikt, waardoor hun fabrikanten gelijkwaardige poorttellingen kunnen adverteren in een poging u te vertellen hoeveel dat allemaal waard zou kunnen zijn in een ” typisch ” applicatie …

De bovenstaande antwoorden, hoewel correct, missen het punt over waarom FPGAs (en aangepaste ASICs) vooral goed zijn voor bitcoin-berekeningen.

Het echte voordeel is dat een groot deel van de SHA-256-berekeningen logische bewerkingen zijn (bijvoorbeeld bitverschuivingen) die kunnen worden gedaan in bedrading. Als ze op deze manier worden gedaan, hebben ze 0 klokcycli nodig.

Een ander belangrijk voordeel is dat FPGAs veel energiezuiniger zijn (dwz MIPS per Watt) dan CPUs, dus de hoeveelheid energie die nodig is voor de berekeningen is veel minder. Dit is belangrijk omdat de kosten van het minen van een bitcoin afhangen van hoeveel elektriciteit je gebruikt om het te maken.

ASIC-chips zijn energiezuiniger dan FPGAs, dus ze kunnen dezelfde code veel goedkoper uitvoeren. Je kunt ook meer executie-eenheden aan boord proppen om ze sneller te maken. Het nadeel is dat de kosten voor het maken van een aangepaste ASIC erg hoog zijn, dus je zou nogal wat chips moeten verkopen om de productiekosten te dekken.

GPUs worden ook gebruikt voor het maken van bitcoins, maar omdat ze dat zijn Ze zijn veel minder energiezuinig en verliezen terrein aan FPGAs en aangepaste ASICs.

Reacties

• Als je kijkt naar het Monero-hash-algoritme oftewel cryptonight, zul je zien dat een FPGA-implementatie bijna onmogelijk is vanwege het grote aantal geheugen moest willekeurig worden benaderd (2 MB). Een CPU heeft in dit geval het voordeel.
• @ lucas92 kun je geen RAM in FPGA integreren om de benodigde hoeveelheid geheugen te accommoderen?
• Je hebt waarschijnlijk ‘ t hebben er genoeg logische elementen in de FPGA voor.