AMD Trinity Review (A10-4600M): A New Hope

Introduktion och Piledriver-översikt

Brazos och Llano var båda oerhört framgångsrika delar för AMD. Företaget sålde ton trots att det inte levererade ledande x86-prestanda. Framgången för dessa två APU:er gav AMD mycket internt förtroende för att det var möjligt att bygga något som inte prioriterade x86-prestanda utan snarare levererade en bra balans mellan CPU- och GPU-prestanda.

AMD:s engagemang för världen var att vi skulle se årliga uppdateringar av alla dess produktlinjer. Llano debuterade i juni förra året, och idag ger AMD oss sin efterträdare: Trinity.

På en hög nivå kombinerar Trinity 2-4 Piledriver x86-kärnor (1-2 Piledriver-moduler) med upp till 384 VLIW4 Northern Islands generation Radeon-kärnor på en enda 32nm SOI-matris. Resultatet är ett 1.303B transistorchip (upp från 1.178B i Llano) som mäter 246mm^2 (jämfört med 228mm^2 i Llano).

Utan en förändring i tillverkningsprocessen står AMD inför det tuffa jobbet att öka prestanda utan att ballongforma storleken. Formstorleken har bara ökat med cirka 7 %, men både CPU- och GPU-prestanda ser tvåsiffriga ökningar jämfört med Llano. Strömförbrukningen är också förbättrad jämfört med Llano, vilket gör Trinity till en vinst över hela linjen för AMD jämfört med föregångaren. Om du gillade Llano kommer du att älska Trinity.

Problemet är vad som händer när du kliver utanför AMD:s värld. Llano hade svårt att konkurrera med Sandy Bridge utanför GPU-arbetsbelastningar. AMD:s förhoppning med Trinity är att dess hårdvaruförbättringar i kombination med mer tillgänglig OpenCL accelererad mjukvara kommer att förbättra dess ställning jämfört med Ivy Bridge.

Piledriver: Bulldozer Tuned

Medan Llano innehöll så många som fyra 32nm x86 Stars-kärnor, har Trinity upp till två Piledriver-moduler. Med tanke på det inte så fantastiska mottagandet av Bulldozer i slutet av förra året var vi oroliga för hur ett Bulldozer-derivat skulle hamna i Trinity. Jag är glad att kunna säga att Piledriver är ett steg framåt från CPU-kärnorna som används i Llano, till stor del tack vare ett gäng saneringsarbete från Bulldozer-grunden.

Piledriver fortsätter där Bulldozer slutade. Dess grundläggande arkitektur förblir helt oförändrad, men snarare förbättrad på alla områden. Piledriver är i hög grad ett andra pass på Bulldozer-arkitekturen, städar allt, drar nytta av lågt hängande frukt och förbättrar krafteffektiviteten avsevärt. Om du hoppades på en arkitektonisk återställning med Piledriver, kommer du att bli besviken. AMD är engagerad i Bulldozer och det är ganska uppenbart om du tittar på Piledrivers blockdiagram på hög nivå:

Varje Piledriver-modul är samma 2+1 INT/FP-kombination som vi såg i Bulldozer. Du får två heltalskärnor, var och en med sina egna schemaläggare, L1-datacacher och exekveringsenheter. Mellan de två finns en delad flyttalskärna som kan hantera instruktioner från en av två trådar åt gången. Den enda FP-kärnan delar datacachen för de dubbla heltalskärnorna.

Varje modul framstår för operativsystemet som två kärnor, men du har inte så många resurser som du skulle från två traditionella AMD-kärnor. Den här tabellen från vår Bulldozer-recension belyser en del av problemet när man tittar på fronten:

Det är sällsynt att du kommer någonstans i närheten av maximalt hårdvaruutnyttjande, så låt dig inte avskräckas av dessa deltas, men det är en avvägning som AMD gjorde genom Bulldozer. I allmänhet valde AMD bättre utnyttjande av färre resurser (delvis genom att öka vissa datastrukturer och andra element som matar exekveringsenheter) jämfört med att helt enkelt kasta fler transistorer på problemet. AMD valde också att minska förhållandet mellan heltal och FP-resurser inom x86-delen av sin arkitektur, helt klart för att stödja en övergång till APU-världen där GPU:n kan tillhandahålla en betydande mängd FP-stöd. Piledriver ändrar inte i grunden någon av dessa balanser. Rörledningsdjupet förblir oförändrat, liksom fokus på att sträva efter högre frekvenser.

