Microsoft demonstrerar Windows 8 för ARM

Dels så tog jag med en länk som visar resultat från t.ex. Sun Spider och CaffineMark när alla plattformar kör Android. Sedan jobbar jag dagligen med MIPS, ARM, PPC och x86 (jobbar med OS för inbyggda system) så är fullt medveten om att det inte går jämföra frekvenser rakt av.

Faktum är att det är betydligt mer komplicerat att jämföra prestanda mellan arkitekturer än att bara lura ut en ARM MHz/x86 MHz prestanda kvot. Enklare benchmarks ger nästan alltid omotiverat hög prestanda på simpla CPUer jämfört med vad man kommer se i verkligheten. Och i detta fall skulle det tala än mer för Medfield då dess cache-hierarki är betydligt mycket mer avancerad jämfört med Cortex A9, Atoms L2 cache kan ha betydligt många fler anrop "in-flight", något som inte alls påverkar resultatet i enklare benchmarks, men blir väldigt viktigt när man t.ex. ska driva en hel grafik-stack som är byggt i flera lager.

Hittade en jämförelse mellan Medfield och Tegra 3, det är som sagt en enda benchmark men den visar att Tegra3 och Medfield nog kommer ligga väldigt nära varandra i prestanda. Visst, Tegra3 borde vara snabbare på saker som kan utnyttja alla 4 kärnorna, men det kommer vara extremt få applikationer som gör detta under lång tid.

Vad det gäller prestanda i Dalvik (den virtuella maskin som de flesta Android applikation kör under, vissa spel använder den inte utan kör med NDK, Native Developmet Kit) så har Medfield en STOR fördel jämfört med multicore ARM, nämligen hyper-threading. Varför är det en fördel, HT är ju inte "riktigt" multicore.
Nä just det och kör man två st helt orelaterade saker, som t.ex. kör två program samtidigt, så är två CPU-kärnor alltid bättre (mer effektivt) än HT. Men i fallet Dalvik så handlar det om två trådar där den ena kör programmet och den andra kör GC (garbage collector). GC tråden komma aldrig behöva 100% av en full CPU (om den gör det så har applikationen grava designproblem), så HT är inte en flaskhals här. GC tråden kommer till stor del referera samma data som den tråd som kör programmet och här ligger den stora fördelen med HT jämfört med separata CPU-kärnor. De data som båda trådarna använder måste delas via L2-cache alt. RAM medan HT delar detta data direkt via L1 cachen. L1-cache har mycket högre bandbredd och långt lägre latens jämfört med L2 -> effektiviteten på HT blir bättre jämfört med två fysiska kärnor.

Notera också att effekten av HT är långt mycket högre på Atom än på Sandy Bridge. Applikationer där två kärnor ger väldigt nära x2 i prestandaförbättring på två fysiska kärnor ger ofta runt 10-30% med HT på Sandy Bridge. Samma sak med HT på Atom ger ofta 50-60%! Anledningen är inte att Atom är avancerad, utan tvärt om så blir HT så pass effektiv då Atom är en extremt simpel CPU som "stallar" rätt ofta. Alla dessa "stalls" gör att CPU är fri att använda för den andra tråden och har man två trådar så sjunker tiden när tråd kan köra dramatiskt. Sandy Bridge "stallar" betydligt mycket mer sällan och två trådar som kör via HT går mycket oftare turas om at använda CPUn.

Och sist men kanske inte minst: rent generellt kan man inte direkt använda klockfrekvens föra att jämföra prestanda mellan två olika CPUer/arkitekturer. Men i praktiken så går det väldigt bra mellan just ARM Cortex A9 och Atom då de RÅKAR ha väldigt snarlik IPC.

Interessant att vi kan får så olika resultat.

Jag testade precis SunSpider och på en 1.5GHz Atom körandes 32-bitars Ubuntu 11.10 samt 32-bitars Win7 så är Firefox 9 54% snabbare under Ubuntu och Chrome16 är 35% snabbare under Ubuntu.

