Apple kan släppa persondatorer med ARM-baserade processorer 2016–2017

Gör inte det här att det inte alls går att spela på en Mac?

Det har det ju inte gjort tidigare heller så vad är skillanden?

Vad vill du åstadkomma genom att komma med rena troll-kommentarer som denna? Du vet mycket väl att det inte stämmer. Självklart går det att spela på Apples datorer, och så kommer det förbli, oavsett processorarkitektur.

Självklart kan man spela på Apples datorer så rimligen borde mitt inlägg inte tolkas ordagrant och utanför sitt kontext. Jag försökte ordvitsa lite utifrån att prestandan för Apples OSX inte är i paritet med Windows när det gäller 3D-grafik och avslutar med en fråga som visar att ArcticFires inlägg är öppen för tolkning så han kan utveckla sitt resonemang.

Nog kan man spela på dagens macbook air. Moba-spel och WoW på hyfsat låga inställningar. Tycker det är något att notera att det kanske inte kommer vara möjligt längre.

Skickades från m.sweclockers.com

Självfallet så dementerar dom, fattas bara annat
Intressant är hur historien skrivs om, från början så kom inte iden till ARM förrän efter dom besökt WDC. Nu reffereras det mest till att iden fanns innan besöket

Och givetvis är inte 6502 en RISC per def. däremot så var den en inspiration med sin enkla och effektiva minnes adressering, avbrottshantering och i/o. Adresseringen av dom första 256 adresserna var rätt genial, var ju en av dom starka bitarna med 6502'an.
Sen var ju inte allt med indirekt adessering implementerat fullt ut på 6502, kom ju först i 65C02...
Deras mål var ju en snabbare CPU med mer än 16 bitars adressering, adresseringen kunde ju gås runt med paging men inte hastigheten.
När dom under designen började att snegla på Berkeley RISC så försvann väll likheten än mer, men besöket hos WDC var ändå från början en förhoppning om att få till en snabbare CPU med möjlighet till ett större adress område.
Planer som troligen ändrades redan direkt vid besöket då dom förstod att 6502 var en en-mans konstruktion, då deras egna resurser och kompetens redan då var större. Något som aldrig sades, men var rätt lätt att läsa ut mellan raderna på den tiden...

Att WDC sen kom ut med 65C816 och 65C802 (pinkmpatibel med 6502) ungefär samtidigt som ARM bildades är en annan story, vilken som var snabbast 65C816 eller ARM2 har jag inte en aning om
Det sägs även att 65C816 kom till på förfrågan från Apple, vilket ju är troligt då den direkt kom i Apple IIgs.
Förmodligen så ansåg WDC inte Acorn som någon större kund...

Det med load/store och problem på ARM med flera är väll mer när det körs beroende processer, kan tänka mig att det kan ge lite mer förlust på RISC sidan än på CISC sidan. Detta då det tar tid att spara och ladda register, något som teoretiskt borde ge mer förlust på RISC sidan även om tiden att spara/ladda X antal register ger samma mängd klock cykler.
Då borde ju TI990 ha fördel om den funnits nu, den körde ju nästan helt med minnesregister

Load/store-arkitektur är i normalfallet inget problem, men för atomära instruktioner måste man ju ha en load-op-store cykel för att det överhuvudtaget ska vara en poäng med att göra det atomärt och att då inte direkt kunna referera minne i "op" delen blir ju ett problem. RISC löser traditionellt det problemet via någon form av load-linked/store-conditional sekvens, men är naturligtvis lättare att design logik där det som kommer mellan "load" och "store" är hårt specificerat än LL/SC som i.o.f.s är mer flexibelt men rent teoretiskt kan det ju vara hur många instruktioner som helst mellan LL och SC.

Sen har ju Intel även i normalfallet löst det RISC-anhängare anser den absolut största fördelen med RISC: icke-förstörande operationer. RISC instruktioner är typiskt på formen (A, B och C är register, X är register eller RAM).

C = A op B

med CISC typiskt är på formen

X = X op B

