Apples utvecklardator för ARM bräcker Intel i flertrådade tester

Permalänk
Medlem
Skrivet av Yoshman:

Det är inte "med flit", det handlar om en CPU som har en måleffekt på ~9 W. Vad videon väldigt mycket visar är att Apple faktiskt vet vad de håller på med, dator har ju en kylning anpassad till den CPU man faktiskt valde att stoppa i.

Är väl i så fall på high-end MBP man haft lite undermålig kylning, vilket inte är helt förvånande när man stoppar i 45 W TDP CPUer. Man kan ju kolla på hur PC-bärbara som typiskt utrustas med dessa CPUer ser ut, de kan knappt kallas "bärbara", mer "flyttbara".

Ja håller med att de vet vad de gör.

Mmm, så mycket värme i en bärbar är inte det enklaste att hantera. Släpbara passar också in på dem

Permalänk
Medlem
Skrivet av Yoshman:

Det är en viss sanning med modifikation att Skylake, Sunny Cove, Zen och Zen 2 alla är 4 breda. Det är maximal kapacitet när de avkodar x86 instruktioner. Men alla dessa har en "L0$" (mikro-op cache) som innehåller redan avkodade x86 instruktioner, så de innehåller "interna" instruktioner.

För alla dessa är kapaciteten högre för dessa interna instruktioner, de kan alla "retire" (färdigställa) upp till 8 st interna instruktioner per cykel när SMT används.

Skylake har väldigt svårt att gå över 4 instruktioner per cykel även om man kör från uop-cachen. Max bandbred i reorder-steget är 4 instruktioner per cykel. Det går att gå runt det genom att man utnyttjar micro-op fusion, men det är bara vissa par av instruktioner som kan svetsas ihop. Om din ström innehåller två par som kan svetsas, så får du ut 6 i det steget (=vad uop-cachen kan leverera), men det kommer aldrig att hända under en längre period i praktiken.

Zen behöver jag också läsa på, om jag nu skall bygga en sådan burk.

Citat:

Sunny Cove har dessa primära förändringar från Skylake

  • väsentligt mycket större "out-of-order" fönster, ~60 % större

  • kan hålla ordning på långt fler minnsoperationer, ~80 % fler "loads" och ~30 % fler "stores"

  • kan utföra dubbelt så många minnesoperationer som tidigare (dubbelt så många pipelines för load/store)

  • hade fel om Sunny Cove, den är faktiskt 5-wide så det är ett snäpp upp från de övriga!

  • mikro-op cache (L0$) är 50 % större

  • L1D$ är 50 % större

  • L2$ är 100 % större

  • AVX-512 stöd (påverkar primärt applikationer som använder matriser, som maskininlärning, Matlab, etc)

Det som är nedslående är hur lite effekt allt ovan gett, Sunny Cove har ~20 % högre IPC jämfört med Skylake (så den utför mindre per cykel jämfört med t.ex. Cortex A77 som består av långt färre antal transistorer).

Sunny Cove har också 1 cykel längre latency till L1D, från 4 till 5, vilket kostar en del (Apple har 3, som jämförelse).

Sunny Cove är intressant. Den går verkligen mycket bredare, och lösningen på reorder-problemet är att splittra upp till 4 köer (reservation stations), när de hållit fast vid en enda i alla år när designen blivit bredare. Blir det förresten inte 6 instruktioner i bredd om man går från uop-cachen? Ser inget annat som håller tillbaka den på 5 förutom avkodningen.

Permalänk
Inaktiv
Skrivet av Kilroy:

<klipp>
Hur skulle det gå att kombinera ARM och X86 kärnor på samma processor?

Det känns som att vi behöver komma ifrån att vara låsta till gamla arkitekturer.

No shit, Sherlock! Intel och AMD lever ju på att ha monopol på x86. Du kan betrakta dom som fångvaktare. Varför skulle dom kombinera x86 och ARM på ett chip för att underlätta en övergång till ARM? Det skulle ju bara öppna en dörr så fångarna kan fly. Dom kommer att akta sig noga för det även om det säkert skulle gå rent tekniskt.

Finns många vägar framöver när nu Apple visar vägen för gammal-PC. En variant är att Microsoft köper Intel, eller CPU-delen av Intel, för att sedan bygga vad dom vill. Fast enklare är nog att göra övergången ungefär som Apple gör med dubbla binärer och någon form av emulering. Eller så gör man helt enkelt ingenting. Så dåliga är trots allt inte Intel-propparna, även om dom nu börjar framstå som slöa.