Samma test på en maskin med 2.4GHz Core2 (kör x86_64 versionerna) (kan inte använda min Core i5 MBP då jag tagit bort Win7 på den) visar att Firefox är 12% snabbare på Ubuntu 11.10 medan Chrome är 51%(!) snabbare på Ubuntu 11.10 jämfört med Win7. Notera att JS prestanda var i alla fall tidigare långsammare på 64-bitars jämfört med 32-bitars då 32-bitars varianten hade klart bättre/mer avancerat JIT-stöd. Därför viktigt att jämföra 32 mot 32 och 64 mot 64.

Personligen tycker jag PeaceKeeper är en betydligt mycket bättre webbenchmark jämfört med V8 och SunSpider, då PeaceKeeper försöker testa både JS, DOM och grafik-delen av webbläsaren, d.v.s man försöker mäta "surf-prestanda". SunSpider och V8 mäter endast JS prestanda, som bara är en liten del.

På en stark maskin så är PeaceKeeper resultatet mycket mer lika mellan en Ubuntu och en Win7 dator jämfört vad det är på en svagare dator (t.ex. Atom) där Ubuntu är klart snabbare.

Ha, ha!!! Visst är det han! LOL

Det fungerar om man inte ser tar "IPC" helt bokstavligen. En x86 genomför i genomsnitt mer arbete per instruktion än ARM som utför mer än PPC som utför mer än MIPS. Men när jag säger att Cortex A9 och Atom har ungefär samma "IPC" så menade jag att de i genomsnitt kör samma program ungefär lika snabbat vid samma klockfrekvens. Till att börja med är inte detta helt sant, Atom ligger någonstans mellan Cortex A8 och A9 (en A9 är alltså något snabbare än Atom vid samma frekvens). Sedan så skulle en ARM CPU rent tekniskt ha högre IPC om den var exakt lika snabba som en x86 vid samma klockfrekvens då x86 kod är mer kompakt (en länk som visar att så är fallet).

Till att börja med har man ALDRIG tjänat tusentals cykler, möjligen hundratals i värsta fall då "unaligned access" kan dubbla (i värsta fall) antal accesser mot RAM och det kostar (i värsta fall, d.v.s inte en en LLC träff) 100-tals cykler. Sedan så låter x86 dig referera minne på vilken adress som helst helt utan extra kostnad sedan Nehalem, så på moderna x86 kan man helt skita i alignment. På PPC och MIPS så är "unaligned access" inte ens tillåten i många fall (ger en krasch) och på ARM får man ett resultat som väldigt sällan är det man menade (man får minnescellen på närmaste address avrundat nedåt till närmsta tal delbart med 4 och sedan är resultatet roterat så många steg man var från en adressen delbar med 4...). Så visst är "code alignment" ett problem i vissa fall, men det är ett icke-problem på en modern x86.

Majoriteten av alla implementationer av Cortex A8 och senare har minst lika mycket cache som Atom (L1 är 32/32kB på ARM och 32/24kB på Atom, L2 är 0-4M, typiskt 512k-1M på ARM och 512k på Atom), däremot har alla moderna x86or, till och med Atom, en betydligt mer avancerad cache än ARM. Cortex A9 har däremot högre bandbredd mot både L1 och L2 cache jämfört med Atom, så i en micro-benchmark kommer A9 se riktigt stark ut mot Atom, men på ett större program som använder gör access mot relativt många cache-lines (många är ändå så pass lite som 10-20 st) kommer rejält gynna Atom jämfört med A9.

Fast frågan är: det GUI-bibliotek som användes, vilken typ av system vad det designat för? 2M kan vara extremt mycket, det är fullt möjligt att köra RTOS som VxWorks, OSE m.fl. med flera program och fullt TCP/IP nätverksstöd på halva den mängden minne. Men på en PC så är det alldeles för dyrt att optimera ner på några få MB, det är inte alls säker att det går fortare heller då vissa algoritmer som har bättre algoritmisk prestanda ("skalar bättre") inte allt för sällan kräver mer RAM för att fungera optimal. Om ett program drar 2M eller 3M på en PC med 8GB är helt irrelevent och om det går fortare att skriva programmet så det drar 3M så gör man det. Så att du optimerade en specifik GUI från 2M till 5k säger väldigt lite och det behöver definitivt inte betyda att det ursprungliga programmet var dåligt skrivet.

