AMD lanserar A-serien "Trinity" APU

Om man inte bara jobbar riktigt triviala saker så vill man som programmerare ha MASSOR med CPU-kraft. Kör själv med Core i7 2600 som arbetsdator och skulle definitivt inte tacka nej till mer CPU-kraft då jag fortfarande har kompileringstider som är plågsamt långa i vissa fall. På våra laptops kör alla utvecklare med den snabbaste Core i7 QM som fanns när dator köptes.

Och man blir förvånad när man får höra vad folk använder Excel till. Min personliga användning av detta program är väldigt grundläggande, men inom vissa områden så använder folk Excel för väldigt avancerade och tidskrävande/CPU-krävande beräkningar.

Skulle säga att på en notebook så är CPUn oftare den begränsande faktor jämfört med desktop. Framförallt då många helt valt bort desktop idag och köra allt på sin laptop.

Ytterst få förväntar sig faktiskt något större spelupplevelse på sin laptop och tar vi bort spel så duger redan "Intel HD" (föregångaren till HD2000/3000 som satt i "Arrandale", d.v.s Westmere för bärbara). Och tillhör man den lilla skara som vill spela på laptop så får man nog inse att ingen laptop under 15.000kr kommer fungera och i denna prisklass så sitter det en diskret GPU i maskinen.

Fanns ju en länk till AnandTechs test av Piledriver tidigare i tråden. Där testas just A10-4600M.

Ser faktiskt ut som en riktigt bra produkt om den kommer hamna i laptops <8000kr.
Riktigt bra GPU prestanda om man jämför med andra laptops i den prisklassen!
Däremot så känns det lite sådär när A10-4600M i genomsnitt är långsammare än Core i7-2637M (en CPU med 17W TDP) på CPU delen.

Sweclockers sa redan vid lanseringen att de kallar Bulldozer, och nu Piledriver, for två respektive fyrakärnig eftersom AMD själva gör det.

Jämförelsen med HT haltar eftersom det faktiskt sitter två heltalsenheter i varje modul med egen L1 chache och egen scheduler. Det blir alltså inte alls rättvist eftersom du får dubbelt så många heltalsenheter att slänga på problemet. En modul är alltså inte en vanlig dualcore men det är betydligt mer än en implementering av Simultanious Multithreading som HT är. Enklast är nog att kalla det moduler och jämföra med prisnivåer istället för antal kärnor för hur man än gör blir det fel.

Vem ska du köpa av då? Intel? De är mer för stängda standarder än AMD.

Är det bara jag som älskar de lite subtila StarWars referenserna på Anandtech? http://www.anandtech.com/show/5831/amd-trinity-review-a10-460...

Krävs väl iofs att man minns vad rubriken var på recensionen av Core2Duo från 2006
http://www.anandtech.com/show/2045

Visst är AMDs variant med likt en "riktig" dual-core än vad HT är. Men likheter med Intels HT är långt större än skillnaderna

Prefetcher och decoder: delas på båda och på båda så måste alla instruktioner som avkodas tillhöra SAMMA tråd. Det finns ett fall i SNB när båda trådarna kan få instruktioner samma cykel: ena tråden får instruktioner från avkodaren och den andra tråden befinner sig i en loop och får då sina instruktioner från en speciell "loop buffer". BD har inget som motsvarar den "loop buffer" som SNB har.

L1I, L1TLB och L2 cache: delas på båda

L1D: delas på SNB, separat på BD. Problemet här är att L1D bara är 16kB och den är s.k. "write-through" mot L2 så alla skrivningar som görs går mot L2 som delas. Alla andra moderna CPU:er har en s.k. "write-back" L1 cache som är betydligt snabbare än en "write-through" för skrivning, dessa två är lika snabba för läsning.

AGU (Address Generation Unit) och ALU (Aritmetic Logical Unit): SNB har 3st AGU och 3st ALU som delas, BD har 2st AGU och 2st per "kärna". Här ligger en stor del i förklaringen till att BD aldrig kommer få lika hög IPC (Instruction Per Clock) som SNB på enkeltrådade saker. Phenom I/II hade 3st "pipeliens" där alla 3 tog hand om jobbet motsvarande en AGU eller en ALU (exakt vilket bestämdes per cykel av instruktionen som skulle köras).

