X86-instruktionssæt er måske mindre strømslugende end deres rygte

Faktisk siger testen meget lidt om det indbyrdes strømforbrug, for det er ikke instruktionssættet, der er afgørende for, at ARM er kendt for lavere strømforbrug. Det er et helhedsdesign med vægt på strømbesparelse.

Det betyder selvfølgelig, at Intel sagtens kan lave en lige så strømsparende processor ved samme slags helhedsdesign. Men om dette er tilfældet siger testen intet.

Det er generelt svært at sammenligne strømforbrug for en CPU alene, da meget afhænger af det samlede system -- ikke bare cache og hukommelsescontroller, men også RAM, bus og i/o. Men man kan prøve at gøre de samlede systemer så ens som muligt på tværs af processorer. Men selv her er der fælder: Generelt koster performance strøm, så man skal sikre sig, at systemerne er tunet, så de to systemer bruger præcis den samme tid på de opgaver, de skal udføre i benchmarket. Og dette uden at det ene system kører væsentligt hurtigere eller langsommere end "normale" konfigurationer.

En afgørende faktor for strømforbrug er graden af integration: Hvis flere funktioner sidder på samme chip, bruger man mindre strøm, end hvis de er fordelt på flere forskellige chips. Så hvis man vil mindske strømforbruget, skal man lede efter en chip, der har flest muligt af de funktioner, man ønsker, integreret i en chip. Og her har ARM en stor fordel: Der findes fra forskellige firmaer et meget stort udvalg af systems-on-chip (SoC) med forskellige funktioner, hvor Intel kun laver et forholdsvist begrænset antal ditto. Så chancen for at du kan reducere antallet af chips er større med ARM end med Intel. Det kan Intel også gøre noget ved ved at udbyde et større udvalg, men det er svært som enkeltfirma af konkurrere på udvalg med de mange firmaer, der laver ARM SoC'er.

Det betyder selvfølgelig, at Intel sagtens kan lave en lige så strømsparende processor ved samme slags helhedsdesign.

Min første tanke var at journalisten burde have undersøgt om Intel havde sponseret dette forskning, det lugter langt væk af profylaktisk spin...

Og nej Torben, Intel kan ikke "sagtens" match ARMs strømforbrug, hvis de kunne havde der helt sikkert også været x86 tablets og smartphones på markedet.

AMD gjorde et stort og kompetent stykke arbejde med at rydde op da de definerede den 64bit x86 arkitektur som Intel nægtede at lave af hensyn til Itanic.

Men i bagudkompabilitetens hellige navn shipper alle x86 CPUer den dag i dag både 32 og 64-bits ISAer, hvilket i sig selv koster areal og effekt.

Men selv hvis man kastede 32bit ISA overbord ville man stadig være bagud i forhold til ARM's 64bit, fordi visse dele af arkitekturen er baseret på 40 år gamle og ofte dårlige ideer.

F.eks er hele den gumpetunge 'descriptor' baserede memory management fra iAPX432 og segmentregisterhacket fra 80286 en tung vægt om benet på x86.

Intel er godt klar over hvor det bærer hen og heldigvis for dem er ARM et langt mere anstændigt firma end de nogensinde selv har været, så de blev ikke ramt med dummebøder da de begyndte at fab'e ARM cores for Altera i 2013.

Men i bagudkompabilitetens hellige navn shipper alle x86 CPUer den dag i dag både 32 og 64-bits ISAer, hvilket i sig selv koster areal og effekt.

ARM bærer efterhånden også rundt på et større antal forskellige instruktionssæt af hensyn til bagudkompatibilitet: Det (næsten) oprindelige 32-bit instruktionssæt, Thumb, Thumb2 og ARM64 er alle understøttet af den seneste generation. De er dog alle enklere end både x86 og x64, og Thumb er "blot" et afkodningslag før den almindelige ARM32 pipeline, og du har nok ret i, at arven fra iAPX432 koster. Men det er alligevel nok manglen på højt integrerede SOC'er, der koster mest.

Men det er alligevel nok manglen på højt integrerede SOC'er

Dem laver Intel da masser af ?

Problemet er at de har en tendens til at kaste alt+køkkenvasken i deres SOC'er, hvad enten kunderne skal bruge det eller ej.

