AMD utvecklar ARM-baserade processorer för servrar och datacenter

[QUOTE=Yoshman;12844776]Här undrar man varför AMD tror att det blir enklare att vara en av rätt många ARM-utvecklare. Calxeda, Cavium, Marwell, FreeScale och Samsung (säker flera) kommer alla skapa server-lösningar baserad på 64-bitars ARM. På x86 är AMD en av två som har något att erbjuda på serversidan och Opteron har en bra rykte.

Känns som om steget att skapa en serverlösning på Bobcat för strömsnåla servers ligger mycket närmare tillhands än att börja designa ARM APU:er. Med Bobcat så har man

1. En mer kraftfull CPU än Atom som dock drar något mer ström (men kanske går att skala ner Bobcat mer?)

2. x86_64 är redan etablerat, vilket betyder att kompilatorer och utvecklingsverktyg är färdiga och väldigt mogna. För ARM är det Aarch64 (64-bitars ARM) som man siktar på, en arkitektur som inte är ett direkt super-set av dagens ARM arkitektur så det kommer krävas nyutveckling kring kompilatorer och liknande. Tittar man på utveckling för x86_64 så är det rimligt att anta att den utvecklingen kommer ta ett antal år innan kompilatorer och verktyg för Aarch64 är lika bra som de är för ARMv7, x86 och x86_64.

3. Att använda GPUn på servers ser ut att vara en riktigt intressant tanke och en bra idé i teorin. Men tittar man hur mycket det används i praktiken så inser man att i princip ingen använder detta utanför HPC (High Performance Computing) och även inom HPC används det mindre än man först trodde det skulle användas. Problem? Det är helt enkelt för komplicerat (==dyrt) att skapa GPGPU program idag då verktygen är för primitiva och de program som faktiskt finns blir i praktiken väldigt specifika för en viss GPU-familj. Kommer med största sannolikhet ändras med tiden, men svårt att säga hur lång tid det kommer ta.

Man får helt enkelt se hur detta går, förhoppningsvis lyckas AMD göra något bra av det hela![/QUOTE]

Du har nog inte läst artikeln (eller tittat på bilderna) så noga. Det är inte ARM-processorerna i sig som ska ge fördelar. Det är interconnecten från SeaMicro och erfarenheten från utveckling av Opteron-plattformar i kombination med ARM som ska ge fördelar gentemot Calxeda, Cavium, Marwell, FreeScale och Samsung som du nämner.

Om denna nya bransch som helhet kommer funka får vi ju se, men om den funkar så ligger nog AMD rätt bra till.

Ok, så det är alltså mer eller mindre en helt ny uppsättning instruktioner. Det låter ju lite klantigt men de kanske inte värderar bakåtkompatibilitet på samma sätt? Det är ju inte fullt så vanligt att man jonglerar runt mjukvara på ARM än så det mesta hade väl fått skrivas om ändå. Men det där med att utveckla kompilatorer låter som en rätt stor nackdel. Ska hur som helst bli intressant att se hur de presterar sen för kan de sparka upp prestandan ett steg eller två med out of order så kan de ju faktiskt bli relevanta för lite allt möjligt som kör många små laster.

Bara fick en kul tanke, och är inte ute efter att starta flamewar.
Dessutom köper jag nästan bara AMD-grejer, men när du nämnde kaffe-maskiner
och AMD så kunde jag inte låta bli att tänka:
Då kan de använda Bulldozer som värmeelement.

men ja...
Ska iaf bli kul att se vad som händer framöver.
Tror nämligen som jag skrivit tidigare i tråden att
detta kan vara bra för AMD.

Man var väl mer eller mindre tvingad att dumpa gamla instruktions-setet för att få någon prestanda när man ska försöka bygga server-chip. Iaf som jag förstått det. Idag är ARM ingen höjdare alls i en server-miljö. Klart den drar lite ström, men latency per req är också hög. Som webbserver tex är den inte speciellt bra alls. En Atom är så mycket bättre att strömförbrukningen blir ett icke-problem. Out of order ex är nånting ARM måste ha om den ska funka i servermiljö på nån skala.