Permalänk
Skrivet av Kilroy:

Hur skulle det gå att kombinera ARM och X86 kärnor på samma processor?

Jag känner till en maskin som gjort något likande: https://en.wikipedia.org/wiki/Commodore_128
Det korta svaret: Det blir dyrt, ineffektivt, kommer döda batteritiden på allt bärbart, och alldeles för få kommer att använda sig av möjligheterna det ger.

Apple har till skillnad från Microsoft bra pli på sina utvecklare och en historia av "kill your darlings (after giving suitable notice)". Övergången till Apple-kisel kommer att gå enkelt för den absoluta majoriteten program folk kör på sina Macar, och kan potentiellt ha som bieffekt att Windows på Arm får större spridning när det börjar dyka upp prestandamaskiner på den plattformen. Mängder av programvara med öppen källkod kompileras redan nu för Arminstruktioner, och Apple har enligt egen utsago till och med eget folk inblandat i att få några av de mest kända biblioteken och produkterna att bygga rent på deras nya plattform.

De som kommer att drabbas är de som är beroende av att köra den minoritet x86-64-programvara som inte längre underhålls på macOS - kom ihåg att allt som hade kvar 32-bitsbibliotek dog redan förra året - och de som inte klarar sig utan att köra virtuella x86-maskiner lokalt på sin dator. Även det sistnämnda kommer troligen vara en försvinnande liten andel av användarna med tanke på att Arm-baserade Linuxdistributioner kan virtualiseras finfint och mjukvarustödet för dessa bara blir större och större.

Permalänk
Medlem
Skrivet av Det Otroliga Åbäket:

Det korta svaret: Det blir dyrt, ineffektivt, kommer döda batteritiden på allt bärbart,

Nja, riktigt så illa behöver det ju verkligen inte vara.
Att i en övergångsperiod köra saker som inte moderniserats än på native x86 kärnor medans systemet och

Skrivet av Det Otroliga Åbäket:

och alldeles för få kommer att använda sig av möjligheterna det ger.

Poängen med det är ju att göra övergången ifrån x86 till ARM osynlig för gemene man.
Att en inte förlorar prestanda i program och spel som kör x86 kod då ingen emulering behövs men att allting nytt skrivs direkt för en modernare arkitektur.
Det gör övergången osynlig för gemene man och gör det så mycket enklare för utvecklare att fokusera på att bara skriva mot och kompilera för det moderna. Men samtidigt veta att det finns bakåtkompatibilitet.

Men vi får väl se hur bra Apples emulering är i verkligheten, den kanske är bra nog.

Skrivet av anon214822:

Varför skulle dom kombinera x86 och ARM på ett chip för att underlätta en övergång till ARM?

För att dom ska kunna ha en framtid. Jag ser ingen möjlighet för x86 att överleva så länge till, Intel levde på sitt produktionstekniska övertag men det är i princip borta nu.

x86 har fortfarande övertaget att det inte finns en marknad för högpresterande ARM men iom Apples omställning så kommer det övertaget antagligen tunnas ut allt mer.

Att haka på tåget nu och fokusera på att göra ett världsledande ARM-chip med all den kunskap som finns.
Men det kanske är svårt att ställa om och det tekniska kunnandet som finns inte kan översättas till en helt annan typ av arkitektur så det blir svårt att konkurrera.

Men någon omställning behövs, det är ju helt uppenbart. Det behöver ju inte ens vara ARM, det kan vara något annat också och det känns som ett någon behöver ta tag i det snart.
Sätt igång och planera nu, t.ex. i kombination med kommande genertioners spelkonsoler så en kan få spel skrivna för det också.

Jag blir bara så trött på att sån här typ av företagsekonomiska anledningar håller utvecklingen tillbaka!

Skrivet av anon214822:

Finns många vägar framöver när nu Apple visar vägen för gammal-PC. En variant är att Microsoft köper Intel, eller CPU-delen av Intel, för att sedan bygga vad dom vill. Fast enklare är nog att göra övergången ungefär som Apple gör med dubbla binärer och någon form av emulering. Eller så gör man helt enkelt ingenting. Så dåliga är trots allt inte Intel-propparna, även om dom nu börjar framstå som slöa.