d.v.s. innehållet i X skrivs alltid över i CISC vilket då betyder att man måste spara undan innehållet i X om originalvärdet måste sparas. "Lösningen" på detta problem är att sedan Haswell så hanteras register-till-register tilldelningar helt i front-end (via register renaming/alias) så back-end delen blir aldrig belastad av detta. Ovanpå det är kompilatorer rätt bra på att undvika detta ändå + i många fall behöver man ju inte spara vare sig A eller B så totalt sett är nog just detta ett rätt svagt argument för RISC.

Historian kring hur mycket ARM inspirerades av 8502 kan mycket väl har förvanskats en hel del, var ju rätt mycket stämningar mellan tillverkarna redan på den tiden så ARM vill knappast erkänna att de sneglade allt för mycket på något annat, oavsett om de gjorde det eller ej.

ARM liksom x86 representerar familjer av processorer, som implementerar en instruktionsuppsättning m.h.a. olika kretslösningar och kiselprocesser. Så det finns inget enkelt svar.
Om vi tittar på "best-in-class" implementationerna just nu, kan man kanske jämföra intels Broadwell och Apples A8(x). Det är fortfarande lite av äpplen och päron, prisskillnaden är en faktor tio, olika kiselprocesser, halva A8 består av annat än GPU/CPU/cache/minnesbuss (!), effektförbrukning vid benchmarking osv kan alla diskuteras. Men det råder inte mycket tvivel om att senaste iterationen av Apples ARM är i runda slängar jämförbar med Broadwell, vid motsvarande effektförbrukning. Kolla benchmarks på Lenovos Yoga 3 vs. IPad Air2 t.ex.

Prestanda är inte det som kommer att avgöra om/när/för vilka system Apple börjar använda sina egna processorer också för OSX. Andra aspekter skiljer mycket, mycket mer.

Tyvärr finns det ett antal som håller kvar vid gamla käpphästar och vägrar släppa detta. De vägrar förstå att det finns företag som inte kan räddas mer än tillfälligt oavsett om man så pumpar in tiotals miljarder, för de läcker pengar ännu fortare!

Apple är ett utmärkt exempel. De var på ruinens brant -97, men gjorde en vinst på drygt $300 miljoner -98, tack vare Steve Jobs. Där vände han skeppet på ett år, med ett kassatillskott på $150 miljoner från Microsoft.

Det du länkar till beskriver hur man kan använda SSE3 för att till viss del accelerera SHA-1, det Aarch64 har och Intel kommer få i Skylake är specifika instruktioner för SHA-1 på samma sätt som 32nm Nehalem (Westmere för servers, Arrandale för laptops) fick för AES i och med AES-NI.

Geekbench använder AES-NI och SHA-1 instruktioner på Aarch64, men den använder inte SSE3 för att göra en mer effektiv SHA-1 implementation. Du får kolla disassembler om du inte tror mig alt. betala för Geekbench så du får tillgång till källkoden.

Har inte jag länkat till de benchmark resultat jag refererar till? Vad det gäller cache-latens, branch-missprediction så skulle det kräva extremt mycket tid om jag ska leta på länkar till varenda utsaga, kan de flesta utantill då en av mina arbetsuppgifter är att designa extremt prestandakritiska kodbibliotek till bl.a. Intel Xeon (för tillfället SNB, IVB och HSW) och Avoton (för tillfället SMT) samt ARM Cortex A7 och Cortex A15. För diskussionen var det inte heller viktigt att ha exakta siffror, huvudpoängen var mest: Cyclone är väldigt bred jämfört med Silvermont, Intels L2-cachar har rejält mycket lägre latens jämfört med alla andra samt Cyclone har inte allas samma nivå på sina branch-predictors och prefetcher som HSW, vilket den måste ha om den ska kunna prestera bra på komplicerade program då det är en väldigt "bred" design (är ju bredare än Haswell till och med).

