AMD arbetar på ersättare till Bulldozer – gör skräddarsydd ARM-kärna

Den mest vedertagna separationen av RISC vs CISC är huruvida det finns maskin-instruktioner som direkt kan jobba mot minne eller om argument till maskin-instruktioner måste ligga i register.

Med den definitionen är ARM definitivt en RISC.

Å andra sidan har 32-bitars ARM väldigt komplicerade instruktioner för att vara en RISC och väldigt CISC-lik flora av sätt man kan hämta/skriva från minne jämfört med "rena" RISCar som MIPS och SPARC. Å andra sidan har "rena" RISC-ar visat vara sig rätt ineffektiva i det att det krävs relativt många instruktioner för att göra saker, är just detta som ARM undvikit med sin mer komplicerade format och CISC-liknande load/store.

Känns som störta fördelen CISC får är i s.k. atomära instruktioner som typiskt är väldig viktiga vid multicore-programmering. Här kan CISC koda sina atomära instruktioner som en enskild instruktion (då det är OK att ha minne som argument) medan RISC alltid får modellen
1. load something with "reservation"
2. spekulative do something that should be atomic
3. store with check that "reservation" is still OK, if not goto 1 else done!

Cortex A57 kärnor är de näst största ARM-kärnor som någonsin tillverkats, bara Apples Cyclone-kärnor som är större/mer komplicerade. AMDs Jaguar-kärnor är med x86-mått väldigt små, helt i nivå med Cortex A15 i storlek. Så "sanningen" att ARM-kärnor är mindre/strömsnålare än x86-kärnor är inte längre sant, så fort ARM började göra dual/trippel-issue kärnor med out-of-order execution så blev fördelen av en enklare avkodare helt irrelevant räknat i antal transistorer.

Svårt att exakt uttala sig om Cortex A57 prestanda, men Cortex A15 (A57 är i princip en A15 med 64-bitars stöd) är definitivt långsammare än AMDs Puma-kärnor, så lite svårt att se när Cortex A57 blir ett bättre val än Puma. Aarch64 är i.o.f.s. en väldigt väldesignad arkitektur, den bästa ISA (Instruction Set Architecture) som skapats än så länge i min mening, men ISA är långt mindre viktigt än många CPU-flamewars gör gällande.

Såg på Nordichardware

Fast den minimala information som finns kring K12 pekar på att det kommer bli en Aarch64-baserad (64-bitars ARM) som prestandamässigt kommer ligga mellan dagens Puma och Kaveri. En sådan CPU skulle idag vara den överlägset snabbaste ARM CPUn då redan Puma är snabbare än något som finns i ARM-lägret, men kan överhuvudtaget inte se någon framtida strategi kring x86.

Är kanske vettigt för AMD att inte ha allt för många CPU-designer på gång samtidigt, men är det verkligen rätt strategi för AMD att helt ta bort fokus från x86 produkterna? (AMD har en x86 licens som de inte betalar något för då Intel behöver AMD64 och AMD behöver grundläggande x86). Framförallt med tanke på att Windows i praktiken kräver x86 och tycka vad man vill om det som OS men det är fortfarande det mest betydelsefulla OSet på konsumentprodukter och arbetsredskap. Skulle inget hellre än se ARM + Linux bli det nya desktop OSet, men känns inte sannolikt. Linux som OS klarar sig ändå rätt bra då det totalt sett är finns på klart fler "datorer" än Windows.

Det låter faktiskt väldigt konstigt att använda en ARM-kärna för just videoavkodning för de är på tok för klena för det. Video avkodas bäst av specialdesignade kretsar vilket redan görs i alla ARM-plattformar. Moderna grafikkort har också dedikerad hårdvara för just video. Det är också det som är anledningen till att en liten mediaspelare för 700 kr som drar ett par watt klarar av att spela upp 1080p h.264 med hög bitrate utan att lagga och hacka.

Från Techraport, som Swec länkar till.

Två grenar alltså en effektsnål ARM och en högpresterande x86.

Utfick från denna bild