Det AMD tar till partyt är ju Hyper Transport, Freedom Fabric et al. Något som ARM i stort sett helt saknar, något bra att kopplaihop kärnorna med varandra och resten. Köpet av Seamicro ser lite mer logiskt ut nu.

http://www.anandtech.com/show/6420/arms-cortex-a57-and-cortex...

ARM har släppt info om de kommande 64-bits CPU:erna. Antagligen detta som AMD kommer använda.

Om det hade varit fallet så hade jag förstått hur man skulle kunna fortsätta med väldigt enkla CPU-kärnor då Aarch64 verkar ha städa upp mycket gammalt skräp. Men detta är vad ARM skriver på sin hemsida om Cortex A50 som verkar bli den första ARM CPUn som stödjr Aarch64

Cortex-A50 series processors are excellent 32-bit processors with 64-bit capability. They deliver more performance for ARMv7 32-bit code in AARCH32 execution state, and offer support for 64-bit data and larger virtual addressing space in AARCH64 execution state.

The ARMv8 architecture allows clean interworking between 32b and 64b in AARCH64 state, enabling a step-by step migration to 64-bit, beginning with 64-bit operating systems running 32-bit ARMv7 applications, migrating to a mix of 32-bit applications and 64-bit applications running in the same system.

D.v.s. man har stöd för BÅDE Aarch32 och Aarch64, vilket inte är något större problem i de fall 64-bit är ett super-set av 32-bit. Men så är ju inte fallet för ARM, så blir det inte ganska komplicerat (i antal transistorer) att stödja två hyfsat olika instruktionsuppsättningar? De är ju så pass olika att de som jobbar med ARM på Linux hävdar att det inte är vettigt att låta Aarch32 och Aarch64 dela arkitekturspecifika delar vilket man gör får både 32-bit och 64-bit på alla andra CPU-arkitekturer som finns både som 32-bit och 64-bit, även x86 som, jämfört med PPC och MIPS, ändå skiljer en del mellan 32- och 64-bit.

Morkul, de kommer självklart vara bakåtkompatibla, ARM är komplexa chip. Mer så än MIPS och PowerPC.

ARM7TDMI som används i bilar, abs-system, inbyggda i diverse apparater osv är däremot inte binärkompatibel med 32-bitars ARMv7. Tror för den delen inte folk fattar att chippen inte är helt kompatibla och kräver mjukvarufixar när t ex Nvidia bara kör VFPv3-d16 i sina Tegra 3 och de måste kompileras för detta. De större 64-bitars chippen är byggda för att mata 4k monitorer med multimedia och 3D-grafik. I dagsläget är tom Cortex A9 större än Atoms in-orderkärna. Strömbesparingen bygger man in genom smarta funktioner, andra transistortyper och processer som förbrukar mindre. Genom design/konstruktion helt enkelt. En Apple A6X är större än en Ivy Bridge i din laptop. Vill du ha en liten 64-bitare ska du snarare kolla på MIPS. Redan en A9 har generell kärna, och två FPUer/SIMD i form av VFPv3 och NEON. Den stödjer massor, massor ARM-specifika instruktioner, instruktioner för flyttalsenheterna osv. Bra mycket kraftigare än 64-bit superscalar-designerna från 90-talet. Instruktionssidan använder man inte för att hålla nere storleken, chippen är ändå så komplexa idag, jag tror inte folk fattar att x86-64 alltså 64-bitars front-end och (x86) decoder sitter i Atom som är en helt kompatibel produkt med SSSE3 således rätt kraftig FPU där med, virtualiseringsextensions, och hyperthreading som är mindre än Cortex-A9 är med L2 cache.