En väldigt bra källa för x86 är Agner Fog, för ARM är det lurigare då det inte finns allas något motsvarande Intel/AMDs optimeringsmanualer och vad Agner Fog satt ihop. Vad det gäller Apples Swift och Cyclone finns i princip bara en vettig källa utöver att testa själv: den information som Apple själva måste specifiera för sina kretsar i LLVM för att den ska kunna optimera väl. Är bl.a. där AnandTech grävt ut decode-width och issue-width.

Sedan kan jag utan problem "erkänna" att jag inte kan något om hur man rent fysiskt designar CPU-kretsar, men vet väldigt mycket om hur olika designval påverkar olika delar i ett program och vad man bör göra och inte göra givet en viss design.

Med andra ord en kvalificerad gissning. Var just därför jag använde en Intel CPU när jag testade cache hit-rate i Geekbench, då behöver man inte gissa utan det går att mäta ner på enskild cache hit/miss. Dock var det enda relevanta här: Geekbench går inte att använda för att avgöra hur en CPU står sig i mer normala program då den använder arbetslaster som är så löjligt små att de får plats i en 32kB L1 cache.

Geekbench-testet för "stream" är bokstavligen detta

geekbench_stream(uint32_t *a, uint32_t *b, uint32_t scale, size_t len)
{
    for (size_t i = 0; i < len; i++) {
        a[i] = scale * b[i];
    }
}

där scale är 1 för "copy" och >1 för "scale" stream-tester. Seriöst vad har resultatet av detta för relevans i verkliga applikationer?

Cyclone har fler ALU än Haswell, men min poäng var att det är bara en väldigt liten den av hur en CPU faktiskt presterar. Ju mer komplicerade program man kör ju mindre viktigt är teoretisk beräkningskraft då prestanda kommer vara helt begränsad av huruvida processorn lyckas förse sin back-end med relevant data i tid. Mäter man IPC (något som igen går att mäta ner på instruktionsnivå på Intels CPUer, så man behöver inte gissa, ett alternativ är Intels Performance Monitor för Linux) för serverlaster med väldigt stora "working-set" så inser man snabbt att inte ens den värsta Xeon CPU med 30MB cache fixar att hålla IPC speciellt mycket över 1.0. Om man då har 1, 2 eller 100 ALU-enheter är rätt irrelevant då för prestanda, så Silvermont, Haswell och Cyclone har alla overkill vad det gäller ALU ett sådant fall.

Så min poäng här var: för mer komplicerade program så är det betydligt viktigare hur bra CPU-delen är att lära sig mönster i hopp och minnesaccesser + en låg latens är kritiskt när del väl gissat fel.

Fast det är inte vad jag sa och inte heller vad texten du länkade till säger. Den säger att så länge posterna ligger sekventiellt i minnet presterar Cyclone bra (trivial last för en prefetcher att hantera) men i deras "riktiga" fall blir accessmönstret väldigt oregelbundet (+ att logik baserad på data i posterna gör att villkorade hopp inte längre är triviala att förutsäga, men det sägs inte explicit men är något som kommer hända i en simulering). Min enda poäng här var att Cyclone må ha "bredden" för att matcha Haswell vad det gäller IPC i något så trivialt som Geekbench, men när man jämför Cyclone mot Haswell (och även Silvermont) i detta test så ser man att det trots allt handlar om en CPU med väldigt simpel (men bred) front-end.

Just latensen för cache i Swift och Cyclone går inte att veta exakt då Apple inte uppger den och det är tyvärr inget som går att hitta i LLVM-beskrivningen för arkitekturen (där finns bara L1-latens och branch-missprediction kostnad). Däremot går det att hitta latens för t.ex. Cortex A9 och Cortex A15. Notera att effektiv latens kan vara lägre än faktisk latens för allt som missar L1, Cortex A15 i fallet jag refererar till har en latens på 21 cykler men ändå är den uppmätta latensen för 128kB 17 cykler vilket då visar att vissa accesser har prefetchen helt eller delvis lyckats pricka in så data kommer till CPU-delen fortare än L2-latensen.

