Linus Torvalds sågar fler processorkärnor

Nej. I en modern processor så delar varje kärna redan ut arbetet på flera parallella enheter - där varje enhet ligger inuti en kärna. Detta kallas att kärnan är superskalär. Den första Intel x86-processorn som gjorde det var Pentium.

Men hur programmets kod är strukturerad är fortfarande en flaskhals - instruktionerna ligger i ordning och måste fortfarande utföras på ett sätt så att resultatet blir som om de utfördes i ordning. Kärnor har en mängd tricks för sig för att kunna köra en sekvens av instruktioner så parallellt som möjligt, men det är ändå endast högoptimerade loopar som ens kommer i närheten att utnyttja denna parallellism fullt ut.
Numera är kärnor så pass parallella inuti att de flesta enheterna skulle ligga oanvända i vanlig körning. Det är bl.a. därför som man införde symmetrisk multitrådning (SMT) där en kärna kan köra två instruktionsströmmar (trådar, processer, program) samtidigt.

Numera är den största flaskhalsen hur trådar accessar minne, vilket de gör indirekt via cache-minne i processorn. Cache-minne är snabbt medans primärminne är långsamt, och mer kiselarea på en processor används i dag för cache än för kärnor.
Så länge som alla trådar/kärnor vill komma åt samma minne hela tiden som ryms i cachen (vilket de gör i parallelliserade algoritmer) så är allt frid och fröjd, men med flera olika program på olika kärnor som vill komma åt olika delar av primärminnet så måste det bli fler åtkomster till det, vilket slöar ner.

Det finns en avvägning att göra mellan antal kärnor/trådar, storlek på cacheminnet och hastigheten på primärminnet beroende på vilka slags program man kör.
Fler antal kärnor som kör olika program blir inte bättre utan mer cacheminne - och ju mer processorarea som används desto dyrare processor. En Xeon är dyr för att den har mycket area för att kunna ha många kärnor och mycket cache - men det vore overkill att stoppa in en sådan i en telefon eller i en kontors-PC.
Det är en sådan avvägning som Linus Torvalds gör.

Det känns som en något knepig kommentar, tycker den inte helt relaterar till den verklighet jag förstått.

Isåfall skulle väl C och C++ fungerat lika bra att parallisera som occam-π , erlang, eller t.o.m arbetet kring Google Go.

Tycker återigen att man skall vara lite försiktig med bergsäkra kommentarer, det man ser idag med ARM och Intel x64 baserade kärnor, kanske inte är det vi kommer använda om fem-tio år framåt. Saker o ting kan ändras fort i denna bransch, även om det oftast tar enorm tid.

Jag vill bara säga att jag verkligen uppskattar dina inlägg. De är väldigt informativa och lätta att förstå även för en som inte är så insatt.

Han har en del poänger, men som väldigt många andra allt för teoretiska datavetare verkar han aldrig hört talas om något som kallas leaky abstractions. Dagens multicore-system är extrema fall av "leaky abstractions", mer specifikt är minneshierarkin (där cachen ingår) i dessa en sådan.

Sedan är det ännu en i raden som inte riktigt förstår skillnaden mellan "concurrent" och "parallel". Får kontra med en annan Vimeo länk, Rob Pike (en av designerna av språket Go) förklarar väldigt bra vad skillnaden är och att språk som Go och Erlang m.fl. fokuserar på "concurrent programming". "concurrent programming" är användbart även om man bara har en CPU-kärna, det är främst ett sätt att strukturera sina program. "parallel programming" handlar bara om run-time och går ut på att så effektivt som möjligt dra nytta av tillgängliga CPU-trådar, alla "parallel program" råkar däremot alltid vara en form av "concurrent program".

Tror ingen hävdar att det är enklare att koda program som ska använda många CPU-kärnor i C eller C++ än vad det är i språk som Go och Erlang. Men tyvärr är SMP-system extrema "leaky" i sin abstraktion kring att man har N stycken CPU-kärnor som kör i isolation och kan kommunicera både effektivt och med deterministisk hastighet. Faktum är att alla de antagandena är i praktiken fel, det finns enormt kraftiga beroenden och tyvärr så varierar de även mellan de olika implementationer av multicore vi har idag...