Intels største problem er stadig "Marcitecture"

x86-64 er, set i forhold til ARM, et ultragrimt design med masser af klodser om benet. Men de fleste CPUer med x86-64 som instruktionssæt oversætter det jo tidligt til "mikro-ops" der til forveksling er tættere på dem ARM har. Og så kører de internt som en RISC-lignende CPU. Hvis du samtidig har en out-of-order arkitektur, så burde det ikke have det alt for store omkostning at dekode x86-64.

Det er vel også det der er argumentet i artiklen. ISA betyder forholdsvist lidt i forhold til strømforbrug. Man kunne jo tænke sig at man kunne disable de enheder i CPUen der ikke er i brug, hvilket Intel har gjort siden deres Pentium-M arkitektur SVJV.

Jeg er måske mere interesseret i et helt andet spørgsmål: Hvor meget regnekraft har man brug for i en laptop eller telefon? Min telefon har 64bit, 4+2 cores der kører 1.2Ghz, en temmeligt kraftig GPU, chips specialdesignet til videodekodning og så videre. Har jeg egentlig brug for meget mere kraft? Den svarer velsagtens til en state-of-the-art laptop fra 2010 eller lignende. Så er en kraftig Intel-CPU med høj peak-performance egentlig det rigtige chipdesign, hvis jeg med en simplere CPU kan køre med lavere strømforbrug?

Jeg spår at det der betyder noget er performance i forhold til strøm. Og dernæst naturligvis pris. Og i det spil er det ikke givet at du skal lave den største og hurtigste CPU, hvis prisen for hastigheden er en masse strøm brugt. En simplere arkitektur ved lavere klokfrekvens kan måske godt vinde på kurven, bare den kan spare nok strøm. Specielt hvis det følges af programmel der er mere effektivt også.

Jeg er måske mere interesseret i et helt andet spørgsmål: Hvor meget regnekraft har man brug for i en laptop eller telefon? Min telefon har 64bit, 4+2 cores der kører 1.2Ghz, en temmeligt kraftig GPU, chips specialdesignet til videodekodning og så videre. Har jeg egentlig brug for meget mere kraft? Den svarer velsagtens til en state-of-the-art laptop fra 2010 eller lignende. Så er en kraftig Intel-CPU med høj peak-performance egentlig det rigtige chipdesign, hvis jeg med en simplere CPU kan køre med lavere strømforbrug?

Software er årsagen til at x86 arkitekturen stadig er altdominerende på PC markedet. Der laves stadig et hav af gammeldags windows programmer som ikke kan køre på andet end en konventionel windows PC. Microsoft har jo forsøgt at sælge ARM baserede windows tablets, men med meget begrænset held.

Min telefon har 64bit, 4+2 cores der kører 1.2Ghz

Den clockfrekvens bruger dine 6 cores kun ved helt særlige festlige lejligheder og dit batteri får ret hurtigt krydsøjne hvis det fortsætter mere end nogle få sekunder.

ARM bærer efterhånden også rundt på et større antal forskellige instruktionssæt af hensyn til bagudkompatibilitet: Det (næsten) oprindelige 32-bit instruktionssæt, Thumb, Thumb2 og ARM64 er alle understøttet af den seneste generation. De er dog alle enklere end både x86 og x64, og Thumb er "blot" et afkodningslag før den almindelige ARM32 pipeline, og du har nok ret i, at arven fra iAPX432 koster. Men det er alligevel nok manglen på højt integrerede SOC'er, der koster mest.

Men hvordan ser det så rent faktisk ud med POWER arkitekturen, sammenlignet med ARM og x86-64 (amd64 som jeg helst kalder den)? Og er det ikke sådan at CPU strømforbruget er en ting, men at der i enheden en computer sluges strøm så mange andre steder? PSU spilder strøm, andre chips i chipsættet spilder strøm osv. Så der må også ligge en faktor i hvor meget computation der kan presses ind i en chip, kontra mange chips, eller computere? Det vil være mere interessant at se på en Intel 20 core Xeon, og dens computational power i en computer og måle dens strømforbrug, og så se på en ARM opbygning med samme computational power (hvordan den så skal bygges?), og til sidst en POWER, og så se på deres respektive strømforbrug. Det giver ikke meget mening at tale om hvor meget benzin en motor bruger, hvis man ikke ved hvilken bil den er placeret i, vejer den 1.500 kg, eller 3.000 kg. Har den larvefødder eller 4x4 eller ...., hvordan er vindmodstanden osv.