Intel-propparna är ju fortfarande det snabbaste du kan köpa, men prestanda per watt börjar se smått patetiskt ut och det här är bara början.

Jag har inte följt hårdvarubranschen så mycket de senaste 10-15 åren som jag gjorde tidigare och den känns verkligen stagnerad.
Jag har ganska starka aversioner mot Apple och deras affärsmetoder och strategier men jag hoppas verkligen att dom med detta tvingar andra att förnya sig och tänka nytt.

Permalänk
Medlem
Skrivet av Kilroy:

Nja, riktigt så illa behöver det ju verkligen inte vara.
Att i en övergångsperiod köra saker som inte moderniserats än på native x86 kärnor medans systemet och

Poängen med det är ju att göra övergången ifrån x86 till ARM osynlig för gemene man.
Att en inte förlorar prestanda i program och spel som kör x86 kod då ingen emulering behövs men att allting nytt skrivs direkt för en modernare arkitektur.
Det gör övergången osynlig för gemene man och gör det så mycket enklare för utvecklare att fokusera på att bara skriva mot och kompilera för det moderna. Men samtidigt veta att det finns bakåtkompatibilitet.

Det är det här tänket som sitter som ett par betongdojjor på IT-branschen. För de lata kommer att tänka "skönt jag behöver inte göra något, det finns bakåtkompabilitet".

Att inte våga släppa det gamla och ta ett nytt steg... Är man beroende av något gammalt mög (mjukvara där utvecklaren inte orkar kompilera om på ny plattform) kan man faktiskt behålla sin 5.25" diskettstation, 1x cdrom-spelare, ms dos 6.22, win 3.11, serieportar, parallellportar o.s.v. på sin gamla utrustning...

Permalänk
Medlem
Skrivet av Det Otroliga Åbäket:

Jag känner till en maskin som gjort något likande: https://en.wikipedia.org/wiki/Commodore_128
Det korta svaret: Det blir dyrt, ineffektivt, kommer döda batteritiden på allt bärbart, och alldeles för få kommer att använda sig av möjligheterna det ger.

128:an var ett specialfall, dyr och krånglig och jävla under att skiten kunde produceras i någotsånär volymer, och det gick ju inget vidare för CP/M, men förutsättningarna är helt andra idag. Tror det blir rätt överkomplicerat med "dubbel hårdvara" kontra den nivå av virtualisering och emulering som går att få idag. Det går nog att bygga ARM/ARM64 från Visual Studio oavsett....

Vore väldigt trevligt att kunna lägga vantarna på ett ARM dev kit.

Permalänk
Skrivet av Kilroy:

Nja, riktigt så illa behöver det ju verkligen inte vara.
Att i en övergångsperiod köra saker som inte moderniserats än på native x86 kärnor medans systemet och

Poängen med det är ju att göra övergången ifrån x86 till ARM osynlig för gemene man.
Att en inte förlorar prestanda i program och spel som kör x86 kod då ingen emulering behövs men att allting nytt skrivs direkt för en modernare arkitektur.

Som jag försökte skriva i mitt förra inlägg kommer övergången till Arm vara osynlig för gemene man på Mac-plattformen. Alla native Apple-program kommer redan vara portade, MS Office och Adobes Creative Suite kommer vara portade, och vid slutet av tvåårsperioden kommer allt som ska kunna fortsätta säljas på App Store vara portat. Bara program som inte underhållits enligt rekommendationerna på flera år kommer vid det laget inte funka.

Det som per definition händer när man tillåter en existerande arkitektur och en ny arkitektur att samexistera är att alldeles för många tar chansen att inte göra något. Jämför Apple och Microsoft, där Apple fattar beslut som tvingar produkter att hålla sig moderna eller dö (och på regelbunden bas gör ett litet subset av sina användare arga på det viset), medan Microsoft försöker skapa bakåtkompatibilitet till nära nog vilket pris som helst vilket å ena sidan ger ofantliga fördelar vad gäller hur länge mjukvara kan leva, men å andra sidan tvingar oss leva med konsekvenserna av dåliga designbeslut bokstavligen i decennier.

