8 kärnors mobil är korkat

Delad cache är kan hjälpa till, men det hjälper bara latensen på för att läsa data som delas mellan flera kärnor, inte skriva. De multicore-system vi använder oss av upprätthåller en egenskap som kallas "cache coherence", även om en skrivning kanske inte alltid måste gå ända till RAM så är kostnaden (i latens/svarstid) motsvarande den du har mot RAM om en CPU-kärna skriver till en s.k. cache-line (64-byte stora på de flesta moderna CPUer bl.a. de från ARM, AMD och Intel CPUer).

I parallella program vill man ofta bygga sin inter-CPU-kommunikation på primitiver som garanterar sekventiellt-konsistens (SC). I stor sätt betyder det att jag vill ha en garanti att när jag läser variabel A så måste CPUn garantera att alla läsningar och skrivningar som kommer efter denna SC-läsning händer efter (happens after, a.k.a acquire barrier) läsningen av A (i normalfallet kan CPUn ändra runt i den ordning saker faktiskt blir lästa + kompilatorn kan göra liknande optimeringar, är OK i program som kör på en CPU-kärna men i en tråd som kör på en annan CPU-kärna kan "se" en sådan optimering). Motsvarande för skrivning till A så garanterar SC att alla tidigare läsningar/skrivningar garanterat är utförda innan (happens before, a.k.a release barrier) skrivning till A sker.

Att göra skrivningen är dyrt (lång latens) på alla CPU-arkitekturer, men även SC-läsning är dyrt på nuvarande ARM (men inte på x86, SPARC och IA64)!! Detta kommer fixas i 64-bitars ARM, men detta betyder att många CPU-kärnor är speciellt krångligt att hanterar på ARM (PowerPC och MIPS har samma problem). Lite intressant då att Intel står på samma sida som Qualcomm i den diskussion...

Precis, Cortex A15 verkar lite väl strömslukande för att sitta i riktigt strömsnåla saker så man har tagit fram detta koncept. Problemet är att latensen mellan att byte från LITTLE kärnan till big kärnan är långt ifrån försumbar, så man vill inte göra det ofta. "Fusket" som Samsung blev påkomna med att utföra på benchmarks i Android var till stor del att undvika denna kostnad genom att tvinga telefonen att alltid köra på A15 kärnan.

Detta är dock inget som hjälper skalning över flera CPU-kärnor och Apple, Qualcom och Intel anser alla att big.LITTLE är för komplicerat och har för många nackdelar mot att göra en CPU-kärna som skalar från extremt låg strömförbrukning till hög (för att vara en mobil CPU) prestanda.

Komplicerat == dyrt == kommer inte hända på billiga SoCer inom kort.
Till viss det finns sådan HW, jobbar med system som har 4-32 CPU-kärnor där man bl.a. vill sprida ut nätverkstrafik (ett paket tar typiskt 200 till ett par tusen cykler att hantera, kostnaden för inter-CPU kommunikation är 100-tals cykler...). Detta går inte att göra enbart med logik i CPUn, man måste ha speciellt HW som separerar de olika nätverströmmarna innan de ens når CPU. Ett sådan nätverkskort kostar mer än de flestas spel-riggar...

Sedan har man detta
Unfortunately, the fifth difficulty, the high cost of communication relative to that of processing, remains largely in force. Although this difficulty has been receiving increasing attention during the new millennium, according to Stephen Hawking, the finite speed of light and the atomic nature of matter is likely to limit progress in this

I.e. det är mer eller mindre bevisat att den delen av svårigheten att jobba med multicore kommer nog aldrig lösas, även om man gör framsteg så är det två ungefär tiopotensen som skiljer innan kostnad (svarstiden) för kommunikation hamnar på en nivå så den är ungefär lika snabb som en CPU lokalt kan utföra beräkningar.

PS var lite off med mina 20 år ovan, börjar bli gammal... Tiden ska vara ungefär 25-30 år, men resultatet är detsamma.

Antar att du refererar till x86 med "uråldrig kärna". ISA-designen på x86 är definitivt komplex och inte alls lika elegant som t.ex. PowerPC eller MIPS. Men 32-bitars ARM är också ett härke utan dess like, så för mobila enheter ser det ut som om de två sämst designade ISA kommer "vinna"... Det positiva för både x86 och ARM är att AMD64/Intel64 städade upp de majoriteten av de missar som faktiskt spelade någon roll. Av allt att döma kommer samma sak hända med 64-bitars ARM, som är mer likt MIPS än det är likt 32-bitars ARM.

I fallet x86 vs ARM så har den senare fördelen av att vara enklare att avkoda instruktionerna (precis som i alla RISC) alltid är fix storlek (4-byte för Aarch32), men x86 har fördelen av att den genomsnittliga längden på instruktioner är <4 bytes + man utföra operationer mot minnet med en instruktion (tar 2 instruktioner för fetch-op och 3 instruktioner för fetch-op-store) så program tar mindre plats och en L1-hit drar mindre ström (och är snabbare) än en L2-hit som drar mycket mindre ström än en RAM-access.

Och i kontext av denna diskussion blir det ju lite fel att kalla x86 för uråldrig då det är den arkitektur av x86/32-bit ARM som har bäst förutsättningar att ge program som faktiskt kan använda många CPU-kärnor...

Det sagt: ISA är långt mindre viktigt än alla flamewars på Internet gör sken av. Det som spelar absolut mest roll är kapaciteten på heltals ALU + kvalitén på minneshierarkin (CPU-cache + RAM-buss).

