Intel lanserar Clover Trail+ för smarta telefoner

Kommer i Bay Trail.

Man kan inte bara räkna cache design i latency, latencyn när det gäller cache står i direkt proportion till mängden minne. När Intel gick från prescott 1MB-2MB cache så ökade latencyn ifrån 21 till 27 cykler nått sånt. L1 cache som är väldigt liten ligger på en latency på 3-4 typiskt sett.
Och det är såklart mer parametrar en latency och minnes mängd som påverkar hur avancerad en cache är (bandbredd är en t.ex. )

Har väldigt svårt och tro att Intel ligger 10 år före ARM (eller AMD) i cache design. Räknar du även in branch predicting till "cache features" så ligger de ju definitvt inte 10 år före.

Hittar du någon studie som du kan länka till ? Enda rejäla försprånget det alltid pratas om är ju intels tillverkningstekniska försprång, hade de legat 10 år före i cache design (med tanke på hur viktig del det är i en modern processor) så hade det uppmärksammats mer.

Atom processorn må ha en ganska kort väg till cachen med låg latency men har o andra sidan 1MB (2x512), men ARM 15 kan ha upp till 4MB cache..

Atom har arkitekturen har inte direkt gett några generella prestandaökningar de senaste 5 åren, utan Intel har fokuserat att få ner effektförbrukningen, jämför man prestandan mellan A15 och Atom Dualcore, så ser A15 snabbare ut på det test som Anand Tech gjort.
Anandtechs jämförelse
Det är emot exynos dual core. enligt Anand så är Cortex A15 ca 40-65% snabbare i CPU testet (emot dualcore atom 1.6GHz)

Här är en annan artikel som jämför A15 emot Atom
http://www.extremetech.com/computing/139393-arm-cortex-a15-ex...

Anand verkar även skrivit lite om nya Atom släppet:
http://www.anandtech.com/show/6790/intels-clover-trail-dualco...

Saxat lite ifrån hans text: "like many modern smartphone SoCs, the addition of extra cores simply increases the dynamic range of SoC power consumption." så vid lättare belastning antagligen ingen skillnad, men vid tyngre belastning så lär den dra mer än nuvarande single core.

Jo Intels lösning på program som kallar Native ARM libraries är ju ganska cool hade glömt den faktiskt
Men jag undrar hur mycket performance den kostar, inte sett några tester, hittade dock en notis om den återigen hos Anand (tråkigt men han är en av de få som faktiskt publicerar de mer tekniskt inriktade artiklarna).

Intel isn't disclosing much about the solution, but by intercepting ARM binaries and translating ARM code to x86 code on the fly during execution Intel is hoping to achieve ~90% app compatibility at launch. Binary translation is typically noticeably slower than running native code, although Intel is unsurprisingly optimistic about the experience on Android. I'm still very skeptical about the overall experience but we'll have to wait and see for ourselves.

http://www.anandtech.com/show/5365/intels-medfield-atom-z2460...

Edit
Roligt projekt med benchmark programmet du jobbar på! Hur långt har du kommit?
Har en hög olika ARM processorer, allt den som satt i gamla Legend upp till ARM A-15, kan hjälpa dig med ett comparison register om du drar ett PM när appen är klar

Det var inte meningen att vara otrevlig! Trodde du menade att de blev byggda av robotar, när robotarna mest lyfter runt wafers och dylikt!

virtual void: Konverteringen sker ju inte i molnet alls utan det är en gammal myt, utan det sker med libhoudini och lite andra modifiering för att ackommodera detta. Det verkar vara en plattform som skött detta mycket bra, och vad det gäller binäröversättning så har Intel köpt upp mycket kompetens inom det området och har rätt mycket folk som kan allt kring kompilatorer/maskinkod för den delen. Android är helt rimligt att köra på flera arkitekturer som det är idag. Intels modem kommer fortsätta säljas med tredjepartschip däremot, precis som Infineons gjorde, denna verksamhet omsätter mycket mycket mer än när de drev Windows Mobile/Pocket PC, Linux och Blackberry-enheter med PXA/XScale. Intel är större på området än någonsin så det är klart att de lägger resurser på att få ut produkter, på att mjukvara fungerar osv. Det blir bara bättre där. Sen är det väl ganska naturligt att de inte hade något som konkurrera mot sin gamla PXA-linje när de sålde den verksamheten. SoCs på x86 fanns ju inte från Intel mellan 386EX (94) och Pentium M (anno 2007). Att de ville koncentrera på en ISA (flera design) har vi sett länge.

Jag har en känsla av att det inte gör det hela bättre för ARM. Att ha 40 cyklers latens är inte helt bra och långt efter Intel, att ha det på så små cachestorlekar är ännu värre. Sedan är ju bandbredd av mycket lägre betydelse än latens på cache.

Vågar nog påstå att Pentium M har överlägsen branch prediction jämfört med ARM också, men det överlåter jag väl till Virtual Void att reda ut.