som jag förstår det blir K12 den första CPU där AMD endast licensierar Aarch64 ISA men designar mikroarkitekturen själv i stället för att köpa IP från ARM som i fallet Cortex A57.

Är inte alls säker på att Intel når 10nm till 2016, undrar om det kommer vara ekonomiskt försvarbart att fortsätta pusha en tick-tock cykel vartannat år när kostnaderna för att utveckla noder + bygga fabriker ökar som de nu gör med varje ny nod.

En modern ARM med NEON-stöd (motsvarigheten till SSE), vilket är alla modeller efter den Cortex A9 som användes i Tegra2, fixar att avkoda film. Men det skulle vara väldigt strömslukande jämfört med att använda de specialkretsar som alla(?) modern ARM SoCer (och x86 SoCer) innehåller.

Little-endian / big-endian spelar väldigt liten roll nu för tiden, framförallt när det finns instruktioner som movbe (x86 instruktion, move big endian) som tar bort eventuellt kvarvarande kostnad när man jobbar med t.ex. nätverkskod. Dock är PCI definierat som little-endian och det är nog en större kostnad att hantera på en big-endian maskin än att hantera nätverkspaket på en little-endian (om man skulle sakna movbe eller liknande).

MIPS och PowerPC är också definierat för både big- och little-endian. Nästan alla realtids OS fördrar big-endian, men i Linux föredrar de flesta little-endian på de plattformar man kan välja.

Vad det gäller instruktioner så är det helt sant att majoriteten av alla x86 instruktioner som används i de flesta program är bara en väldigt liten andel av alla som finns. Men i vissa lägen kan en/ett par specifik/komplicerad instruktion(er) göra underverk för prestanda, som SSE-instruktionerna cmplepd + movmskpd med vilka man enkelt fördubblar den mest prestandakritiska delen av t.ex. beräkning av Mandelbrot-mängden. Atomär operationer är ett annat exempel som i antal alltid är en väldigt liten andel av alla instruktioner som körs (annars har programmet grava prestandaproblem), men detta är instruktioner som x86 verkar kunna göra effektivare än RISC just därför att CISC tillåter instruktioner där operander direkt refererar minne och inte bara register.

Men den slår inte min Pentium MMX 166 mhz va? Den burken har ju en turbo-knapp bredvid startknappen! Det ni, TURBO! *bruuumm brrrrruuumm bruuuuum!!*

För övrigt, nice att AMD äntligen skrotar Bulldozer, min Piledriver rullar ju på rätt bra med tanke på att mitt musikprogram skalar väldigt jämnt över mina 8 kärnor (efter Nebula på varje kanal så ligger alla CPU:erna på 75-90% haha, hör verkligen hur datorn svettas!), men det finns nog en anledning att dom inte fortsatte efter den.

Men jag måste säga att Intel inte heller går framåt med stormsteg, minns när en generation gick från 1 ghz till 2 ghz (+mer beräkningar/hz), nu så blir det +5-10% per generation.

När intel gick från 1 till 2 GHz så sänkte de sitt antal beräkningar per cykel rätt duktigt.
Fanns ju en anledning till att folk hellre ville ha en 1,4GHz Tualatin än en Willamette. För att inte tala om Thunderbird och Palomino.

Kanske inte har till denna artikel att göra, men är det någon som kan svara på varför dem inte lägger lite mer tid på sina originalkylare?

Gäller båda lagen.

Pengar. Det behöver bara skicka med en enkel kylare som gör jobbet och inte mer. Sen har de generellt lite andra krav på kylaren än gemene Swecklockersanvändare. Till exempel måste de vara små för att kunna användas av OEM i små chassin. Om man måste prioritera storlek och pris är det inte så mycket man kan göra mer än en solid aluminiumkloss med en fläkt på.

Fast AMDs stockkylare är rätt så okej faktiskt. Det finns kopparrör till och med. Stora problemet är fläkten de skickar med.

Absolut! att limma dit en bra 8 cm fläkt och säkra med buntband ger ett bra resultat.
En bra fläkt är det enda som saknas.