Men hvordan ser det så rent faktisk ud med POWER arkitekturen, sammenlignet med ARM og x86-64 (amd64 som jeg helst kalder den)?

Jeg har ikke fulgt med i POWER, så jeg kender ikke detaljer. Men POWER er p.t. næsten udelukkende rettet mod serverbrug, så jeg tror ikke, at den er sammenlignelig med SoC'er fra ARM og Intel.

Med hensyn til strømforbrug, så afhænger den af mange ting: Antal gates, der er aktive, lækstrøm, hvor hurtigt gates skifter (her er afhængigheden kvadratisk), størrelsen af gates og diverse finurligheder såsom brug af charge recovery logic, adiabatiske signaler, Bennett-clocking, asynkrone kredsløb osv.

Specielt den kvadratiske afhængighed af frekvensen er interessant: Det er billigere (i strøm) at have to processorer på hver N GHz end en processor på 2N GHz. Det er bl.a. derfor, at grafikprocessorer har mange regneelementer men en (i forhold til CPUen) en lav clockfrekvens. Og det er også årsagen til, at fokus i CPU-design i de sidste 10 år er gået fra at øge clockfrekvensen til at øge antallet af kerner. Endvidere er der fokus på at neddrosle frekvensen, når der ikke er behov for så meget strøm, og på at frakoble enheder, der ikke er i brug.

Software er årsagen til at x86 arkitekturen stadig er altdominerende på PC markedet

Performance er årsagen til at x86 arkitekturen er altdominerende på PC og server markedet.

x86 har en del baggage, der kræver en avanceret mikroarkitektur at råde bod på: 1. Variabel instruktionslængde 2. To-adresse instruktionsformat 3. Begrænset antal registre. 4. Opdatering af flag af (stort set) alle instruktioner. 5. Strong memory ordering model (dansk ?)

Derudover er der en række hjerneblødninger, der er deprecated i praksis; Call gates, segmenter etc.

Intel har to arkitekturfamilier: Core og Atom. Core har features til at afhjælpe alle ovenstående problemer, Atom har kun features til at afhjælpe punkterne 2), 3) og 4).

De ting der skal til at afhjælpe problemerne er ikke spildt specifikt for x86. Det er egenskaber, der markant øger ydelse for alle arkitekturer. Som eksempel har Apple's nye A9 CPU kerne et meget stort instruktionsvindue til OOOe, ligesom det har spekulativ hukommelsesadgang (som Intel's Core arkitetektur).

Og nej Torben, Intel kan ikke "sagtens" match ARMs strømforbrug, hvis de kunne havde der helt sikkert også været x86 tablets og smartphones på markedet.

Der findes skam masser af x86 tablets - og enkelte telefoner..

Jeg har hørt det postuleret (og demonstreret i eksotiske benchmarks) at x86's uhumske CISC-ISA nutildags kan være en fordel, fordi det i praksis udgør en Huffman-indkodning af instruktionssættet, således at de mest hyppigt anvendte instruktioner tager mindre plads. Hypotesen er, at programkode derfor fylder mindre, hvilket gør det hurtigere at hente fra lageret, og fylder mindre i cache.

Førstnævnte betyder nok ikke så meget, men sidstnævnte kan godt have en effekt: Det flytter pejlemærket ved hvornår noget er et "tight loop" eller ej. En grund til at betvivle hypotensen er dog, at moderne højtydende løkke-kode typisk gør god brug af vektoriserede instruktioner, og ingen af x86's mange vektor-instruktioner, fra de forskellige SSE-generationer, er specielt kortfattede. At ARM valgte at nitte både Thumb og Thumb2 på deres design synes dog at indikere, at hypotesen ikke kan være helt ved siden af.

Jeg har ikke fulgt med i POWER, så jeg kender ikke detaljer. Men POWER er p.t. næsten udelukkende rettet mod serverbrug, så jeg tror ikke, at den er sammenlignelig med SoC'er fra ARM og Intel.