Finns väldigt lite information kring exakt hur binärkonverteringen utförs, men den information som Intel lämnade innan Medfield släpptes var att konverteringen skulle vara automatisk (vilket den är) och att den inte skulle utföras på den mobila enheten då det skulle kosta för mycket ström. Med tanke på att det inte tar någon extra tid att installera saker som TuneIn, Angry Birds som alla innehåller ARM specifika NDK-delar så gissar jag att denna konvertering inte sker vid installationstillfället.

Det tar heller inte någon extra tid att starta programmet, inte ens första gången. Så drog helt enkelt slutsatsen att det Intel initialt sade att konvertingen kommer redan vara utförd innan man laddar ner APK filen stämmer. Och i så fall sker konverteringen i "molnet" sett från min punkt som användare.

Har precis börjat på benchmarken, men det borde inte ta allt för lång tid att få till den. Anledningen till att göra den var dels för att lära mig mer om Android-utveckling (detta är den största anledningen) men också då jag tycker att de flesta andra benchmarks endera visar väldigt lite av skillnader i CPU-delen (JavaScript benchmarks som beror väldigt mycket på kvalitén på JIT-kompilator, x86 verkar prestera bättre än förväntat i dessa benchmarks). Många andra benchmarks fokuserar alldeles för mycket på flyttal, något som kraftigt gynnar Cortex A15 som har en väldigt bra FPU men det säger väldigt lite om upplevd prestanda då nära nog allt vi kör är begränsat av heltalsprestanda alt. av GPU-prestanda.

Tittar man på dessa resultat och funderar på vilka som är heltalstunga så står ju sig Medfield (RAZR i) väldigt bra mot dual core Cortex A15 (Nexus 10) och då ska man inse att man jämför en pekplatta mot en telefon där pekplatta har betydligt mer "thermal headroom".

Visa innehåll

Dold text

Diskussionen kring hur många år före Intel ligger i cache-design är rätt meningslös, man kan i alla fall konstatera att Atom knappast är state-of-the-art på något sätt men den har ändå på många sätt en bättre cache-design än Cortex 15 och den är överlägsen Cortex A9.

L1 cache-latens
Atom: 3 cykler
Cortex A15: 4 cykler
Cortex A9: 4 cykler

L2 cache-latens (teoretiska minimum, verklig latens är högre och enligt t.ex. SiSoft Sandra testerna ligger Atom betydligt närmare sina teoretiska siffror)
Atom: 15 cykler
Cortex A15: 17 cykler
Cortex A9: 23 cykler

TLB miss-cost (TLB cachen är extremt viktig då den ligger före L1 cachen, väldigt ofta när man får en L2 miss får man även en TLB miss)
Atom: 7 cykler
Cortex A15: 12 cykler
Cortex A9: 7 cykler (ja, just detta är tydligt bättre på A9 jämfört med A15)

Edit: tänk på att latens adderas, så effektiv latens mot L2 är L1-latens + L2-latens + eventuell TBL-miss latens.
Och vad det gäller storleken kontra latens: visst ökar latens med större storlek men Intels L3 cache på SNB har en total latens (d.v.s inklusive latens från L1 och L2) på 26-31cykler vid 8MB och bara några cykler till vid 20MB!

Hittar väldigt lite om hur branch-prediction fungerar på A15, Atom har en lite obalanserad design här branch taken/not-taken tabellen är så pass mycket större än branch-target tabellen så med "objektorienterad" kod där man har ganska mycket indirekta hopp (hopp via funktionspekare) så kan Atom mycket oftare avgöra om de ska hoppa eller ej, men den vet inte vart (branch.target). En full miss kostar 15 cykler på Atom och lär kosta minst lika mycket på Cortex A15 då den har en pipeline på 15-21 steg (beror på vilken instruktion man kör) vilket är väldigt långt för att vara ARM, Cortex A9 hade bara 9 steg. Så A15 behöver en väldigt bra branchpredictor, 15 steg är längre än den effektiva längden på Sandy Bridge (som är 14 steg)!

Tittar man på designen av CPU-kärnan på Cortex A9, A15 och jämför med Atom så inser man snabbt att något i Atom måste vara väldigt mycket bättre jämfört med ARM får Atom är en dual-issue in-order design där endast den ena pipelin:en kan utföra instruktioner som går mot minnet (och 32-bitars x86 har väldigt ont om register). Jämför detta mot A9 helt symmetriska dual-issue out-of-order design och Cortex A15 trippel-issue + quad execute out-order design. Givet denna information så ligger A15 närmare en Pentium M i design men en Pentium M har dubbel IPC jämfört med Atom, något knappast A15 har. Även A9 borde på pappret demolera Atom, men Atom är tvärtom snabbare. Ska bli väldigt intressant att se den nya Atom-plattformen på 22nm med FinFET och out-of-order execution. Designen av CPU-cachen blir ju än mer komplex när man går OoO då CPUn kan ha väldigt många läsningar och skrivningar "in flight", något som inte är möjligt med in-order då allt sker, well, i ordning