Mätningen som AnandTech gjord är också ett mått på effektiv latens, enda sättet att jämföra det mot t.ex. Silvermont vore att köra exakt samma test på den. Något i Cyclone är rejält förbättrat jämfört med Swift, men eftersom man inte har värdet på L2-latensen kan den lägre effektiva latensen komma av bättre prefetchers, snabbare cache men också (och det VET man är fallet) ett mycket bredare out-of-order fönster som då kan "svälja" mer latens i ett fall när man inte gör något annat än den "for-loop" som Geekbench stream gör.

Den diskussion jag förde kring detta hade med relativa kostnaden för en "bred", lågt klockad design som Cyclone kontra en "smal" men högre klockad design som Silvermont. Exakta siffror finns inte för Cyclone vilket var en anledning till att jag använde branch-miss-prediction kostnad i stället, men värdet var ändå inte relevanta för slutsatsen. Nu kanske Apple lyckas med något som varken andra ARM-tillverkare eller AMD lyckats med under väldigt många år: göra en L2-cache matchar i alla fall Silvermont (Haswell har 12 cyklers latens mot sin cache, fast den är då mindre med sina 256kB). Resultatet av diskussionen blir ändå att om Silvermont och Cyclone har ungefär lika avancerade prefetcher/branch-predictors och ungefär lika låg latens på cachen så kommer Silvermont presterar bättre då den relativa kostnaden för missar är lägre då den är smalare samt högre klockad.

Men fel av mig att ens gissa en L2-latens för Cyclone, det var både irrelevant för diskussionen och sannolikhet fel (får skylla på att jag var kvar i min Cortex A15 diskussion mental). Cyclone är så pass lågt klockad, så även fast det är en relativt stor L2-cache på 2MB borde den ha en latens under 20 cykler (Cortex A15 klockas ju i telefoner till 2.5GHz så där är det svårare att ha riktigt låg latens). Rätt utsaga är att Silvermont har lägre absolut latens mot L2, 13-14 cykler med högre klocka. 2MB L2 lär inte ha en latens i Haswell nivå då ljusets hastighet är konstant även för Apple.

Detta är ett diskussionsforum, finns gränser för hur mycket efterforskning folk orkar göra för att skriva ett inlägg. Saker ska inte vara totalt fel, men det mesta som diskuteras i denna post är om det ska vara 14, 17 eller 21 cyklers latens vilket för den diskussion som egentligen fördes (hur pass bra/dåligt Cyclone presterar i applikationer mer avancerade än iOS-appar) är totalt irrelevant, slutsatsen blir den samma vid 14 cyklers latens som vid 21 då den det är en så liten del av helheten.

Utvecklar enbart "stängd" kod, ett exempel på vad jag gjort är en TCP/IP-implementation + väldigt enkelt webb-server som fixade att hantera upp till 9 miljoner HTTP/1.1 transaktioner per sekund på 2st Xeon E5-2690 kärnor. Gör man något mer avancerat än statiska HTTP-sidor skalar detta linjärt till ett fullt dual-socket system upp till i alla fall 2x 12-kärnor, i det enklaste fallet var det helt enkelt svårt att hitta något som kan generera mer än 9M HTTP/1.1 anrop... Systemet hade en genomsnittlig IPC på ~2.5 vilket jämfört med andra program är väldigt högt, SNB->HSW har alla ett teoretisk max på 4 x86 instruktioner per cykel, 5 om man kan använda "macro-op fusion" varje cykel.

Dels skrev jag att min referens om >20 cykler var en ihopblandad med Cortex A15, sedan refererar jag till absolut load-to-use latens medan Anand mäter effektiv latens. Du såg ju att den är lägre än faktiskt latens, hur mycket lägre beror på hur bra prefetchers är och hur stort stort OoO fönstret är (och det är stort på Cyclone).

Sedan måste jag säga att Apple har ju gjort något väldigt rätt med tanke på att Swift mikroarkitekturmässigt (det lilla som är känt) påminner om något mellan Cortex A9 och A15, men har en IPC som är bättre än A15. AnandTech har många gånger varit inne på att det är just en bättre cache än andra ARM-designer som ligger bakom det.