Vad Apple har gjort är att i åratal gradvis förbereda användarbasen för det här skiftet genom att pensionera gamla bibliotek, sluta supportera <64-bitsplattformar, skriva ett "bra nog" översättningslager för x86-64-kod, och nu rycker de plåstret under den relativt korta tiden ~2 år. Tänk vad skönt om ISP:er runt om på jorden gjort något liknande med IPv6 någon gång runt 2012-2014 när alla gängse operativsystem hade stöd för den "nya" standarden...

Permalänk
Datavetare
Skrivet av mpat:

Skylake har väldigt svårt att gå över 4 instruktioner per cykel även om man kör från uop-cachen. Max bandbred i reorder-steget är 4 instruktioner per cykel. Det går att gå runt det genom att man utnyttjar micro-op fusion, men det är bara vissa par av instruktioner som kan svetsas ihop. Om din ström innehåller två par som kan svetsas, så får du ut 6 i det steget (=vad uop-cachen kan leverera), men det kommer aldrig att hända under en längre period i praktiken.

Zen behöver jag också läsa på, om jag nu skall bygga en sådan burk.

Sunny Cove har också 1 cykel längre latency till L1D, från 4 till 5, vilket kostar en del (Apple har 3, som jämförelse).

Sunny Cove är intressant. Den går verkligen mycket bredare, och lösningen på reorder-problemet är att splittra upp till 4 köer (reservation stations), när de hållit fast vid en enda i alla år när designen blivit bredare. Blir det förresten inte 6 instruktioner i bredd om man går från uop-cachen? Ser inget annat som håller tillbaka den på 5 förutom avkodningen.

Skylake, Sunny Cove och Zen 2 har alla en maximal kapacitet på 6 μops från "front-end" till "back-end" (>4 μops händer bara vid träff i μop-$, Skylake/Coves kan få 5 μops i specifika fall) samt maximal kapacitet på att färdigställa 8 μops ut ur "back-end". De lär alla ha extremt svårt att i praktiken nå mer än 4 μops i genomsnitt då de alla tre har 4 st ALU. Det är självklart möjligt att skapa "rätt" mix för att nå 6 μops, men det lär knappast hända i praktiken.

Sunny Cove har precis som Skylake en central schemaläggare, men i praktiken är portarna uppdelad i 3 separata klasser: ALU/Branch (4 st), AGU (3 st för Skylake och 4 st för Willow Cove) samt "store data" (1 st för Skylake och 2 st för Willow Cove). Zen 2 lägger heltals-ALU/Branch över 4 st portar (med distribuerad schemaläggare) och flyttals-ALU över 4 st portar (med central schemaläggare).

Här kan man nog också se att det måste finnas en fundamental skillnad mellan x86 och ARM64. Redan Cortex A77 har totalt 6 st ALU/Branch portar för heltalsberäkningar medan Apples A12/A13 har hela 8 heltals-ALU/Branch portar! Det är nog en vink kring att det är helt enkelt poänglöst att göra heltalsdelen speciellt mycket bredare i x86, det kommer nog inte göra någon skillnad medan det ser ut att skala i alla fall till den bredd A12/A13 kör med för ARM64.

Också intressant att Apple A11 och Cortex A77 ändå klarar sig så pass väl i flyttal mot Zen 2 och Skylake/Sunny Cove givet att ARM:arna bara har två pipeline för flyttal medan Zen 2 har fyra. Också intressant värt att notera att Sunny Cove faktiskt ofta har lite större IPC övertag mot Skylake i flyttal, det trots att man inte breddat den del och man har "bara" 2/3 flyttalspipelines (3 för SIMD, men bara 2 för skalära flyttal).

Apple A12/A13 har klart högre IPC även för flyttal jämfört med x86 med sina 3 flyttalspipelines. Får se hur Cortex X1 kommer tugga flyttal då den har 4 st flyttal/NEON-pipelines! Har ändå lite svårare att riktigt se varför ARM64 skulle ha några stora fördelar över x86 i flyttal, än mindre hur NEON skulle kunna vara så mycket bättre jämfört med SSE/AVX... För heltalskod råder nog inga tvivel om att ARM64 är långt bättre, kanske är något jag helt missar kring flyttal och SIMD.

I.o.f.s. ger AVX-512 klart bättre prestanda än NEON i de områden AVX-512 passar riktigt väl, så fel att ge ARM fördel här om man inte tittar på "SVE" som varken Apple eller Cortex A implementerar än. (SVE=Scalable Vector Extensions).