Flyttalsdel: delas på båda

"branch predictor": delas på båda

"Retirement" (steget när resultatet skrivs tillbaka och blir synligt för andra CPU-trådar): delas på båda

Så enda skillnaden är alltså att BD har separat L1D cache och separata ALG/ALU enheter. SNB har dock möjligheten att använda sina 3 ALG + 3 ALU även när man kör 1 tråd. BD har 2+2 ALG och 2+2 ALU som är separat.

Hm, en fyrkärning sandybridge med 6mb har en yta på drygt 200mm2 o består av ca 1.2miljarder transistorer. Det är jämförbart med Trinity. Så om man antar att Intel o amd är lika duktiga på att utnyttja en given chipyta ska vi nog inte ha för stora förhoppningar. Speciellt inte då amd väljer att låta gpun ta en större del av chipytan. Vad gäller kostnad så är den direkt kopplad till chipytan o jag har svårt att tro att amd kommer billigare undan än Intel.

Den avgörande skillnaden är alltså hur mycket chipyta som går till gpu resp cpu.

Och då har jag utelämnat det faktum att Intel redan är på 22nm o trigate.

Jag ser inte något stort problem med att prefetch och decoder delas om man ska se till vad som är en kärna eller inte. Likaså cacher. Det har ju varit delat mellan kärnor länge i andra arkitekturer. Sedan är det inte direkt ett minus att flyttalsdelen delas. Jag ser det som två stycken som kan samarbeta vid behov. Det är bara vid AVX som FPU arbetar som en enda FPU, annars arbetar den som två, som kan användas av båda kärnorna. Eftersom den mer eller mindre alltid arbetar som 2x128 så ser jag den som dubbla FPU som kan samarbeta. Det syns tydligt på dieshots att det verkligen är två FPU som delar frontend.
Det enda som egentligen delas är prefetch, decode och lite L1. Det finns 2x128bit FPU (med gemensam scheduler) och det finns 2 INT kluster. Det viktigaste i en kärna.

Så är det ju alltid, i varje nyhet eller forumtråd som handlar om AMD skall det in några och övertyga om att intel är så mycket bättre. Tröttsamt var ordet!

Japp. Håller med dig fullständigt om det!

Nog för att jag håller med om att namndiskussionen är meningslös. Men man måste alltid få dra jämförelser med konkurrenten. Det är bara för riktiga fanboys det inte finns ett alternativ, för alla andra är det viktigt att reda ut för och nackdelar mellan konkurrenterna. Och när en nyhet så är det viktigare än annars.

Det innebär inte att man måste in och spamma varje AMDtråd med tjat om Intels förträfflighet som det är nu.

Skickades från m.sweclockers.com

Som sagt så tyckte jag namndiskussionen var onödig. Men man ska kunna diskutera sakligt.

Om du har en "riktig" dual core, som t.ex. Phenom X2, så delas ju varken prefetch, decoder, L1D, L1I eller L1TBL, "retire" eller ALU/AGU.

Sedan Core2 så har den största flaskhalsen i Intels CPUer varit just avkodaren och det trots att Core2 "endast" hade 3 ALU och 2 AGU. I Sandy Bridge lade man till en "level 0 instruktions cache" som innehåller redan avkodade instruktioner just för att minska trycket på avkodarsteget.
När båda "kärnorna" används i BD så ÄR det konstaterat att avkodaren är den största flaskhalsen.

I både BD och SNB så kan ju avkodaren maximal avkoda 4 instruktioner (5 i väldigt speciella fall på SNB). Det blir ju ett problem när nästa steg kan hantera upp till 8 instruktioner på BD om båda "kärnorna" kör och upp till 6 instruktioner på SNB (oavsett om en eller två trådar kör).

Och om beskrivningen kring hur FPUn fungerar på Bulldozer är helt fel så kan den köra två 128bits instruktioner parallellt, men det finns bara en "FPU scheduler" så båda instruktionerna måste komma från samma "kärna". "retire" steget är definitivt delat både för heltal och flyttal. Däremot så har BD ändå en fördel just på FPU jämfört med SNB. I SNB så är det samma ALU som tar hand om både flyttal och heltal medan BD har helt separerade enheter för detta.