Korrekt - POWER kan slå Intel's Xeon-processor på visse meget parallelle beregningsopgaver, men de bruger langt mere strøm.

Jeg har ikke fulgt med i POWER, så jeg kender ikke detaljer. Men POWER er p.t. næsten udelukkende rettet mod serverbrug, så jeg tror ikke, at den er sammenlignelig med SoC'er fra ARM og Intel.

Jeg tror også at SoC POWER er en døende race, selvom der er en del. Men det er vel også interessant at se på server strømforbruget, der er alligevel en del servere installeret på verdensplan. Systemer som Linux og BSD kan alle afvikles på både ARM, x86-64 og POWER, og er vel i dag de mest udbredte platforme, hvis vi ser på servere, tablets, smartphones, PC'ere, biler, fly osv.?

POWER var i last-gen spil konsollerne Xbox 360, PS3 og Wii, og i current-gen Wii U.

Jeg tænker også at her i virtualiseringstiden, må POWER have nogle fordele, med sin mere eller mindre indbyggede hypervisor.

Og nej Torben, Intel kan ikke "sagtens" match ARMs strømforbrug, hvis de kunne havde der helt sikkert også været x86 tablets og smartphones på markedet.

Tablets: http://www.pcmag.com/article2/0,2817,2417564,00.asp

Smartphone: https://www.asus.com/Phone/ZenFone_2_ZE551ML/

Men hvordan ser det så rent faktisk ud med POWER arkitekturen, sammenlignet med ARM og x86-64 (amd64 som jeg helst kalder den)?

Current POWER processor er POWER8, som kan have op til 12 'fede' cores, hver med op til 8 vejs SMT, og kan klokkes op til 5GHz. IBM har sådan dryppet processorer med flere og flere cores sådan hen ad vejen, og den fuldt udviklede processor kom vist i april sidste år. Indtil da har man typisk haft keramiske moduler med f.eks. 2 stk 3-6 core processorer, som man så pluggede ned i en socket. POWER8 har været 'i butikkerne' i to år nu, og er ved at være lidt træt. Der skulle kommen en POWER8+, her i år (hvor ikke + og + er lidt det samme som Intels Tick Tock). Men traditionelt fokus for POWER (glem lige PowerPC i den her sammenhæng) har altid været servers, og især highend og midrange. Så derfor er der temmelig meget Lastbil over POWER. Så den er egentlig ikke rigtig designet til at 'holde stille', men at blive brugt 100+%, eller ikke blive brugt. Og det afspejler sig også i strøm forbruget, men også i de strøm besparelses teknikker som bruges. Det er ikke sådan targeted mod.. 'Hva så hvis vi kun har 5% load', for så vil man jo flytte virtuelle maskiner væk fra den fysiske maskine og lukke den ned, eller måske lukke dele af maskinen ned.

Fokus på udviklingen de sidste 10 år har været på bla. SMT, som man/serverne selv kan lave om på, som man vil on the fly. Så har det været Virtualizerings understøttelse, Linux enablement og sidst acceleratorer. Altså ting som Transactional memory, Decimal floating point, Vector instruktion, compression, encryption i hardware. POWER8 understøtter både Big og Little endianess med adskillelse på per core nivau, så vidt jeg husker, så de nyeste version af Linux til POWER er så Little endian, så man slipper for at skulle 'kode mere ordentligt', for at kunne portere koden mellem f.eks. Suse på POWER og Suse på x86.

Jeg tænker også at her i virtualiseringstiden, må POWER have nogle fordele, med sin mere eller mindre indbyggede hypervisor.

Ja, nu kan man også få en PowerKVM, men jeg vil da klart foretrække PowerVM, som er en firmware baseret hypervisor. Jeg har set maskiner køre fint med 100+ virtuelle maskiner, hvor størrelsen på de virtuelle maskiner varierede fra 4 til 100+ logiske cores. Og generelt så kører midrange og highend POWER maskiner generelt med 60-80 average load.

