AMD är inte ensamma om CMT

Blev aldrig riktigt klok på vad AMD menade med "reversed hyperthreading", kör man SMT har man ju fördelen att alla ALU-enheter kan användas av en tråd i enkeltrådade program så det borde inte vara den aspekten man kallande för "reversed hyperthreading". Fick mer känslan att det är det som POWER8 och de SPARC T4/T5 har där man dynamiskt kan styra hur många trådar som ska vara aktiv per kärna, vettigt om man vill garantera att något specifikt enkeltrådat program får lägsta möjliga latens.

Enda fördelen med en 2+2 splitt är att man får mer konsekvent prestanda per tråd oavsett om två eller en tråd används per modul, problemet är att det är konsekvent låg prestanda p.g.a. av smal back-end då den är uppdelad. Ska man vara riktigt riktigt petig så är inte bredden 2 på Bulldozer, det finns 4 "heltals-pipelines" per CPU-tråd men 2 av dessa är extremt begränsade i vad de kan göra (kan i princip bara utföra "lea" load-effective-address) så i praktiken tar nära nog alla x86-instruktioner resurser från någon de två kapabla pipelines (som hanterar interna instruktioner, en x86 instruktion kan bli flera interna instruktioner). Att IPC även på Steamroller ligger i nivå med Jaguar, som verkligen är 2 bred, visar att den design man valde beter sig i alla fall som 2-wide.

Backar man ett gäng år så var en x86 front-end betydligt mer komplicerad jämfört med en relativt "ren" RISC som t.ex. PowerPC. Idag så finns det så mycket annat i front-end som tar transistorer, t.ex. branch-predictor, loop-detectors, olika former av mikrokod-cacher för att snabba upp loopar, register renaming etc. Så frågan är hur mycket transistorantalet skiljer sig i en high-end CPU mellan olika instruktionsuppsättningar.

Flaskhalsen i Haswell verkar vara just front-end i det lägen båda trådarna används då effektiviteten av HT i princip var helt opåverkad av dubblad cache-bandbredd, ökning av bredd på back-end från 6 (fram till IVB) till 8 mikroinstruktioner. e6500 är 4 bred då den maximal kan påbörja (issue) 4 instruktioner per kärna, men back-end har 5 heltalsenheter, 2 minnesenheter och en flyttalsenhet (AltiVec kapabel), en mix som ändå verkar kunna hantera två separata front-ends som kan avkoda upp till 4 instruktioner var.

AMD kunde tidigare hämta och avkoda 4 x86 instruktioner per modul och det borde vara 4 x86 instruktioner per CPU-tråd sedan Steamroller. Rent teoretiskt kan man sedan påbörja 4 interna instruktioner per cykel per CPU-tråd, men i praktiken blir det alltså bara 2. Förstår inte hur man trodde att separata avkodning skulle hjälpa Steamroller då det är steget efter som är flaskhalsen.

Och är inte en uppenbar nackdel med att två trådar delar "fetch" den att programräknaren för de två trådarna kommer typiskt vara på olika ställen så det blir väldigt svårt att effektivt hämta in instruktioner från två trådar via en enskild "fetch" enhet? Av den anledningen känns en separat "fetch" per CPU-tråd väldigt vettigt, mer rimligt att dela avkodning då. "fetch" är ju också den del som använder "branch-predictor" resultatet, så känns också som en uppenbar sak man vill ha separat per tråd innan man börjar dela på andra saker.

SMT är vettigt då det tar väldigt lite transistorer i anspråk, multicore är vettigt då kapaciteten ökar i stort sätt linjärt med antal kärnor. Frågan hur den vettigaste kompromissen mellan dagens SMT och multicore ser ut, verkar i alla fall som Freescale hittat en betydligt bättre kompromiss än AMD här men båda verkar haft samma utgångspunkt i varför man anser att SMT inte är optimalt.