Permalänk
Medlem

Skummade precis Agner Fog’s optimeringsmanual för första gången på ett tag, letade efter Ice Lake. Den var inte med, men Zen var det. Han tycker att man bör klara 4 instruktioner/6 uop också för kod som inte får plats i uop-cachen. Nu är ju uops inte identiska mellan AMD och Intel, men lite intressant ändå.

Permalänk
Medlem

[i]

Skrivet av Yoshman:

Apple A12/A13 har klart högre IPC även för flyttal jämfört med x86 med sina 3 flyttalspipelines. Får se hur Cortex X1 kommer tugga flyttal då den har 4 st flyttal/NEON-pipelines! Har ändå lite svårare att riktigt se varför ARM64 skulle ha några stora fördelar över x86 i flyttal, än mindre hur NEON skulle kunna vara så mycket bättre jämfört med SSE/AVX... För heltalskod råder nog inga tvivel om att ARM64 är långt bättre, kanske är något jag helt missar kring flyttal och SIMD.

I.o.f.s. ger AVX-512 klart bättre prestanda än NEON i de områden AVX-512 passar riktigt väl, så fel att ge ARM fördel här om man inte tittar på "SVE" som varken Apple eller Cortex A implementerar än. (SVE=Scalable Vector Extensions).

SVE är trevligt, men dess main claim to fame, att den tillåter hårdvaruvektorlängder från 128 till 2048 bitar är kanske inte så tillämpbart för Apple. Noterbart är att Fujitsus A64FX superdator har en vektorlängd på 512 bitar. Mer är absolut inte generellt bättre vad gäller vektorlängd, ens för den klassen av datorer.
För en bra artikel med måttligt omfång angående vektorlängd, inkluderande cache effekter, längdspecifik vs. agnostisk kod osv och till och med en liten jämförelse med NEON prestandamässigt (ingen reell skillnad) rekommenderar jag varmt en liten femsidig artikel av Angela Pohl et. al.

Nu är iofs SVE trevligt, och jag hoppas att Apple så småningom byter till den vektorlösningen av rent estetiska skäl, men med tanke på att Apple implementerar inte bara egna co-processorer, utan också lägger till egna instruktioner (AMX) till AArch64, så vete fasen hur stor den praktiska nyttan skulle vara.

Permalänk
Datavetare
Skrivet av mpat:

Skummade precis Agner Fog’s optimeringsmanual för första gången på ett tag, letade efter Ice Lake. Den var inte med, men Zen var det. Han tycker att man bör klara 4 instruktioner/6 uop också för kod som inte får plats i uop-cachen. Nu är ju uops inte identiska mellan AMD och Intel, men lite intressant ändå.

Satt och lekte lite med mikro-benchmarks i morse. Det är helt klart möjligt att nå >4 instruktioner per cykel i tighta loopar på Zen 2, men det fungerar bara i extremt specifika fall ("tricket" är att blanda minnesoperationer, heltal och flyttal då Zen 2 har totalt 3+4+4=11 exekvering-portar att jobba med).

Enligt Agner är det inte omöjligt att även Skylake kan peak:a på >4, närmaste jag kom här var uppmätt IPC 4,0.

"However, the throughput of the whole design rarely exceeds four instructions per clock."

Att det finns en begränsning på 4 "renames" per cykel är i sig ingen barriär för >4 μps, det finns absolut hopp samt x86 kan även göra jämförelser direkt mellan minne och konstanter. Angner nämner också att han inte alls ser detta som en flaskhals

"Register renaming is controlled by the reorder buffer and the scheduler. Register allocation and renaming has not been observed to be a bottleneck."

För Skylake fungerar inte Zen 2 tricket då ALU för flyttal och heltal delar exekvering-portar, möjligen kan man få till det med större andel minnesoperationer (som måste ge 100 % L1D$ hit for att ens teoretisk nå dessa IPCer) då det finns totalt 4 portar för minnesoperationer (mot 3 i Zen 2 och 6 i Sunny Cove).

Fast ens fyra instruktioner per cykel är extremt akademiskt på båda dessa CPUer. Kör man något som är stort nog att börja trilla ur CPU-cache är det svårt att ens nå IPC på 1,0. I "normala" program som har väldigt god cache-hit rate (d.v.s. de flesta desktop-applikationer) ligger dessa CPUer på IPC mellan 1,0 och 2,5 utan SMT och ~20-30 % högre med SMT (då lägre IPC per tråd men refererar till IPC per fysisk kärna).