Men ja.. hva f*nden kan man så bruge sådan en POWER server til. Personlig så mener jeg at hvis du har IBM software så er det en nobrainer, at man bør smække noget virtualizering og en RHEL eller Suse på en POWER server og flytte sit IBM software derover. Det er f.eks. hvad jeg råder folk til internt hvor jeg arbejder :)

// Jesper

Men ja.. hva f*nden kan man så bruge sådan en POWER server til. Personlig så mener jeg at hvis du har IBM software så er det en nobrainer, at man bør smække noget virtualizering og en RHEL eller Suse på en POWER server og flytte sit IBM software derover. Det er f.eks. hvad jeg råder folk til internt hvor jeg arbejder :)

Jeg tænker at JVM kører fint på sådan en fætter (J9 er vel i en udgave til POWER?), og dermed er Hadoop og andre Big Data teknologier (Elastic Search osv.) vel oplagte? Application Servers er vel et andet emne, dvs. et microservices miljø. Man kan sige at Containers, som lige nu er hot topic, vel er en oplagt teknologi til POWER, eller hur?

ARM bærer efterhånden også rundt på et større antal forskellige instruktionssæt af hensyn til bagudkompatibilitet: Det (næsten) oprindelige 32-bit instruktionssæt, Thumb, Thumb2 og ARM64 er alle understøttet af den seneste generation. De er dog alle enklere end både x86 og x64, og Thumb er "blot" et afkodningslag før den almindelige ARM32 pipeline, og du har nok ret i, at arven fra iAPX432 koster. Men det er alligevel nok manglen på højt integrerede SOC'er, der koster mest.

Der tager du faktisk fejl, Torben—i hvert fald med den nyeste version af ARM-specifikationen, ARMv8 (både AArch32 og AArch64). Heri er der fjernet en masse features, herunder:

• Den oprindelige Thumb-model, som er reduceret til en alternativ instruction encoding-form i 32-bit mode, som understøtter et subset af Thumbv2.
• Jazelle (JVM-acceleration)
• Load/store multiple (instruktionsfamilierne LDM og STM)
• En hel masse conditional instruktioner og instruktionannotationer
• Ældre FP-instruktionsvarianter, herunder VFPv2. NEON (svarer til SSE/AVX) og VFPv3+4 er dog bevaret (tilsvarende x87 på speed).

Mange af disse features har kun haft relevans i specialiserede områder, og jeg har til dato ikke endnu set en compiler til ARMv7 og 8 emitte LDM/STM, VFPv2 eller Thumb-instruktioner, så deres fjernelse er fuldt ud på sin plads. Så faktisk er der en ret solid oprydningsproces i gang i arkitekturen.

Dog ignorerer denne her artikel fuldstændig virkeligheden under instruktionssættene. Intel-CPU'er er jo ikke CISC-CPU'er (i traditionel forstand), da de operationer, der afvikles på hardware anvender et helt separat (og udokumenteret) instruktionssæt, der i øvrigt varierer fra CPU-generation til generation.

CPU-frontenden har en dynamisk translator, som oversætter de oldschool komplekse instruktioner til mikrooperationer, som er dem, der skeduleres og afvikles "på metallet". En kompleks x86-instruktion (én af dem der henter, adderer, shifter aritmetisk, gemmer i memory og ringer med en klokke og kommer med kaffe til dig) dekomponeres til en serie af mindre komplekse instruktioner. Jeg er ikke sikker på, jeg ville kalde paradigmet RISC, da både Intel og AMD er begyndt at lege med µ-op fusion, som kobler ikke-interdependent instruktioner sammen til mere komplekse instruktioner (men dette er ikke just traditionel CISC, og heller ikke helt VLIW).

Intel's første processor med dette approach var Pentium Pro, som nok er den mest RISC-agtige af Intel's x86-processorer, idet mikro-operationerne decideret mindede om en "traditionel" RISC-arkitektur som MIPS.

Nu om dage minder den µops-baserede approach en hel del mere om Transmeta's eventyr i slut-90'erne og start-00'erne (med Crusoe og Efficeon): en x86-frontend, der dynamisk oversatte til en "hemmelig" VLIW-arkitektur. Transmeta imponerede netop med lavt strømforbrug i forhold til performance; at performancen så aldrig rigtig blev helt imponerende, betød så bare at strømforbruget var -rigtig- lavt for den generations fabrikationsprocesser og teknologier.

