Skrivet av Petterk:
Det är 8 st heltalspipelines i dessa processorer med eget L1d, dvs den klassiska definitionen på kärnor. Frontend/dekoder är dock väldigt smal så det är inte som att det är massor mer arbete att göra för det. Bara på avkodningssteget lär du förlora 30%. FP-pipeline beter sig dessutom olika.
Tänk på att många andra arkitekturer inte har denna bild av en (separat) hel front-end/avkodare per kärna för den delen. De har däremot ofta SMT som inte finns här. Eftersom x86-avkodningen tar upp så lite plats idag (jämfört med heltals och flyttalsdelarna, cache osv, och för den delen idag gpu) så är det inte bästa sättet att begränsa sig däremot. En hel x86-kärna är inte många mm² när man räknar bort cache. Det är inga problem att ha x86 quadcore på Jaguar eller kommande Silvermont med kompletta och egna front-ends med separat decoder per kärna. Att bygga en processor med behov av massor cache kommer däremot vara ganska kämpigt utanför servermarknaden. Dessutom vill man gärna att desktop och notebook-processorerna ska vara starkare per tråd än Kabini/Jaguar I just AMDs fall har de lyckats göra en arkitektur som dessutom skalar relativt dåligt i multi-threading/SMP. Då ger det inget att bara sälja fler kärnor. 50-60% mer prestanda per tråd och bättre skalning behöver de ha ganska snart för att kunna ta sig förbi där Nehalem var 2008-09. FM2/FM2+ är dessutom bara 4-kärnor än så länge.
Dold text
För många serverlaster är SMT ett väldigt effektivt sätt att öka totala mängden utfört arbete med väldigt liten extra insats i form av transistorer, man kan få väldigt hög effektivitet av HT t.ex. och i dessa laster skulle man mycket väl kunna dra nytta av mer än de två trådar per CPU-kärna som Intel har. IBM POWER har idag 4 trådar per kärna, Oracle SPARC har 8 trådar per kärna och även Intels Xeon Phi har 4 trådar per kärna.
Att trådar delar på ALU-enheter är helt enkelt inte flaskhalsen här då trådarna utför väldigt mycket I/O och instruktionsströmmen då kommer innehålla många läsningar/skrivningar mot minnesmappade I/O-register där en "mov" instruktion mycket väl kan ta x10-x100 gånger längre tid en en "mov" mellan CPU-register.
Desktop applikationer tenderar har långt mycket mindre andel I/O och även långt mycket mindre "working-set" än server applikationer så långt mer än 90% av alla minnesaccesser är cache-hit på desktop. Flaskhalsen tenderar därför att bli front-end (avkodning) eller back-end (ALU-enheter) lite beroende på vad man gör. Att då har flera CPU-trådar per CPU-kärna ger väldigt lite effekt och på desktop laster skulle en Intel laptop CPU i många fall vara snabbare än en Oracle SPARC CPU från en $50.000 server då det skulle få nära nog noll effekt av sin brutala bandbredd mot RAM och 8 CPU-trådar per kärna.
Det man kan klaga på vad det gäller AMDs design för Bulldozer/Piledriver är att man lyckats skapa något som inte är bra på vare sig desktop eller servers...
Det är en dålig desktop CPU då man har relativt dålig enkeltråd-prestanda, något som man försöker kompensera genom att ha fler CPU-kärnor. Problemet med detta är minst tre, dels så får en sådan lösning sämre latens då latens minskar linjärt med ökande enkeltrådprestanda, dels så kan väldigt få desktop applikationer använda speciellt många CPU-kärnor, dels så är summan av vad en båda modulerna kan prestera inte högre än vad Intel får ut med en CPU-kärna och två HT...
Det är dåligt på servers då man har får overkill av ALU-enheter per CPU-tråd då flaskhalsen inte är ALU utan flaskhalsen är i stället att vissa "mov" instruktioner tar väldigt lång tid och det är långt mer effektivt att köra flera CPU-trådar per CPU-kärna då det tar väldigt få transistorer jämfört med att replikera alla ALU-enheter för heltal.
Sist och definitivt inte minst är det ju något som är fundamentalt fel med hur man byggt upp Bulldozer/Piledriver kärnorna. I diskussionen om Jaguar-artikeln här på SweC så beräknades IPC per CPU-tråd både på Piledriver och Jaguar, det visar sig att Jaguar har högre IPC än Piledriver!! Med tanke på att Piledriver kan avkoda upp till 4 x86 instruktioner per CPU-cykel och köra upp till 4 interna instruktioner per cykel och CPU "kärna" (pipelinen klarar av påbörja 2 ALU och 2 minnesoperationer per cykel) jämfört med Jaguar-kärna som kan avkoda upp till 2 x86 instruktioner per CPU-cykel, påbörja upp till 2 x86 instruktioner per cykel (dessa kan vara ALU och/eller minnesoperationer) så får man en uppfattning om just hur usel designen i Bulldozer/Piledriver är.
Nu skalar inte prestanda alls linjär med ökande antal ALU-enheter och med ökad bredd på front-end, men Intels SNB/IVB CPUer kan avkoda 4 (5 i vissa lägen) x86-instruktioner och kan utföra 3 ALU + 3 minnesoperationer (2 läsningar + 1 skrivning) (HSW kan utföra 4 ALU + 4 minnesoperationer (2 läsning + 2 skrivning)) och de har nästan dubbla IPC mot AMD, så även den "smala" back-end som Piledriver har borde presterar betydligt bättre än Jaguar på pappret.
Det kanske vore bättre för AMD att skapa en Jaguar-variant med större CPU-cache och designad för att köras >3GHz, det lär ju dra mindre ström än Piledriver. För desktop skulle man kunna sikta på maximal frekvens med 4 kärnor och på servers skulle man kunna sikta på lägre frekvens och 8-16 CPU-kärnor per chip med SMT (minst 2 trådar per kärna).