Det man kan konstatera är att det är helt rimligt antagande att det finns en mer optimal kompromiss mellan att duplicera hela CPU-kärnan och vad de flesta SMT-implementationer gör (duplicera enbart register). Väldigt mycket pekar dock på att AMD valde väldigt fel delar att duplicera, Freescale har bevisligen gjort ett bättre val med tanke på hur bra perf/W man får men inte alls säkert att de har hittat den mest optimala lösningen.

Är inte alls osannolikt att det blir lite olika mix på vad som bör dupliceras beroende på om man vill få maximal perf/W/CPU-tråd, total perf/W, total perf, perf/CPU-tråd, etc. Så det är definitivt ett område som borde undersökas mer då vi har nått en vägg i hur hög IPC man kan nå och även hur hög frekvens man kan nå.

På serversidan är den uppenbart vilken katastrof BD var då AMD inte lyckats skapa något BD-baserat som definitivt klår Opteron "Magny-Cours" (K10 kärnor).

Som presentationen från 17 oktober 2014 säger: "Coming out of stealth mode at last week’s Linley Processor Conference". Väldigt få har nog hunnit bilda sig en uppfattning om detta än, hade själv aldrig hört talas om detta tidigare så STORT tack för länken!

Nästan alla individuella delar som VISC innehåller har gjorts tidigare, men själva mixen de försöker sig på är unik vilket gör det väldigt intressant att följa utvecklingen kring detta.

Det jag däremot helt saknar i presentationen är varför deras angreppssätt skulle ge bättre enkeltrådprestanda än vad t.ex. Intel Haswell, IBM POWER8 och till mindre del även Nvidia Denver och Apple Cyclone får. Problemet med att öka enkeltrådprestanda har helt enkelt att göra med att det bara finns en begränsad parallellism i varje enskild instruktionsström, det man kan göra är att titta längre och lägre fram men ju mer man gör det ju mer måste man gissa vad programmet kommer göra och när man gissar fel har man spenderat ström på något helt meningslöst. Haswell och POWER8 har upp till ca 200 instruktioner de undersöker.

Modellen att använda enkla distribuerade schemaläggare är definitivt inte ny, man vet att detta är strömsnålare än en central schemaläggare så i princip alla CPU-designer optimerade för låg strömförbrukning, t.ex. ARM Cortex A15, Qualcomm Krait & Intel Silvermont använder sig av detta. En central schemaläggare ger bättre total prestanda men kostar väldigt mycket mer transistorer, används av t.ex. Intel Haswell, AMD Steamroller & IBM POWER8.

Modellen att analysera koden och transformera den till en annan uppsättning instruktioner är inte heller ny, Transmeta var nog först med den tekniken men Nvidias Denver kommer också använda sig av detta. Tanken här är intressant, genom att översätta och till viss del ordna om instruktionerna så kan man göra en enklare out-of-order eller helt enkelt köra en in-order design (vilket Nvidia Denver gör). Out-of-order back-ends kostar väldigt mycket mer transistorer jämfört men in-order, men normalt sätt blir det helt meningslöst att göra en "bred" in-order design då man nästan aldrig kan utnyttja bredden då det kräver en ganska specifik ordning av instruktioner som ska till de tillgängliga ALU och minnesenheterna. Blir väldigt spännande att se hur bra/dåligt Nvidia Denver kommer hantera en 7-wide in-order design baserat på att man gör en analys av ARM-instruktioner och konverterar till de interna instruktioner som Denver förstår (är 7 sådana som kan köras).

Det Soft Machines kallar "kärna" tycker jag mer ser ut vad man skulle kalla en "pipeline" i en symmetrisk back-end. Grejen är att ingen gör symmetriska back-ends längre, sista var nog AMD K7, K8 och K10 som hade 3 pipelines som kunde göra allt. Intel har alltid kör med en asymmetrisk back-end sedan deras första superskalära design, Pentium.

Ser inte riktigt hur Soft Machine skulle kunna få en IPC som kliver förbi Haswell eller POWER8 med den förklaring de ger här. Visst kan man låta 4 eller till och med 8 kärnor jobba på samma tråd, men de säger ju själva att det är väldigt snabb "diminishing returns" på det. POWER8 är ju 10-bred i backend, Haswell är 8-bred men ändå har de inte speciellt mycket högre IPC än Core2 som var 5-bred i backend eller Nehalem->Ivy som var 6-bred.