En bredare design får ett större straff för felaktig spekulering då detta upptäcks i "back-end" och det ligger då en rad instruktioner som redan börjat hanteras men nu måste slängas, ju bredare design desto fler instruktioner hinner CPUn tugga i sig.

Är egentligen 3 "huvudmått" man måste klassificera en CPU efter

• bredden: hur många instruktioner kan maximalt avkodas per cykel. Finns även en bredd i back-end i form av antal exekveringsportar. Cyclone har 6/9, Haswell har 4/8, Silvermont har 2/6

• djup: storleken på ROB (ReOrder Buffer), d.v.s. storleken på out-of-order fönstret, det är gigantiskt på Cyclone och Haswell, 192 micro-ops. Det är endast 32 micro-ops på Silvermont. Större djup möjliggör fler instruktioner "in-flight" vilket ger större möjligheter att hitta något att göra medan load/store operationer väntar på sitt resultat. Transistormässigt är det dyrt med ett högt värde här.

• längd: (vettigt namn?) vilket är längden på pipeline genom processorn och därmed minsta latens från att en instruktion kliver in i front-end till dess att resultatet skrivs ut av back-end. Det är inte längre ett fix värde då olika ALU har olika latens, har inte sett detta på Cyclone men typisk är branch-miss-prediction kostnaden rätt nära detta värde och enligt AnandTech så är den kostnaden 14-19 cykler. Missprediction på Silvermont är 10 enligt RealWorldTech och pipeline längden är 14-16 cykler. Haswell har en 14-19 cyklers längd på sin pipeline och en missprediction kostnad på 15-20 cykler.

Ju "längre" den är ju högre går den typisk och klocka, men alla felspekuleringar blir dyrare.
Ju "djupare" den är ju dyrare blir "worst-case" felspekuleringar för hopp, men däremot kan man "gömma" allt mer cache-latens med större "djup".
Ju "bredare" ju högre maximal kapacitet får man, väldigt svårt att dra nytta av bredden i kod med mycket villkorade hopp. Har hört från CPU-designers att det är i princip hopplöst att nå över en IPC på 2-2.5 per CPU-tråd i genomsnittlig kod, oavsett bredd, då det helt enkelt inte finns tillräckligt med oberoende instruktioner. SPARC (Oracle) anser ju fortfarande att det är meningslöst med en bredare kärna än 2 och det trots att deras T4/T5 har 8 trådar per fysisk kärna, skulle säga att de har rätt om man bara siktar på databas-laster och liknande men som desktop-OS skulle den CPUn suga.

Alla CPUer har problem med slumpmässig minnesaccess, men verkar som Cyclone relativt sätt har större problem än t.ex. Haswell, Silvermont och Cortex A15. Är helt övertygad att det kommer av att det blir helt omöjligt att upprätthålla en hög IPC i dessa fall, något Cyclone relativt sätt lider mer av än smalare designer som Silvermont och Cortex A15, Haswell hanterar det med en extremt avancerad front-end.

<EDIT>missade att nämna Geekbench. Är något jag drog in och pekare på dess begränsningar då väldigt många (på forum som AnandTech och liknande) ofta använder resultatet i denna benchmark att visa att t.ex. Cyclone är i Haswell-nivå. Cyclone har en IPC i nivå med Haswell i detta test, så felet är inte där utan att Geekbench är väldigt irrelevant som vägvisare kring relativ prestanda mellan olika CPU-designer i "verkliga" program. Enkla "breda" designer presterar väldigt bra i Geekbench, ungefär som Itanium som var rätt dålig på det mesta men den var fantastisk bra på HPC-laster för saker med mycket inneboende parallellism i instruktionströmmen och relativt få hopp (Itanium är en av de "bredaste" designer som någonsin skapats, upp till 12 instruktioner per cykel med Poulson).</EDIT>

