Linus Torvalds sågar fler processorkärnor

Det Linus snackar om handlar ju dock inte huvudsakligen om antalet kärnor rakt av (särskilt inte om du håller dig i trakterna av dagens CPUer) utan snarare avvägningen mellan färre snabba kärnor (i princip alla vanliga cpuer idag) eller en stor mängd svaga kärnor (isf mer likt dagens gpuer till upplägget). Det Linus säger är att han tycker att det vore galenskap att satsa på en stor mängd svaga kärnor som huvudsaklig beräkningsenhet i datorer för vanliga användare.

"There's this huge body of "knowledge" that parallel is somehow more efficient, and that whole huge body is pure and utter garbage. Big caches are efficient. Parallel stupid small cores without caches are horrible unless you have a very specific load that is hugely regular (ie graphics)."

"End users are fine with roughly on the order of four cores, and you can't fit any more anyway without using too much energy to be practical in that space. And nobody sane would make the cores smaller and weaker in order to fit more of them - the only reason to make them smaller and weaker is because you want to go even further down in power use, so you'd still not have lots of those weak cores."

Jag uppfattar mao det centrala i vad Linus säger som att han inte tror på att ha betydligt svagare kärnor än dagens för att istället kunna ha fler, inte att det konkreta antalet kärnor egentligen är det viktiga för hans argument.

Som jag tolkar det du säger, och det de flesta andra som kommenterar här, så menar ni att "jag vill ha fler snabba kärnor!" vilket i så fall ändå handlar om något annat, dvs högre effekt, osv.

Både Windows och Linux (i alla fall så länge som det inte finns några realtidstrådar) garanterar att varje tråd till slut kommer få köra förutsatt att den är i tillstånd READY (d.v.s inte blockad av något). Realtids OS och Linux om man använder realtidstrådar garanterar däremot INTE att alla trådar kommer få köra, de garanterar bara att den tråden med högst prioritet som är READY kommer få köra.

Och här ligger ett stort problem för hårda realtidssystem: multicore ger typiskt lägre genomsnittlig latens men hård realtid handlar om garantier på worst-case och multicore ställer till det rejält där. Jobbar bl.a. med utveckling av säkerhetskritiska system (flygplan, medicins utrustning etc) och där använder man inte SMP-system på vanligt sätt då det (ännu i alla fall) inte finns något sätt att formellt bevisa att ett system är korrekt (med en viss sannolikhet beroende på hur katastrofal en bug kan vara) om det är möjligt att trådar faktiskt körs samtidigt (multicore). I stället delar man upp systemet i flera, helt oberoende, delar och hårt låser varje sådan del till en egen CPU-kärna. Flera sådana delar kan dela på en fysisk CPU-kärna men då ligger det en s.k. time-partition scheduler som garanterar att de ändå inte påverkar varandra.

Sony och Microsoft valde att använda 2st 4-kärninga Jaguar CPUer för det var vad man hade att tillgå från AMD. Det är betydligt mycket enklare att dubbla antalet relativt enkla CPU-kärnor i en krets jämfört med att öka IPC med säg 20-30% med bibehållet antal CPU-kärnor. Det är också anledningen till att vi nu ser telefoner/pekplattor med 8 CPU-kärnor, det är enkelt att göra, ser bra ut i PR (bevisligen köper ju folk detta). Som tur är verkar trenden vända här, t.ex. så har Nvidia gjort en 2-kärnig krets som består av betydligt fler transistorer än Tegra 3/4 med sina 4 kärnor.

Om du inte har 100% last på ALLA CPU-trådar så finns det överhuvudtaget ingen anledning att ha fler CPU-kärnor, faktum är att det du gör i förgrunden kan bli långsammare av att det finns kärnor som är i "idle". För att förstå hur det kan vara så lär man ha lite grundläggande kunskaper i hur en modern CPU fungerar, de saker som spelar in här är frekvensskalning och CPU-cachen.

Säg att du har en 2 kärnig CPU är lastade till 100%, i detta läge går båda fysiska kärnorna på max frekvens. Du har sedan ett annat system med 4 kärnor där 2 kärnor är lastade till 100% och 2 är lastade till 0%. Nu gör du något interaktivt så GUI-delen ska kicka in en kort stund. Sättet både Windows, Linux och OSX schemalägger trådar kommer göra så att den interaktiva tråden direkt kommer få köra på båda systemen.

I det första systemet får man då en tråd där frekvensen är max (lägsta möjliga s.k. P-state), så kostnaden är en kontext-byte (som är relativt billigt på både Intel och AMDs CPUer).

I det andra systemet kommer schemaläggaren med relativt stor sannolikhet välja en av kärnorna som är "idle" (inte helt säkert på Linux). Den kärnan befinner sig till att börja med i minst C1, i värsta fall (typ laptop/bärbar) i djupare C-state. Det tar då mer tid att bara köra första instruktionen på den kärnan än vad det tog för kontext-bytet i förra fallet. Sedan startar med stor sannolikhet CPU-kärnan i högsta P-state (lägsta frekvensen) och det tar ÄNNU mera tid att byta P-state (typiskt ~10us) än det tar att gå ur C1 till C0 (vilket är ~1us).

Ovanpå detta har Windows (mindre problem i OSX och Linux) en tendens att få OS-trådar att "hoppa" mellan CPU-kärnor om det finns relativt många OS-trådar men ingen använder 100% av CPU-tiden. Detta leder till att saker ibland är cachad på "fel" CPU och vilket sänker prestanda.

Om man renderar eller gör något annat som kan utnyttja många CPU-kärnor till 100% så visst ska man dra till med en CPU med många CPU-kärnor. Men för den stora massan ger det i bästa fall ingenting att ha många CPU-kärnor, i värsta fall drar det mer ström och går (marginellt) långsammare. Själv undviker jag mer än två CPU-kärnor + HT i laptops och liknande, batteritiden blir definitivt lidande när man har 4 kärnor, vilket jag tyvärr har i min nuvarande laptop då det inte gick att välja 2-kärnig p.g.a. att det var en "topp-modell"