Jeg tænker at JVM kører fint på sådan en fætter (J9 er vel i en udgave til POWER?), og dermed er Hadoop og andre Big Data teknologier (Elastic Search osv.) vel oplagte? Application Servers er vel et andet emne, dvs. et microservices miljø. Man kan sige at Containers, som lige nu er hot topic, vel er en oplagt teknologi til POWER, eller hur?

Nu er det et par år siden jeg stoppede hos IBM, og er ikke lige fuldt opdateret. Men så vidt jeg husker er nogle af deres 'Big Data' appliances basseret på netop Linux på POWER. Og det giver jo god mening for dem. Rent performance mæssigt har POWER altid sparket r*v, og har en fin balance mellem 'throughput' på System, Processor, Core og Thread niveau. Og igen så kan man 'on the fly' justere antallet af Tråde så det passer til ens workload.

Desuden så er der mange af acceleratorerne, der giver god feks. java 'performance', det kræver så som regel at du bruger en 'IBM Java'. Og hvis du bruger IBM's egne Big Data (og andre) Produkter så er der selvfølgelig support. F.eks. så rykker DB2 Blu ret godt på en POWER platform, hvor den kan udnytte, stor memory kapacitet, høj memory båndbredde, hardware support for Vectorer, Compression, Decimal Floating points og transactional memory m.m.

MHT. Containers, så ja.. så er det jo ikke noget nyt i *NIX verdenen. BSD (PHK er jo eksperten der), Solaris og AIX har i mange år haft container teknologi. Og ja.. det virker jo bare på de platforme. Men f.eks. sådan noget som Docker er der vist ikke lige endnu på f.eks. Linux på POWER.

Men der hvor POWER især giver mening er hvis du kører IBM software. PVU (processor value Units) countet for en IFL (Integrated Facility for Linux) på en POWER server er en flad 70, uanset server størrelse. Og core throughput er altså bedre for en 2014 POWER8 processor med 12 cores end den er for en brand new spanking Xeon, selv hvis du tager den nyeste Intel Xeon E5-2637 v3 @ 3.50GHz. Desuden så skal du betale 100 PVU når du går til 4 sockets og 120 når du går til 4+ sockets for en Xeon server.

Man kan så sige at ja.. en POWER server koster kassen. Men der er altså Linux Only versioner, der giver good value for Money. Du kan altså få f.eks. en S822LC med KVM, SLES 20 cores @2.92GHz og 1 TB RAM for cirka 1.5 gange det som en mærkevare x86 med to E5-2660'ere og 768GB RAM koster.

Og POWER boksen er så cirka 40% hurtigere ved samme core Count. Personlig ville jeg foretrække en S822L med 16 POWER8 cores @4.1 GHz, med SLES og POWERVM, hvis man kan nøjes med 512 GB RAM. Den er tæt på at have samme kapacitet som en Xeon server med 2 stk. E5-2699, men har x2+ i per core throughput.

Så igen, hvis du skal køre noget WebSphere .. eller DB2 så kan du altså spare rigtig mange penge.

Og ja jeg laver bla. TCO analyser i mit arbejde :)

// Jesper

At ARM valgte at nitte både Thumb og Thumb2 på deres design synes dog at indikere, at hypotesen ikke kan være helt ved siden af.

Thumb-instruktionssættet var/er primært rettet mod små indlejrede processorer, der har lille databus (mindre end 32 bit) og lille cache. Her har kodedensitet en del at sige. Med store databusser og store instruktionscaches betyder det nok mindre.

ARM bærer efterhånden også rundt på et større antal forskellige instruktionssæt af hensyn til bagudkompatibilitet: Det (næsten) oprindelige 32-bit instruktionssæt, Thumb, Thumb2 og ARM64 er alle understøttet af den seneste generation.

Det er dog langt fra alle sammen der er obligatoriske. F.eks. var NEON ikke obligatorisk i ARMv7 (Tegra2 implementerede det ikke), og 32-bit (Aarch32) ser heller ikke ud til at være obligatorisk for ARMv8 [1].

[1] [PATCH v3 0/7] arm64: Support for systems without AArch32 state