Bra spår av brittiska ARM Ltd och AMD här. Kan tänka mig att serversystemen lär vara hybrider däremot. Hur som helst får de pengar oavsett om det är ett ARM eller x86-64-kort man sätter in. Deras tillverkningspartner GlobalFoundries tillverkar dessutom redan ARM-processorer bland annat åt de största spelarna i branschen så de har mycket kunskap att förlita sig på. Det betyder att det redan finnas (kommer finnas nya) kärnor anpassade för tillverkningsprocessen och det är inget de behöver ta på sig helt själv. Det AMD bidrag är ju SeaMicros IP när det gäller interconnect. Sådana som Calxeda har eget IP för detta. Out-of-order-kärnor har ARM Ltd redan med A15 idag självklart är deras 64-bitars det och så väl en in-ordervariant för "little" som ni kan se att de presenterat nu, Intel får det inte fören med Silvermont (2013) när det gäller Atom. AMD satsar nog snarare på Lågspännings Opterons i dagsläget. Möjligen att man får se någon Jaguar-baserad produkt i framtiden för servrar.

@hACmAn VIAs x86-processorer är en produkt av Centaur i Texas och består av 100 man som gör helt Intel-kompatibla processorer. De är små. Effektiva, men små resurser imponerande fast ingen hit på marknaden. Själv tycker jag det är chipset och grafik som tynger ner dem lite. Vias modem och ARM-processorer finns i den del low-end-produkter i Asien, men de är mindre än kinesiska firmor och andra Taiwanesiska du aldrig har hört talas om. VIA har bara en omsättning på ca 140 miljoner dollar trotts att de säljer USB 3-chip, Firewirechip, ljudchip osv till halva PC-industrin.

Visst, det må vara stenhård konkurrens på ARM-marknaden, men är inte ARM som serverplattform ett ganska eget koncept? Tror detta kan vara ett ganska smart drag, jag ser absolut en marknad för extremt strömsnåla, billiga servrar.

Då jag kör en konsollinstallation av Debian på min hemmaserver skulle jag faktiskt utan tvekan valt en sådan konfiguration själv, om det fanns något moderkort i ATX-formfaktor eller liknande, med integrerad ARM-propp, en bunte SATA-portar, som orkade skyffla data i gigabithastigheter över SMB på lanet. Mjukvarumässigt hade det inte inneburit någon större skillnad för mig, det hade bara blivit frågan om att köra en annan build av exakt samma OS. Som det ser ut nu har jag en gammal Athlon II X2 i lågenergiutförande, som ligger och puttrar i 800 MHz med ondemandgovernorn 99.99% av tiden, 0 i load. Total overkill alltså, och ett satans elslöseri egentligen. En ARM-propp hade räckt gott.

Det här kan nog faktiskt bli något. Väl valt tillfälle att sparka igång en riktig-dator-baserad-på-ARM-marknad också i och med släppet av Windows RT, det kan säkert bli en extra katalysator.

Det är ointressant när arkitekturen och implementationer ändå är så komplex idag. ARM Ltds applikationsprocessorer är inte små. Att spara ström handlar inte om att bygga enkla chip. I x86 sitter en front-end och decoder, det är bara de som snackar x86-instruktioner. T ex brukar man säga att AMD K5 delade FPU med deras äldre RISC-serie Am29000 och att hela processorn var en anpassning av 29k som översatte x86 till Am29k-liknande instruktioner. Närmast CISC idag kommer du på IBMs stordatorer. Det finns generellt sett ingen skillnad på exekveringsenheterna eller mängden instruktioner du klarar utifrån ISA idag. Det är som sagt en lite icke diskussion idag när t ex Cortex A9 med cache är större än Atom, A9 har två FPUer VFPv3 kompatibla och SIMD NEON-kompatibla. De stödjer en stor mängd instruktioner och funktioner och är moderna out of order superscalar, branchpredicting kärnor. Själv förstår jag inte riktig fokusen kring den generella heltalsprocessorn och dess ISA, det är inte den som kommer användas av tyngre laster. 32-bit vs 64-bit förstår jag bättre. Tegra 2 visar på hur pass viktig FPUerna i ARMs processorer är. Det är inte direkt så begränsningarna idag sitter i vad x86 eller din generella ISA stödjer, det är bara en liten del av allt en processor pratar. Prestandan begränsas inte av ISA, funktioner (som kan hjälpa prestandan) kan läggas till så de motsvarar varandra/konkurrenten och oftast har det ingenting med de vanliga processor-registrena att göra.