Bredd är inte allt, Apple Cyclone är 6-dispatch, d.v.s. den kan verkligen påbörja 6 instruktioner per cykel men ingen vet hur bred back-end den har (utom Apple då). Som jämförelse är Haswell är 4-dispatch, d.v.s. den kan bara köra 4 x86 instruktioner per cykel, men back-end kan peak:a på 8 interna instruktioner på en cykel. Silvermont är bara 2-dispatch men tack vare att en sådan är så mycket enklare kan man klocka den mycket högre än Cyclone vid samma strömförbrukning och i slutändan är Cyclone och Silvermont väldigt jämna i enkeltråd-prestanda.

Det man kan tänka sig med Soft Machines är att varje kärna är enkel -> kan klockas högt + man kan slå ihop många för hög total bredd -> hög IPC. Rätt säker på att det gör att göra benchmarks som ger fantastisk prestanda, är väldigt mycket mer skeptiskt till att det presterar bra i "riktigt" applikationer. ARM Cortex A15 och till mindre del Apple Cyclone är väldigt bra exempel på designer som är helt fantastiska med laster som inte har komplicerade data-beroenden via pekare, d.v.s. brutala Geekbench-resultat, men som faller ganska platt i mer komplicerade applikationer.

Har tillgång och jobbat med ARM Cortex A7, A15 och Silvermont. A15 är snabbast på av alla dessa på triviala saker, men den är totalt chanslös i lite mer komplicerade applikationer mot Silvermont, ibland får den en IPC helt i nivå med A7 som är en mycket enklare och strömsnålare design. Får väldigt mycket känslan att VISC kan bli som Cortex A15, fantastisk på pappret men en besvikelse i verkligheten. Ser gärna att jag får fel på den punkten dock!

Ruggigt bra rapport från The Linley Group som Soft Machine länkar till.
http://www.softmachines.com/wp-content/uploads/2014/10/MPR-11303.pdf

Man tar upp exakt flera av de saker jag själv skulle sätta fingret på, t.ex.

"Although these results are impressive, they require some caveats to put them into perspective. A shorter CPU pipeline reduces branch penalties and other pipeline haz- ards, thereby improving IPC compared with a longer pipe- line. In addition, a low CPU speed reduces the effective latency of caches and main memory (measured in CPU cycles), again improving IPC relative to a CPU with a faster clock."

Skulle vilja lägga till här att man jämför en IPC på 2.1 för ARMv7 instruktioner mot en IPC på 1.4 för x86 instruktioner, det går inte att jämföra direkt IPC mellan olika ISA man måste där jämföra antal cykler för att utföra en specifik uppgift. T.ex. så är en read-operation-write, t.ex. addera ett till en minnesposition 3 instruktioner på ARMv7 men det är 1 x86 instruktion. Däremot är tar det lika många ARM och x86 instruktioner att utföra mattematiska beräkningar om argumenten redan finns i register. Rent generellt gör en CISC mer arbete, framförallt om arbetet kräver minnesaccess, per cykel än vad en RISC gör.

"Soft Machines has run many tests and simulations of its VISC technology. It estimates the second core improves performance by an average of 50–60% across a variety of benchmarks. This factor implies that the test chip would achieve about 1.3 IPC when using a single core—consider- ably higher than Cortex-A15. This higher IPC includes the effects of the lower clock speed and shorter pipeline"