Grundläggande för Piledriver är en betydande växling i den typ av flip-flops som används genom hela designen. Flip-flops, eller floppar som de brukar kallas, är enkla logikdelar som lagrar någon form av data eller tillstånd. I en mikroprocessor kan de hittas på många ställen, inklusive början och slutet av ett pipelinesteg. Arbete utförs före en flopp och begås vid floppen eller arrayen av floppar. Utsignalen från dessa floppar blir insignalen till nästa logikmatris. Normalt är floppar hårda kantelement – ​​data låses vid den stigande kanten av klockan.

I mycket högfrekventa konstruktioner kan det dock finnas en stor variation eller jitter i klockan. Antingen måste du lägga mycket tid på att se till att din design kan stå för detta jitter, eller så kan du införliva logik som är mer tolerant mot jitter. Den förra kräver mer ansträngning, medan den senare förbränner mer kraft. Bulldozer valde det senare.

För att få Bulldozer till marknaden så snabbt som möjligt, efter alldeles för många förseningar, valde AMD att använda mjuka kantflopar ganska ofta i designen. Soft edge floppar är motsatsen till sina hårdare motsvarigheter; de är designade för att låta klocksignalen spilla över klockkanten medan den fortfarande fungerar. Piledriver å andra sidan var resultatet av ett systematiskt försök att byta in mindre hårda kantflopar där det fanns timingmarginal i designen. Resultatet är en påtaglig minskning av strömförbrukningen. Överlag är det en 10% minskning av den dynamiska energiförbrukningen jämfört med Bulldozer, och vissa arbetsbelastningar driver tydligen till och med på en 20% minskning av aktiv effekt. Med tanke på Piledrivers roll i Trinity, som en mestadels mobilfokuserad produkt, var denna effektminskning väl värd ansträngningen.

I fronten lade AMD in ytterligare arbete för att förbättra IPC. Schemaläggarna är nu mer aggressiva när det gäller att frigöra tokens. I likhet med debatten mellan mjuk och hård flip-flop är det alltid lättare att vara konservativ när du drar tillbaka en instruktion från en kö. Det underlättar verifieringen eftersom du inte behöver vara lika bekymrad över förhållanden där du av misstag kan skriva över en instruktion för tidigt. Med den stora ansträngningen att få en helt ny arkitektur från marken bakom sig kunde Piledrivers ingenjörer fokusera på större förfining i schemaläggarna. Strukturerna blev inte större; AMD använder dem just nu bättre.

Utförandeenheterna är också lite biffigare i Piledriver, men inte mycket. AMD hävdar betydande förbättringar i flyttals- och heltalsdelningar, anrop och returer. För klientens arbetsbelastningar visar dessa vinster minimala (under 1%) förbättringar.

Förhämtning och förutsägelse av gren är båda avsevärt förbättrade med Piledriver. Bulldozer gjorde en enkel sekventiell förhämtning, medan Piledriver kan förhämta olika datalängder och över sidgränser i L1 (främst en fördel för serverns arbetsbelastning). I Bulldozer, om förhämtad data inte användes (felaktigt förhämtad) skulle den täppa till cachen eftersom den skulle komma in som den senast åtkomna data. Men om förhämtad data inte används omedelbart är det troligt att den aldrig kommer att användas. Piledriver taggar nu omedelbart oanvänd förhämtad data som minst-nyligen använd, vilket gör att cachekontrollern snabbt kan avhysa den om förhämtningen var felaktig.

En annan förändring är att Piledriver inkluderar en perceptrongrenprediktor som kompletterar den primära grenprediktorn i Bulldozer. Perceptronalgoritmen är en historiebaserad prediktor som är bättre lämpad för att förutsäga vissa grenar. Den fungerar parallellt med den gamla prediktorn och taggar helt enkelt grenar som den är känd för att vara bra på att förutsäga. Om den gamla prediktorn och perceptronprediktorn inte är överens om en taggad gren, tas perceptronens väg. Att förbättra noggrannheten för förutsägelse av grenar är en utmaning, men det är nödvändigt i design med mycket pipeline. Den här typen av sekundära prediktorer är ett måste eftersom det inte finns något som passar alla när det kommer till grenförutsägelse.

Slutligen lägger Piledriver också till nya instruktioner för att bättre anpassa sin ISA med Haswell: FMA3 och F16C.