RISC var populärt för att det kommer från universitetsvärlden/forskning. Itanium är t ex EPIC/VLIW. Det är däremot en arkitektur som snarare används i DSPer och grafikkort idag. ISA är ointressant, verktyg för att stödja processorerna os, mjukvara, kompilatorer och köret är däremot mer intressant än någonsin. ARM råkar ha mycket bra stöd där. Intel tillverkade förut ARM-processorer för smartphones men förlitar sig idag på sitt ekosystem kring x86. Det blir mindre miljöer för de att stödja. De drar fördelar och åker snålskjuts av resten istället. När en x86-processor kan med hjälp av en god arkitektur spöa Itanium eller RISC-konkurrenter har de ingen anledning att igen försöka bygga olika sorters processorer. Front-end/decoder är ändå så pass liten del av processorer idag. Dessutom stödjer de idag alla enterprise och RAS-funktioner som virtualisering osv. Det var förr sådant som bara fanns i tyngre RISC-system eller stordatorer. Fördelarna har aldrig varit ISA. Ett ISA (de delar som är obligatoriska) innefattar sällan alla funktioner/instruktioner som en plattform/arkitektur stödjer. Ett ekosystem/plattform kring ISA hjälper dock till.

Företag tenderar inte vilja ha flera olika system att underhålla och utveckla och brukar ersätta dessa med det nya istället, som idag råkar vara ARM. ARM var mycket enklare från början och det är ju positivt i den meningen att det kräver mindre resurser att utveckla, är enklare att förstå osv. Därför kunde de få kunder, partners osv. Fast idag handlar det inte om enkla chip. De är mer avancerade än de IBM använde i superdatorer för några år sedan.

Håller med om det mesta, men det FINNS saker i ISA som kan ha en rätt stor påverkan på prestanda. En sådan sak är hur atomära operationer är implementerade, något som blir VÄLDIGT viktigt så fort man har flera CPU-kärnor. RISC (inklusive ARM) använder sig av samma typ av struktur

  retry:
  load-linked <någon adress>, <reg>
  utför din operation på <reg>
  store-condition <addressen från load-linked>, <reg>
  om det gick dåligt, försök igen genom att hoppa till 'retry'

x86 är inte lika flexibel då den operation man utför måste vara exakt en x86 assembler instruktion, men det är faktiskt en FÖRDEL i de flesta fall då det är mycket enklare att optimera fallet

  lock xadd <någon address>, #1

jämfört med

  load-linked <någon adress>, <reg>
  addi <reg>, <reg>, #1
  store-condition <addressen från load-linked>, <reg>

då man VET att x86 instruktionen kommer utföra en read-modify-write cykel så fort man avkodat instruktionen medan man måste tolka allt från load-linked till store conditional i RISC. Resultatet är lätt att se, då 86 i genomsnitt är klart snabbare på denna typ av instruktioner jämfört med RISC.

En annan sak som också är VÄLDIGT viktig just för multicore är hur skrivningar och läsningar kan "gå om lott". Detta har inte med RISC vs CISC att göra utan har i stället att göra med s.k. memory consistency model. Även här har x86, tillsammans med SPARC, valt en metod som är något mer komplicerad att implementera men ger MYCKET bättre prestanda och skalbarhet i vissa lägen när man har flera CPU-kärnor som måste samordna arbete.

Men precis som du skriver så spelar ISA väldigt liten roll i praktiken, något bl.a. Intel och Motorola visat då Motorolas Android telefon Razr I (single core Atom @ 2.0GHz) har bättre enkeltrådprestanda och bättre batteritid än Razr M (dual core Krait @ 1.5GHz).