Att Apple, och nu också ARM med Cortex A77 och senare, kan utför så pass mycket mer per cykel måste bero mycket på ISA. Men Agner Fog pekar på andra begränsningar för x86, som inte gäller för ARM

"A memory write may not be able to execute before a preceding write, but the write buffers can hold a number of pending writes, typically four or more."

x86 specifikationen tillåter inte read/read, read/write eller write/write reorder (verkar nog vettig när man spikade detta, men det var när ens två CPU-kärnor var exotiskt...). ARM garanterar enbart en specifik ordning efter explicit synkronisering (vilket är precis hur man definierat det hela i C, C++, Java, m.fl.).

"A memory read can execute before or simultaneously with another preceding read on most processors"

Det är bara delvis sant på x86. I praktiken fungerar high-end x86 så, men de måste ha extra house-keeping då specifikationen kräver att read/read sker i den ordning det specificerades i programmet. Så detta är spekulation på x86 och kommer ibland behöva köras om, det är inte fallet på ARM (så enklare att köra väldigt många samtidiga läsningar).

Måste vara dessa begränsningar i x86 som rejält börjar visa sig som IPC-ankare. Har väldigt svårt att se varför AMD/Intel annars skulle rent slumpmässiga hamna på så väldigt snarlik IPC med på vissa sätt rätt olika design.

Skrivet av EntropyQ3:

[i]SVE är trevligt, men dess main claim to fame, att den tillåter hårdvaruvektorlängder från 128 till 2048 bitar är kanske inte så tillämpbart för Apple. Noterbart är att Fujitsus A64FX superdator har en vektorlängd på 512 bitar. Mer är absolut inte generellt bättre vad gäller vektorlängd, ens för den klassen av datorer.
För en bra artikel med måttligt omfång angående vektorlängd, inkluderande cache effekter, längdspecifik vs. agnostisk kod osv och till och med en liten jämförelse med NEON prestandamässigt (ingen reell skillnad) rekommenderar jag varmt en liten femsidig artikel av Angela Pohl et. al.

Nu är iofs SVE trevligt, och jag hoppas att Apple så småningom byter till den vektorlösningen av rent estetiska skäl, men med tanke på att Apple implementerar inte bara egna co-processorer, utan också lägger till egna instruktioner (AMX) till AArch64, så vete fasen hur stor den praktiska nyttan skulle vara.

Var inte så att jag direkt önskar SVE stöd i de kretsar tänka för mobiler och desktop, precis som du ställer jag mig lite frågande till hur stort värdet är.

I "generell" kod undrar jag inte om 128-bitars SIMD ger bäst tradeoff mellan prestanda och effekt. AVX2/AVX-512 med >=256 bit bredd tenderar dra så pass mycket ström att frekvensen minskas, vilket då minskar prestanda för all skalär heltalskod som normalt är lejonparten i "generell" kod. Finns en del fördelar med AVX/AVX-512, dessa kan även utnyttjas i 128-bitars läge som då inte påverkar frekvensen!

Frågan är hur långt ARM-gänget kan någorlunda effektivt kan addera pipelines för NEON sett till effektivitet. Apples 3 pipelines över ARM Cortex 2 verkar ju ändå fungera, så blir intressant att se hur Cortex X1 presterar med sina 4 NEON pipelines.

Dokumentet du länkar pekar ju på att ökad vektorbredd ser rejäl dimishing returns redan vid 256-bitar i de tester man gjorde där. Tror mer på att köra saker som effektivt kan utnyttja sådan med GPGPU (typiskt långt högre bandbredd) eller specialkretsar som NPUer.

Finns ju ett mellanting mellan NEON/SSE/AVX där instruktionen dikterar bredden och SVE (och motsvarigheten för RISC-V) med variabel vektorbredd. Intels GPU kan variera effektiv registerbredd per instruktion, ändå används en och samma registerbank. Vi lär få se med Xe hur bra/dåligt detta är för grafik, men det verkar fungera väldigt bra för GPGPU (Intels GPUer har väldigt bra prestanda ställd mot teoretisk kapacitet i GPGPU).