Att dela något där man skriver mellan kärnor orsakar cache-line-bouncing, det är ett annan problem än vad 3DMark physics har. Sedan finns beroende mellan CPU-kärnor som delar cache även om man inte orsakar cache-line-bouncing, en 4 kärnors Cortex A15 skalar t.ex. inte linjärt på saker som inte får plats i L1 cache då alla 4 kärnorna delar L2, Silvermont (där 2 kärnor delar en L2-cache) skalar däremot helt linjärt i ett sådant fall upp till 8 kärnor (Avoton).

Kan ju vara så att Cyclone har problem med skalning till 3 kärnor då alla kärnor delar L2 där, vilket i så fall förklarar varför det inte skalar alls från 2->3 kärnor. Men ingen annan CPU-arkitektur verkar skala speciellt bra förbi två kärnor, så att andra CPUer skulle vara snabbare för de har fler kärnor håller inte som förklaring.

3DMark physics resultatet verkar inte vara skalbart, tog ju fram resultatet för A8 och A8X och det skilde 10%. 2 kärnor i7 mot 4 kärnors i7 med samma frekvens skilde 3%.

Bildbehandling är kanske parallelliserbart, har inte jättekoll på det. Men det är också något med väldigt hög cache-lokalitet både i tid och rum så det är en "snäll" last, är däremot något som behöver mycket beräkningskraft och lämpar sig därför väl för SSE/Neon. Fysikberäkningar och andra typer av simuleringar har inte alls lika hög cache-lokalitet främst i rummet då partiklar/kroppar som påverkar varandra behöver inte alls ligga nära varandra i RAM.

Det vi ursprungligen diskuterade var huruvida det är rimligt att Apple skulle köra sin ARM-design i MBA/MBP, där ska man ersätta Core i5/7, inte Silvermont. Jag drog in Silvermont för rent nykter så är A8/A8X betydligt närmare Silvermont än den är Haswell/Broadwell, redan Core M är ett rejält steg upp från A8X.

Är då Cyclone inte "desktop-class"? Om Apple stoppar in den CPUn i MBA är den ju det, finns ingen definition på desktop-class. Men idag är A8X något som i konkurrera med Silvermont i mer avancera applikationer, det är å andra sidan en CPU som fungerar även för ett desktop-OS, kör själv Z3770 i en 11" Win8.1 laptop.

Kan däremot inte se att A8X skulle vara energieffektivare än BayTrail (Silvermont), har ungefär samma batteritid på iPad som i Z3770 enheten med hänsyn taget till batteritkapacitet. Så skulle säga att de har likvärdig effektivitet.

Är då det rimligt att Apple går över till ARM? Har faktiskt ingen aning, men om de gör det så kommer de prestandamässigt gå tillbaka till den nivån man hade i de absolut första MBA-modellerna.
Kommer folk vilja ha det? Vet inte, den kommer vara lättare, ha bättre batteritid och vara fläktlös så viss utveckling är det ändå.

Apple har så mycket pengar för tillfället så man kan absolut inte utesluta något sådant, men tidsmässigt och ekonomiskt är det osannolikt. P.A. Semi hade nästan en färdigt PPC64 design som Apple sedan konverterade till "Cyclone" (känner folk som hade börjat jobba med PPC CPUn under NDA precis innan uppköpet). Att ta fram en helt ny CPU-design är extremt tidskrävande och dyrt (se på AMD och titta hur ofta Intel, IBM, ARM, Qualcomm etc gör något helt nytt), tror man kan se Cyclone i det läge Sandy Bridge var för Intel: första release med Nehalem, sedan mikroarkitekturputsning varje eller vart annat år.

Att använda samma systemkrets som man kör i Ipad och Iphone betyder skalfördelar -> prismässigt vettigt att använda designen i andra enheter. Mac-serien har helt enkelt för låg upplaga för att det ska vara ekonomiskt vettigt att designa något bara för den, framförallt om high-end skulle fortsätta med Intel. Men det är Apple, de har så mycket pengar att det är möjligt att göra val som inte är helt ekonomiskt rationellt.