Cortex A15 drar också betydligt mer ström än Medfield och Clover Trail. Enligt det test som AnandTech gjorde så har Atom bättre prestanda/W än både A9 och A15, A9 har i sin tur bättre prestanda/W än A15.

Tittar man på bilderna så ser man att Intel lyckats bra med overall system power. När man jämför SoC emot SoC så verkar ju Krait mer strömsnål i både idle och use. GPU delen som är snabbare är verkar dra lite mer (dock kraftfullare).

Jämför man sen med A-15 så pga av effektiv powergating så verkar A15 bättre i idle (igen om man bara kollar SoC) total power är inte jämförbar då de har väldigt annorlunda hårdvara, t.ex. 2560x1600 upplösning jämfört emot 1366x768.

In use så är det såklart annorlunda, där är atom mer strömsnål än A15, vilket i sig är logist då då A15 är kraftfullare, själva resultaten i den studien är dock svåra och kvantifiera då det är så väldigt mycket som är annorlunda native kod vs vm, 2560x1600 upplösning vs 1366x768, olika os, olika mjukvaror etc.

Mest rättvisa testet på ren SoC prestanda är fortfarande det jag länkade, där båda SoCsen kör samma mjukvara (kompilerad för vars plattform) med samma skärmupplösning. och där är ARM-A15 mycket snabbare.

vad det gäller A9 så har de ju gjort många förbättringar (prestanda mässigt) under dess livstid, det kommer ju ytterligare än nu r4, där de migrerat vissa bitar ifrån A15 till A9 arkitekturen. (Tegra4i är ju t.ex. byggd på den, gissar nya krait i snapdragon 600 med är byggd på den). Det skall bli intressant och se hur de står sig emot nya atom plattformen.

Snapdragon 600 är förövrigt (enligr preliminära benchmarks) väldigt mycket snabbare än gamla S4 Pro, och enligt dem själva till lägre strömförbrukning.

Vad det gäller mobile SoC's så lämpar sig inte riktigt A-15 dualcore designen. den har helt enkelt för hög effekt, det är ju där big.LITTLE conceptet kommer in.

big.LITTLE, samt Tegra 4 (som kör en low power A15) kommer leta sig ut i mobiler med.

big.LITTLE verkar riktigt coolt då den individuellt kan känner av hur mycket kraft som behövs. Dock så behöver den inte kräma på på A15 core'sen allt för mycket, och väldigt sällan mer än 1 eller 2.

Måste säga att jag är ganska imponerad över Atom, de har lyckats rätt bra med att pressa ner den i effekt. Får se ifall de kan hålla den nere när de väl börjar öka prestandan...

Oavsett vad så tror jag ändå att denna generation kommer domineras av Qualcomms processorer, mest pga av de har de bästa helhets lösningarna.
Nästa generation när intel går ner till 22nm mobile SoC's så kommer de vara en starkare utmanare (förutsatt att de fortsätter uppgradera sitt radiochip att inkludera LTE).

Tänk på att Krait siffrorna inte inkluderar strömförbrukningen för L2-cachen, det är typ 50% av transistorerna i en modern processor... Men skulle ändå säga att Qualcomms Krait är det bästa telefon SoC man kan hitta just nu, väldigt bra batteritid samt bra prestanda. Intels SoC har lite väl klen GPU och Cortex A15 drar för mycket ström för att fungera i allt utom de största pekplattorna.

Edit: och den jämförelse du länkar till mellan Atom och Cortex A15 är mot N570, det är en rätt gammal design. Dels finns D2700 och N2800 som båda är snabbare och strömsnålare än N570, men Z2460 (Medfield) och Z2750 (Clover Trail) är dels högre klockade än N570, drar mycket mindre ström och har även en hel del förbättringar i sin "north-bridge" som drar upp prestanda i vissa lägen. Titta bara hur mycket bättre Z2460 (single core Atom) klarar sig mot Cortex A15 jämfört med N570 (dual core Atom).

Houdini har portats/används i andra roms och som jag förstår det fungerar med APKs utan att du ansluter dig till något så det är inget i molnet. Skulle det ske någon annan stans skulle det behöva ske på Google Play/Market. Android x86 har en rad ARM-bibliotek utöver själva infrastrukturen för libhoudini och libdvm. Sånt som moderna program osv är vid det här laget ofta byggt för x86 och det är ju standard i SDKn. Mycket är inte och använder ARM-translatorn. Bluestacks stödjer också ARM-bibliotek/körbara filer, fast med egen teknik vad jag förstått, och det är ganska segt. Eftersom Intels ska vara begränsad till ARMv5 så låter det helt rimligt att det körs på telefonen som emulator/kompatibilitetslager. Det tog ju inte ens någon större tid på Windows NT 4.0 Alpha tiden. Just att det inte sker vid installation verkar stämma. Ska du dra ner programmet två gånger skulle du se det på dataanvändningen hur som helt.