Så för tillfället får vi hålla oss till dagens motsvarighet till 70/80-talets assemblerprogrammering (som folk bl.a. höll fast vid för kompilatorer på den tiden sög på att generera effektiv kod), nämligen C eller C++ (och till viss del Java eller C#) där man explicit kan specificera punkterna där man måste ha en viss form av synkronisering mellan två eller flera CPU-trådar. Dessa språk är än så länge ett krav för att få saker som inte är triviala att köra på många kärnor att skala någorlunda väl. Däremot finns det en rad fall (mest för servers) som är triviala att parallellisera och för dessa fall kan man använda många andra språk/plattformar.

Det har varit väldigt mycket tal om Ahmdals lag i denna tråd, men det du är inne på beskrivs bättre av Gustafsons lag: om problemet i den parallella delen av programmet är tillräckligt beräkningsmässigt dyrt så kommer det skala över CPU-kärnor.

Ett väldigt illustrativt exempel på Gustafsons lag i aktion är parallell bygge av ett stort C respektive ett stort C++ projekt. C++ filer är väldigt beräkningsmässigt dyra (tar lång tid att kompilera varje fil) medan C (och även Java, C#, Go m.fl) är relativt sett billiga. C++ projekt tenderar därför skala nära nog linjärt med antal CPU-kärnor medan C projekt slår i andra flaskhalsar vid 4-8 kärnor (lite beroende på hur komplex filerna är i genomsnitt) då saker som läkning och andra I/O operationer är seriella delar.

Sedan är det väl ändå inte entusiasters behov som avtalats i denna tråd, utan "vanliga" användares? För entusiaster finns modeller 8 CPU-trådar och ända upp till 16 CPU-trådar idag.

Fyra kärnor med prestanda X är i praktiken ALLTID sämre än en kärna med prestanda 4X, i absolut bästa fall (trivialt parallellserbara problem) kan fyra kärnors-varianten asymptotiskt närma sig 4X varianten. Har sett flera HW-designers säga att mellan tummen och pekfingret så om valet står mellan att gå från 1->2 kärnor eller ökad IPC så är det senare alltid att föredra för "vanliga" användare om ökningen är 20-30% eller mer. För servers ligger denna brytpunkt högre.

Jag bryr mig inte mycket...

Man lusläser ändå tester och tänker själv, det är sällan jag köper det på pappret det allra värsta. Om man läser att en mobil har 16 kärnor och ser att det finns en exakt lika dan med 8 och den kostar mindre än hälften och har dubbel batteritid... och man ändå kan gör samma sak typ lägga ut en bild på Facebook. Vilken väljer man.

Ungefär samma tänk när det gäller datorer... Jag gör musik och utformar min dator därefter men tycker att i dag kan man slänga på extra allt utan att det flaskar det minsta. Att stirra sig blind på siffror är inte längre aktuellt...

Så nästa dator jag bygger kommer jag att titta mer på att den skall vara tyst och liten än något annat och fortfarande räcker fyra kärnor gott.

Marknaden styr nog och vi är inte helt dumma... annat var det för 15-20 år sedan- Då var man tvungen att fläska rejält på om man ville köra PC . Ångrar i dag att jag inte körde MAC under dom åren faktiskt. I dag är PC bättre skulle jag säga---

I framtiden så tror jag det kommer att hänga mer på god programmering än antalet kärnor. God programmering = effektivisering, det kommer betyda mycket mer.

Linus missar doch en väldigt vikitig aspekt.
Låt säga en 4670k som är väldigt populär. Den har hög IPC och relativt hög klock per kärna, det går inte att göra bättre i dagsläget.
Det enda sättet att få den snabbare totalt sett är flera kärnor bredvid varandra.

Sedan får man inte glömma det kostnadseffektiva perspektivet. Det är kanske billigare med 4 medemåttiga kärnor istället för 2 som är dubbelt så snabba.

Mina synpunkter gäller desktopsidan, angående tex mobiltelefoner håller jag med Linus. Jag hade hellre sett min telefon med bara 2 kärnor.

Efter att ha sett Bret Victor - The Future of Programming (http://vimeo.com/71278954) som länkades ovan vill jag svara dig med följande tanke.
Om vi gör ett system som har massvis med kärnor, låt oss säga 128st eller 1024st, vad kan vi göra då?
Då tänker jag inte på "det vi gör idag * 100" som rendera snabbare samtidigt komprimera filer m.m. utan jag tänker på vad för saker kan vi göra då med dessa 100-tals kärnor som vi inte kan göra idag utan dem? Jag tänker i liknade banor som att gå från dos till windows (terminal till gui), 2d till 3d, virtualisering och liknande.

Från denna artikel.

Tänk på Ahmdals respektive respektive Gustafsons lagar på detta sätt:

• Ahmdal du har en specifik uppsättning problem du vill lösa och vill få en uppfattning om hur vettigt det är att snabba upp beräkningstiden för dessa problem genom att addera fler CPU-kärnor till din dator.

• Gustafson du har en fet maskin med massor med CPU-kärnor och vill veta hur pass stora/komplicerade problem du minst måste ge till systemet för att det ska effektivt kunna utnyttja sin beräkningskraft

Det andra fallet är för väldigt nära 100% av desktop-användarna inte relevant, vi jobbar med program där vi inte har kontroll eller bara har marginell kontroll av problemets utformning. Det är också förklaringen till varför 2-4 kärnor är fullt tillräckligt för de flesta, de problem vi jobbar med är inte tillräckligt beräkningsmässigt tunga utan de är mest begränsade av att lösa ett relativt enkelt problem på kortast möjliga tid (för att undvika "lagg").

Har man beräkningstunga komplicerade problem så kan man mycket väl ha väldigt mycket nytta av tusentals CPU-kärnor. De som ofta transkodar fil och liknande kan definitivt dra nytta av 8-16 CPU-kärnor. Använder man mest datorn till surf och liknande är 2 kärnor mer än nog.

Visst har det betydelse, både OSet förbättring och dens... mög i bakgrunden.
Förr satt man ju timmar med W2k och XP och stängde av allt man kunde, för att den en kärna CPUn man körde på skulle orka med spelet man ville spela. NAturligvis bestämdes sig Windows för att när man spelar är en utmärkt tillfälle att defragmentera, uppdatera, indexera, rapportera och allt annat den kunde få för sig.

Idag är 2+ kärnor ett krav för mig, just pga detta. Man kan göra det man vill, och låta OSet göra typ vf det vill, så länge det inte stör mig. När man fick 4(3) kärnor var det faktiskt förbättring igen, pga nu kunde 2 tråd spelen flyta på bra, samtidigt som OSet hade en kärna att leka med. Hade funkat med 3, men Q9550 var 4. Nu dock.. är "belöningen minimal." Få spel utnjyttjar 4 kärnor perfekt, och ännu färre fler än 4 kärnor. Och även om OSet gärna vill ha iaf en kärna till sitt mög bakom, så räcker 4 kärnor otroligt långt, även till spel.
Tror inte vi kommer inom snar framtid behöva 8, eller iaf 8+.

Dock är en viktigt poäng sagd här. Vi gör fler saker samtidigt idag. Vi har youtube på en skärm, spelet på en, och forum på den tredje skärmen. DÅ och endast DÅ, är 8 kärnor av intresse imho, dvs när inte bara våra program parallelliseras, utan även vår konsumering av den. Dvs, VI börjar bli multitrådade...

Problemet är ju, som Lunus påpekar, vi gör inte detta i vår telefon... Det finns alltså inget behov av så många kärnor i en telefon/surfplatta. 4 lär starka kärnor lär räcka enormt långt där.

Det blir till att multitaska uta H... eller så kan jag väl bjuda 1kr för den

Du verkar ha bra koll, så jag förväntar mig att jag bevisas fel, men...

Jag har alltid trott att begränsningarna var pga både mjukvara och hårdvara. Mjukvaran (DOS) var ju 16-bit, och därav hade sin begränsning med det. Det var ju först när Windows 95 kom som 32-bitars mjukvara började köras, som då kunde hantera mer minne, samt att den hanterade minnet på ett annat sätt. (Du kunde tex köra 2 DOS fönster med vars 640kB minne som bas + expanderat).

Dock kan du ha helt rätt i att 640kB aldrig var mjukvaru begränsning, men detta minne var ju bas minnet även långt in i 486 tiden, i mjukvaran DOS. Sen fick man ju köra expanderat minne för att få det RAM vi känner till idag. Och man var tvungen att ladda drivare som gjorde att DOS kunde använda det, för att sedan spel/program skulle kunna använda det.
Eller?