Efter att läst på lite mer om det artikeln handlar om så verkar det rätt mycket som detta är ett provskott från AMD då de kommer ha både ARM och x86 baserade Opteron CPU:er i low-power segmentet (man tänker tydligen använda Opteron namnet även för ARM).
En sak som jag är lite skeptiskt till vad det gäller ARM i detta fall är lite det jag skrev ovan, man siktar på att skapa servers många svaga CPU-kärnor då det drar lite ström. Problemet är att ARM är en sämre design än x86 för saker som inte är Embarrassingly parallel, så det känns som användningsområdet för dessa servers blir väldigt smalt. Och frågan är vad fördelen är med många ARM-kärnor jämfört med många simpla x86 kärnor. I det allmänna fallet är fördelen med ARM uppenbart, man kan inte få en x86-licens om Intel inte vill. Men det är ju inte ett problem för AMD...

virtual void

Självklart finns det skillnader, även på enklare generella saker. Det är dock ingen begränsning i säg, är det något du inte kan sköta i mjukvara med existerande instruktioner lägger man till ett antal för att hantera detta oavsett vad de har valt för ISA. Man kan också ge tillgång till hårdvara man integrerar på andra sett. Utan att beröra ISA-frågan. Man ska inte överdriva betydelsen. Funktioner man förknippar med en viss arkitektur är ofta implementationer och extensions snarare än någon som följer ISA. Dessa är bara intressanta som konkurrensfördel så länge konkurrenten inte kan göra motsvarande.

ARM ger de en möjlighet att integerera SeaMicros interconnect. Det kommer de inte göra på x86. Tänker vi stället Nvidia så även om de hade fortsatt tillverka x86 (de köpte ULi, därav en 386SX för inbyggnad) så hade de inte haft några produkter inom segmentet att sälja om de inte hade licensierat ARM. De hade inte haft någon x86-kärna att tävla med oavsett hur det sett ut på licenssidan. Intel är en stor licensierare av Nvidias teknik/patent. Centuar/VIA fick behålla och förnya sin pga Centaurs patent som Intel behöver använda. Det har dock varit slagsmål om detta med både VIA och AMD, de har inte x86-rättigheter per default. I princip hade Centaur idag kunnat designa och tillverka processorer hos IBM utan problem, och märka dessa IBM med IBM-teknik inbyggt. TSMC har aldrig haft några problem för att de tillverkar x86. GF har knappast något speciellt förhållande med Intel. IBM tycker det är roligare att tillverka och sälja annat dock. Designar man annat så kan man driva utvecklingen själv på ett annat sett.

Troligen kommer man mest producera bakåtkompatibla CPU:er i början, då det troligen är väldigt dålig marginal på såna. Men vem vet, de kanske får till det, folk betalar, så har vi fullständigt schizofrena ARM-CPU:Er för en lång tid framöver

Man förlorar ganska mycket på att behöva köra varenda bibliotek, verktyg och tillämpning i 64-bitar. Det är fortfarande vanligt att blanda även i operativsystemen. Bara för att majoriteten av programvarorna är kompilerade för 64-bitar så betyder det inte att det är en fördel att bli av med 32-bitars program. De kan ju för den delen vara snabbare, det kan också vara så att det inte finns någon 64-bitars motsvarighet till en hel del. Kan dock vara så att de inte stödjer några 32-bitars operativsystem. 64-bitars servermjukvara som redan rullar på massor system men som inte längre underhålls som 32-bitars blir såklart enklare att portera. I ISA:n ingår ju både 32-bitars och 64-bitar läge. Där handlar det inte om något som är frivilligt (optional). Är den ARMv8-kompatibel så är den nästan säkert 32-bitarskompatibel. Mobiler är nog bland de första att få 64-bitars operativsystem bland kommersiella system. Chromebook var ju t ex den första att få A15 som har LPAE och virtualiseringsstöd. Nog för att ARMv8-kärnor från bolag som inte bygger SoC:s med ARM Ltds IP lär vara före denna gången. De har hur som helst ingen anledning att spara in på registrena. Är chippen ARMv8-kompatibla kommer de innehålla bakåtkompatibilitet iaf. Måste nästan vara du som frågat konstigt.