Att man har en kort pipeline driver upp IPC rejält, men det betyder också att man inte kan klocka speciellt högt. Trots denna korta pipeline så får man 50-60% effektivitet, vilket via Ahmdal's lag ger precis det som Soft Machines simuleringar visar, effekten av att lägga till fler kärnor faller snabbt och enligt Ahmdal's lag så skulle man inte få mer än 3x även om antal kärnor var oändligt. Förlänger man pipeline, vilket är ett krav för högre klockfrekvens, 1GHz lär man inte nå med 10 steg, så kommer effekten av kärna två bli ännu mindre. Så här ligger nog akilleshälen i denna design, den kan bli grym i designer som ska maximera perf/W genom t.e.x 4 kärnor med väldigt kort pipeline och låg frekvens men det kommer inte bli något som matchar Haswell/POWER8 i absolut perf/CPU-tråd.

Det jag verkligen gillar med VISC är möjligheten till M-till-N mappning av front-end och back-end, d.v.s. M CPU-trådar kan i stort sätt steglöst läggas ut över N fysiska kärnor. Den delen av designen tror jag på, problemet ligger nog i effektiv kommunikation där man slår ihop resultaten från den olika fysiska kärnor till CPU-trådar igen, känns allt annat än trivialt och frågan om komplexiteten där växer linjärt eller (mer troligt) exponentiellt med antal CPU-trådar man hanterar.

Insåg att jag slarvade med namngivning ovan så det blev inte rätt, skrev "issue" där det borde stått "dispatch".

fetch/decode-width: antal instruktioner (eller bytes för x86 då instruktioner har variabel längd) man kan läsa in per cykel
dispatch-width: antal instruktioner som front-end kan köa till back-end
issue-width: antal instruktioner som kan påbörjas av back-end per cykel
retire-width: antal instruktioner som kan färdigställas per cykel, sällan man hittar denna information

En nackdel man verkar få på e6500 med separata front-end är relativt låg decode-width, så det borde bli en flaskhals när bara en tråd används. Å andra sidan är en IPC på närmare 2.0 fantastiskt bra även för "big-core" och med tanke på kapaciteten på back-end så kanske man kan komma ganska nära vad front-end fixar.

Man ser också på dessa bilder att storleken på out-of-order fönstret inte alls ligger på samma nivå som för Haswell och POWER8, så Freescale har naturligtvis valt lite tillrättalagda exempel när de visar hur effektiv deras design är. Men ett väldigt effektivt sätt att hålla back-end sysselsatt trots mindre OoO-fönster är ju olika former av SMT, så designen ser riktigt bra ut.

Man ser också att man valt distribuerade schemaläggare mot back-end, precis som i andra designer som optimerar för låg strömförbrukning. Inte fullt lika effektivt som en central schemaläggare som t.ex. Haswell och POWER8 använder dock.

AltiVec var bättre än SSE fram till SSE3 ungefär, men utvecklingen har nästan stått stilla på AltiVec medan den fortsatt i väldigt hög fart för SSE/AVX. Man ser att Freescale inte riktigt brytt sig speciellt mycket om flyttal då det bara finns 1 ALU för detta per två CPU-kärnor. Tror ändå detta hade varit en bättre design för spelkonsoler än Jaguar då den dels går att klocka högre med samma TDP och dels så verkar många spel vara begränsade i AI och liknande som är heltalsintensivt.

Vad det gäller IBM och PowerPC så har de (väll?) helt lämnat det spåret. De har en den kontrakt kvar till saker med stora volymer, fått för mig att de fortfarande har ett finger i spelet med i PS3, Xbox360 samt Wii-U. Man annars är det bara POWER som gäller framöver, även om POWER och PowerPC numera är binärkompatibla med varandra. POWER är high-end och har mer funktioner lämpliga för server medan PowerPC är inbyggda-system och har funktioner mer lämpliga där.

Den man säger är att VISC inte behöver stöd från kompilatorn, man tar en "vanlig" ARM binär och VISC översätter den on-the-fly till "sitt" språk internt. Nvidias Denver tar detta ännu ett steg lägre, även där består programmet av en "vanlig" ARM binär som översätts till ett eget format, men här kan det egna formatet även sparas utanför CPUn och på så sätt bli externt synligt. Finns det redan en översättning och den "vanliga" binären inte har ändras så kör man den direkt. Man måste därför köra ett program ett par gånger på Denver innan man når maximal prestanda.