Notera: trots att jag kanske låter väldigt kritisk till AMDs "kärnor" så tycker jag det är en väldigt bra ide då det, precis som HT, är ett väldigt effektivt sätt att få bättre prestanda på saker som kan använda många CPU-trådar utan att använda speciellt många transistorer. Och AMDs variant tenderar att prestera bättre på saker som är heltalsintesiva och inte använder massor med RAM (i.e. fallet när allt ligger i L1 cache >99% av tiden).

Det stora problemet är inte vilka känslomässiga band man har utan det faktum att konkurrensen avseende prestanda egentligen inte finns. Det gagnar ingen. Hade amd kunna stressa Intel lite mer hade inte Intels senaste cpu generation varit den gäspning som den nu är.
Bara att hoppas att AMD:s gpu försprång kan bibehållas och att den nischningen är vinstdrivande.

Lite cirkelargument här va? För att beskriva varför prefetch, decoder och L1 inte kan delas i en dualcore så tar du ett exempel där de inte delas som utgångspunkt. Kör man cirkelargument åt andra hållet så kan jag använda en Bulldozermodul som definition för vad som krävs för att få kallas dualcore och sedan konstatera att Piledriver lever upp till detta.

Här är inga argument för vad som är dualcore eller inte, mer vad som är flaskhals hos Bulldozer.
Jag skulle säga att jag -tvärtemot dig- är kritisk till deras moduler. Det är en intressant approach och tekniskt avancerad, men den ska kunna leverera. Och beräkningsenheter står och idlar så väldigt många cykler även i moderna processorer att det viktigaste är att hålla dem matade snarare än att ha fler av dem. HT gör ju att de befintliga matas bättre, modulkonstruktionen gör att de matas sämre men blir fler. Sedan verkar de inte har sparat någon vidare plats. En BD modul är dubbelt så stor som en stars-kärna, utan att ha några prestandafördelar. Däremot så har de försvårat för sig att mata beräkningsenheter tillräckligt snabbt. Det är alltså svårare att nå hög potential. Jag tror en ordentlig uppgradering av frontend på stars så att alla tre pipes utnyttjas bättre hade gett mycket bättre resultat.

Varför är det cirkelargument? Jag beskrev bara vad som skiljer det alla är överens är en "riktigt" dual core, d.v.s en design där man helt enkelt har två identiska och fullständiga kärnor. Fullständiga i bemärkelsen du kan ta bort alla delar som kärna X använder så kommer ändå kärna Y att fungera.

Likaså så var resten en argumentation att man i BD delar den enhet som oftast är flaskhalsen i moderna high-end x86 CPUer. Det skulle trycka än mer på varför BD-modul inte kan ses some en "riktigt" dual core.

Men fördelen med BD och än mer HT på Intel är ju att den extra mängd transistorer som går åt för att köra två trådar genom en fysisk kärna ger betydligt mycket bättre utdelning på detta jämfört med kostnaden att duplicera allt. För HT handlar det om <5% fler transistorer för den andra tråden och på BD handlar det om ~12% extra för integer-klustret.

Problemet för både Intel och AMD är att x86 har variabel längd instruktioner vilket gör det extremt svårt (många transistorer) att skapa en avkodare som fixar mer än 4 instruktioner per cykel, så det kommer bli lurigt att komma runt den största flaskhalsen. L0 cachen (µ-cache) i SNB hjälper bara lite då den fortfarande bara kan leverera max 4 µops, den stora fördelen är latens och strömförbrukning, man tar ju bort tiden och strömmen för att köra fetch och decode. Ryktet säger att Haswell kommer ha en rejält förbättrad µ-cache. Separat µ-cache för varje tråd kanske skulle kunna ge HT en rejäl boost.

Finns en anledning varför just decode-steget är så mycket sämre på Atom och Bobcat, max 2 instruktioner per cykel: massor med transistorer att spara här om man accepterar sämre prestanda.