32-bitars operativsystem som Android behöver däremot inte finnas porterat för sådant som inte ska finnas i CE-området. Det har mer att göra med saker som bootloader, drivrutioner osv däremot. SeaMicro interconnect lär inte stödjas av Android precis.

Hur som helst så får vi nog rätt snart under 2014 se surfplattor med 4GB+ minne och 64-bitars kernel. Tyngre applikationer kommer vilja rulla där med.

NDK kan redan bygga för flera arkitekturer (x86, MIPS) så det är inga problem för applikation-utvecklarna heller, de kommer få 64-bitars APIer, kompilatorstöd och de kommer kunna bygga för 32-bitar och 64-bitar samtidigt med ett uppdaterat SDK. Speciellt native-kod. Det kommer inte vara mycket mer än en rad i byggfilen du lägger till eller för den delen ändrar till "all" och bygga för alla tre (eller fyra, två ARM ABIs) med SDK:t är inga problem och genererar en APK som innehåller stöd för alla plattformarna. Så det fungerar med utvecklingsverktygen idag. Nu kommer dock processorerna som kommer finnas att köra 32-bitars kod med full kompatibilitet och 32-bitar OS också. Det är ju en feature hos ARMv8-A att ha den valmöjligheten. Nytt ABI kommer inte vara så stor grej för de flesta projekt, förmodligen inte ens om vi går till 64-bit. Portabel kod och kod som redan rullar på 64-bit på desktop/server lär inte har så stora problem.

Många program använder binära bibliotek tillsammans med Java, eller är i huvudsak C/C++ program som antingen kan vara rena sådana eller kombineras med Java för gränssnitt/presentation. Har man en portabel kodbas man delar mellan olika plattformar så kommer din viktigaste logik inte vara Java eller köras i VM. Med bakåtkompatibilitet spelar det inte så stor roll om den lyckas bygga för 64-bitar eller inte däremot. Är det kod som också körs på OS X, Windows 8/WinRT, Windows mot Win32, GNU/Linux, osv lär koden för eller senare anpassas för 64-bitarsstöd. Finns ingen spridd processor/arkitektur (64-bitar sådan) där du inte kan köra 32-bitars dock. T o m Itanium som byggdes som ren 64-bitare kan kompilera 32-bitars kod (HP-UX) i 32-bitars-läge utan att man behöver ändra pekare osv. Med emulering i värsta fall för binärer för andra arkitekturer. Så aldrig något större problem att få igång grejer.

Android har för övrigt ingen JVM, de har Dalvik VM med JIT och ett språk deriverat från Java SE 1.5 och egna apier. De har ingen Java-bytecode utan de kompileras till DEX av SDK/verktyg. Hur som helst så hanterar Android redan flera arkitekturer finare än Microsoft. Inte bara kan du skeppa och bygga för alla plattformar med en APK, du kan också göra det när det gäller Native. Inte bara sånt som körs i en virtuell maskin som CLR eller Dalvik. Ska du skeppa 64-bitars native app och 32-bitars till Windows är det inte bara en separat PE EXE, DLL osv utan också separata installationspaket oftast, då har vi inte heller räknat in Itanium som måste levereras separat, byggas separat. Du har heller inte räknat in nya Windows Runtime för Metroappar i C/C++ där du måste välja om det ska rulla på Windows RT också eller inte, i de fallen levereras det över programbutiken i vilket fall som helst däremot. Apple kör med feta binärer som innehåller versioner för olika arkitekturer/bitar i samma fil/binär. Dalvik finns hur som helt till ARM, MIPS och x86. 32-bitars i dagsläget. Utöver det så översätter Android för x86 NDK-program (native) för ARM till x86, vilket fungerar för de flesta programmen, för de som inte uppdaterat SDK och byggt programmen för Intel.

I princip vore det helt unikt med en plattform som inte kan bygga eller köra 32-bitars program. Kommer garanterat inte hända bland CE.

Det är precis också vad jag tror efter att ha läst alla pressreleaser osv. Känns logiskt.