Det är fullt möjligt att jämföra arkitekturer bara man säger VAD man jämför och att man köra mer eller mindre samma programvara på de system man jämför. Det jag refererade till var hur Cortex A9 står sig mot Atom när båda kör Android 4 och mer specifikt den inbyggda webbläsaren. I flera "webb-benchmarks" så är en Medfield (Atom baserad SoC som går på 1.3GHz och kan "turbo boosta" till 1.6GHz) konsekvent snabbare än Cortex A9 på 1.2GHz ("Mali SoC") och Medfield var yttest marginellt snabbare än Tegra3 som har en Cortex A9 på 1.3GHz (denna benchmark använder bara en tråd, så det är single-thread prestanda vi jämför).

Att det rent tekniskt vore möjligt att tok-optimera ett program som kör exakt den benchmarken är helt irrelevant då ingen kommer använda systemet på det sättet. Att köra Android + dess grafikstack + en webbläsare är relativt komplext (för denna typ av CPUer) och Atom står sig därför väldigt väl mot ARM i sådana tester och min poäng var att på denna typ av test så presterar en Atom och en Cortex A9 som kör på samma klockfrekvens ungefär lika bra. Är dock rent tekniskt inkorrekt att säga att de har samma IPC.

De programvaror och OS vi utvecklar på jobbet består av miljoner rader kod och kan köras på en lång rad olika CPU-arkitekturer. Och erfarenheten visar att den relativa hastigheten mellan olika kort som kan använda olika CPU-arkitekturer är relativt konstant på en lång rad arbetslaster. Men visst finns det saker där det kan skilja kraftigt. MIPS och ARM-kort tenderar ha väldigt dålig bandbredd mot RAM jämfört med PPC och x86, så PPC och x86 står sig relativt sätt väl på dessa. Vissa kort, vanligen MIPS och PPC baserade kort, har speciell HW-för saker som nätverk, kryptering och de är då relativt sätt väldigt starka på dessa saker.

Men jämför man program där alla beräkningar utförs av CPUn så är den relativa prestandan väldigt konstant mellan olika program över CPU-arkitekturer.

Om det skulle vara sant så har Intel fel om sin egen CPU. När jag läste "optimization guide" för Nehalem stod det just att det inte kostar något extra att läsa data från fel "alignment", t.ex. läsa 32-bitar från en adress som inte är jämt delbar med 4.

Men efter att tittat i den länk du postade så kan det förklara en del. På 90-talet har de flesta CPUer en cache-line storlek på endast 16-bytes (något som också används som exempel i länken). Även på Nehalem kostar det naturligtvis mer att läsa/skriva data om det korsar en cache-line gräns. Men dagens CPUer har betydligt längre cache-lines, x86 har 64-bytes och vissa andra har redan gått till 128-bytes.

I länken nämns också att alignment bara spelar roll för data och man nämner PPro, PIII. På dessa CPUer kostar det extra att läsa data unaligned (blir två anrop över bussen i stället för ett), det är sedan Nehalem man inte har denna extrakostnad.

Så länge som du läser minne eller hoppar till en instruktion som inte korsar en 64-bytes gräns så kostar det inget extra sedan Nehalem. Om du helt ignorerar alignment så är det ändå bara 3/64 (genomsnittsstorleken på en x86 instruktion i "vanliga" är strax över 3 bytes) 5% risk att korsa en cache-line gräns och det kommer ändå bara spela någon roll om någon av cache-linjerna inte redan ligger i L1.

På ARM Cortex A8/A9 så är en cache-line 32-bytes, men där kan en enda instruktion aldrig korsa en cache-line då de alltid ligger på en adress som är jämt delbar med 4 (ignorerar Thumb).