Designen av själva CPU-kärnan (back-end) är i princip helt oberoende av front-end (där olika ISA hanteras) så ingen modern CPU kan därför sägas köra på en gammal design. Tittar man på Silvermont, som till viss del är specifikt designad för att köra Android, så ser man att det grundläggande byggblocket är en 2-kärning design. Ett 4-kärnig har i princip två separata 2-kärniga CPUer, något som ger lägre strömförbrukning när 1 eller 2 kärnor används då man kan totalt power-gate den andra delen (inklusive L2-cache som är separat per 2 kärnor). Är rätt säker på att man designade så för man vet att ytterst få applikationer kan använda mer än 2 kärnor, men man vet också (från erfarenhet med bl.a. Medfield/CloverTrail) att folk automatiskt tänker 4 kärnor måste vara > 2 kärnor så ur den synvinkeln måste man hålla jämna steg med konkurrenterna...

Det enda positiva man kan säga om 8-kärniga ARM SoC är att de är uppbyggda som två 4-kärniga kluster (separat L2-cache per kluster), så man kommer effektivt kunna power-gate hälften av alla kärnor. Men det är transistorer som skulle kunna används betydligt bättre...

När man pratar om "CPU-kraft" är det bra om man specificerar vad man menar. Har aldrig sagt att inga system ska köra med många CPU-kärnor, men man kan grovt dela in problem i två klasser:
1. de problem man vill uppnå minimal latens
2. de problem man vill uppnå maximal "throughput"

I system som är interaktiva är 1. det viktigaste, majoriteten av alla appar vi kör på mobiler och pekplattor hamnar i den klassen. För att uppnå minimal latens när vi prata om tidsrymder i millisekundskala (vilket åter igen är fallet för mobiler/pekplattor) så är det i princip kört att dela upp problem över flera CPU-kärnor, så för att optimera detta ska man ha så hög enkeltrådprestanda som bara är möjligt.

Vissa problem som normalt inte effektivt går att dela upp, t.ex. nätverk + hantering av lager 4 (TCP hör hit), kan man flytta till klass 2 genom att tillåta sig införa en del latens då det gör det möjligt att flytta relativt många paket när den dyra CPU->CPU kommunikationen sker (i.e. man sprider ut kostnaden så den effektiva kostnaden per paket blir OK). Problemet med detta är att man måste öka latensen, så det är direkt olämpligt i ett program som en människa direkt interagerar mot, och det är allt annat än enkelt att skriva sådana program så det blir dyrt. Vidare blir lösning man får fram inte helt allmängiltig, inte ens fast man har hjälp av speciell HW. Vissa fall hamnar på "fel" CPU-kärna, något som måste upptäckas och hanteras (==komplicerat).

Inte för att det är viktigt för denna diskussion, men en "governor" styr inte hur många kärnor som ska användas, den specificerar vilken policy som ska användas för att ändra frekvensen på CPU-kärnorna med avseende på aktuell last.

I din länk står
In computers, Governors are a little more intelligent than just capping the top speed. Instead, these Governors are a set of policies that allow the system to adapt to conditions and adjust the CPU frequency accordingly.

Annars kan du även titta i <linux_src>/drivers/cpufreq/cpufreq_[ondemand|performance|powersave].c. Linux kan ta bort/lägga till CPU-kärnor under drift, kallas CPU-hotplug, men det är ingen som används av dessa CPU-governor.

Även om att förändrar antalet CPU-kärnor är möjligt under drift (används på t.ex. Tegra3 för att switcha mellan 4-kärnor och companion-core) så är det ganska dyrt (hög latens) så är något man vill ha ganska mycket hysteres på.

Om din definition på bra utveckling är: vad som helst som inte Intel "kommit på" så kan jag definitivt se fördelen med både 4- och 8-kärnorns mobiler

Personligen vill jag ha en så bra upplevelse som möjligt och väljer den tillverkare som för tillfället tycker är bäst. Idag skulle jag definitivt välja en telefon med Snapdragon600, men det SoC skulle vara ännu bättre om fler använde den 2-kärniga varianten...

Titeln är säger att 8-kärnor är korkat, det jag skrivit är att givet vad vi har idag (och antagligen kommer göra under många år framöver) så är två kärnor optimalt och 4 kärnor är inte bra för något annat än PR då 2 av kärnorna kommer i extremt nära 100% av fallen göra absolut ingenting mer än dra (lite) ström och ta upp plats som kunde används till annat (t.ex. öka IPC och/eller öka klockfrekvens).

Anledningen att jag ändå tycker Snapdragon600 är det bästa SoC för mobiler man kan hitta idag beror på att det är väldigt strömsnålt, innehåller en GPU som är mer än tillräckligt snabb och absolut viktigast, med hänsyn till denna diskussion, det är det SoC för mobiler med bäst enkeltrådprestanda du kan hitta. Enyxos Octa ligger på samma nivå vad det gäller enkeltrådprestanda, men drar mer ström och big.LITTLE lägger till latens när man går från "idle" till "active" så den "känns" inte fullt lika snabb som Krait300 trots vad benchmarks visar.

Jag är inte emot utveckling och definitivt inte emot CPUer med många kärnor (mitt jobb är att skriva programvara som kan utnyttja många CPU-kärnor på ett effektivt sätt). Säger bara att en mobil/pekplatta är inte det ställe där många kärnor är vettigt då det är ett system som ska optimeras för latens och inte "throughput"!