Det jag refererade till att VISC kanske presterar illa på vissa typer av program är att det finns flera CPU-designer, t.ex. Cortex A15, som ser riktigt bra ut på pappret (den borde vara snabbare än Silvermont och Jaguar) och den prestandan ser man också i vissa program som är väldigt "snälla". Däremot är många riktigt program, framförallt server-programvara, rätt "elaka" i bemärkelsen att de använder stora mängder data och läser/skriver data på ett sätt som är väldigt svårt för CPUn att förutse. En CPU som hanterar detta dåligt kommer då bara "trampa vatten" och inte göra något vettigt oavsett teoretisk kapacitet, ser inte riktigt hur man angriper detta problem i VISC mer än väldigt låg frekvens och kort pipeline (som båda effektivt hjälper till men hindrar hög absolut perf/tråd).

Ju mer jag tänker på det ju mer övertygad blir jag över att "reversed hyperthreading" kommer av att någon på AMD försade sig kring tekniken som Soft Machine jobbar på, AMD är ju med på listan över investerare. Tror vi att det bara är AMDs ARM-design "K12" som kör med teknik från detta eller hinner de även få in något i Zen? Ser inte riktigt poängen för Soft Machine att jobba med x86 om inte AMD eller Intel är intresserade då ingen annan riktigt har tillgång till den teknik som krävs för att göra en x86 CPU idag.

Håller med dig om att man lika gärna kan använda Aarch64 i stället för PPC, men 32-bitars ARM är en smärre katastrof om målet är en multicore-design som ska klockas högt, där är PPC ett långt bättre val. Var ju inte heller någon som hade en ARM-design i tid för lansering av PS4/XBO, e6500 har ju funnits på marknaden sedan 2012.

Du har helt rätt att distinktionen POWER och PPC är inte relevant, så det jag menar är att IBM i stort sätt bara fokuserar på POWER för servers sedan några år tillbaka. Tidigare hade ju IBM rätt mycket för inbyggdasystem-marknaden, 400-serien t.ex.

LSI hann ju konvertera sin Axxia-serie till ARM (Cortex A15 för tillfället i AXM5500-serien) i sin Axxia serie innan uppköpet. Har kört en del på topp-modellen av AXM550 med 16st Cortex A15 och där är ett exempel på hur väldigt illa det blir med 32-bitars ARM i enheter med många CPU-kärnor och där man vill ha lite pulver under huven. CPU-mässigt blir den plattformen mosad av 8-kärnors Rangeley ("nätverksvarianten" av Avoton) om plattformarna har ungefär samma TDP. Ok, IBM var med kring designen av ACP3400, jag räknade den designen till LSI. Vet att Ericsson kör (eller man ska kanske säga körde) väldigt mycket med PowerPC från LSI. Får se hur snabbt Intel lyckas konvertera Axxia-serien till Atom, för det måste ju en av de saker som händer framöver.

Tycker 32-bitars ARM fungerar bra i dual-core designer, men har inte jobbat med någon ARM-baserad plattform som fungerar speciellt bra förbi dual-core. Allt kommer naturligtvis inte från ISA, men tittar man på hur ARM agerade kring kompilatorstöd för ISO-C2011/ISI-C++2011 där multicore-stöd för första gången kom in som del i standaren så känns det som även ARM insåg problemen med 32-bitars ARM och de pekar bara på att 64-bitars ARM inte har dessa problem (på pappret är 64-bitars ARM en extremt bra match för 2011 års C/C++ standarder kring multicore).

Men du har rätt att IBM finns kvar även inom inbyggda-system. Har jobbat i områden där PowerPC används rätt frekvent och tidigare såg man en hel del IBM-baserade lösningar, t.ex. 440, men på senare tid har det bara varit LSI och framförallt Freescale. Tycker det är lite konstigt att jag inte sett A2 då många projekt är nätverkscentrerade. Plus att jag är säker på att IBM har sagt att man på sikt vill ut ur embedded, men hittar inte någon sådan artikel via lite snabb googling.