Linus Torvalds sågar fler processorkärnor

Mjo, vilket även är anledningen till att det är mest sånt jag jobbar med. Med tanke på att det är just "moln" servermjukvara som jag utvecklar.

Tänk vad mycket Linus kunde få sagt om han inte uttryckte sig och använde ett språk som lokala alkis-Bosse på bänken

Du får fråga någon senior om detta, fr just nu har du gjort en riktig pudel.

Användaren kommer alltid att fråga efter snabbare prestanda (åtminstone tills vi klarar av raytracing i realtid...). Det är inte det som är problemet, utan hur man klarar av att leverera bättre hårdvara. CMOS-teknologin väntas ta slut vid ca 5-7nm enligt alla seriösa bedömare (inträffar sannolikt runt år 2020-2022). Sen får vi hitta på något nytt (om det går). Högre processorfrekvenser slutade vi att få för 10 år sen, så det blev andra former av förbättringar istället (fler cores, o.s.v.).

Problemet är dock att fler cores inte gör signifikant nytta efter ungefär 4 för de flesta typer av applikationer. Ett AI-intensivt spel som Civilization 5 skalar iofs bra med fler cores, men den typiska spelmotorn levererar inte så speciellt många fler fps om du trycker in en 15-kärnig Xeon-processor. Småuppgifter är helt enkelt för svåra att dela upp på flera trådar på ett effektivt sätt. Den stora majoriteten av alla desktop-applikationer kommer därför inte att dra nytta av att öka antalet cores från 4 till 15.

Torvalds har därför en väldigt bra poäng. Det finns givetvis undantag dock, men de är få för den genomsnittlige konsumenten. Istället får man göra något annat för att tillfredställa vår hunger efter högre prestanda. Exakt vad det kommer att bli vet vi inte idag.

Som han själv säger att han aldrig har sagt...

Så är det nog, men är det inte risk för att man har gjort fel™ om man har realtidskrav och ändå väljer att köra ett system som oförutsägbart introducerar slumpmässiga fördröjningar?

Beror på hur hårt det är och har man ens blandat in windows så är det redan kört för att göra något bra.

Men för mer konsumentapplikationer som spel finns det också realtidskrav och det är inte ovanligt med forumstrådar när någon klagar att spelat hackar till enstaka gånger. Och då inte ovanligtvis precis innan någon skjuter en, där nog grafikkortet nog är största boven.

Så även ur konsumentsynpunkt kan jag tycka vara lite fel på att enbart se applikationerna som att de ej har några realtidskrav alls och allt handlar om hur snabbt de kan exekveras.

Om det är så meningslöst med mer än 4 kärnor, varför valde Sony då att använda 8 istället för 4 i PS4?

Och varför finns det vissa PC spel som där man rekommenderas att ha 6 eller 8 kärnor för bäst prestanda?

Fast om man börjar tala om garantier och "omedelbar exekvering" är det väl underförstått att man menar tämligen hårt. Garanterar windows att ens tråd får köra någonsin?

Ingen aning, på min studietid så fanns det applikationer som man kunde köra för att förbättra det.
Ett exempel som jag hittade vid googling: http://www.tenasys.com/overview-ifw

Och min uppfattning då var att realtid på windows fungerade på samma sätt som TCP/IP nätverk inom mer krävande system. Även om man ej kan garantera att ett paket kommer fram inom en bestämd tid, så har fruktansvärt mycket överkapacitet emot vad man behöver ha så risken är liten om man nu kan skydda nätet emot skräpdata.

De system som jag använder så får man enbart ett argt telefonsamtal om något skulle exekveras för sent och resultera i ett larm(t.ex watchdog), det blir ingen härdsmälta eller så precis.. hehe

Enligt grafen ser det ut som prestandan är en tilltagande funktion upp till iaf 16 kärnor innan det blir en avtagande funktion.
Dvs upp till 16 kärnor är prestanda ökningen högre per kärna och efter 16 kärnor ser prestandaökningen ut att bli lägre för varje extra kärna.

Och om parallell portionen är 95% ser funktionen inte ut att bli riktigt avtagande förrän vid 128 kärnor.

...de flesta webläsare flertrådsupport idag, kör normalt Chrome men testade med Opera och IE som jag också har på maskinen. Vet att Firefox 2013 annonserade att de skulle komma med ny avancerad flertrådsupport, men vet inte om det är klart. Safari har det på OS X och gissar att även Windows versionen har det för att kodbasen skall vara så lik som möjligt.

Det faktum att från Opera 10.6, Safari 4.0, Chrome 11.0, Firefox 4.0 och IE 10 det finns stöd för "HTML5 multi-threading capability" via "Web Workers" för javascript, borde innebära att från dessa versioner åtminstone kan webläsarna utnyttja flera trådar.

På samma sätt som WebGL givit "webappar" direktaccess till grafikkorten kommer WebCL ge dem kontroll över flera trådar.

WebGL kommer från OpenGL och WebCL från OpenCL, (Open Grahipcs Library and Open Compute library), men fick begränsas något av säkerhetsskäl.

Just det där verkar väl dock lösa problemet genom att, via någon sorts virtualisering, köra ett eget operativsystem bredvid windows (och sedan på något sätt kommunicera).

Jo, oftast fungerar det ju bra men garantera något kan man sällan (och det var vad jag främst reagerade på).

Nja, funktionen blir aldrig avtagande utan närmar sig 2, 4, 10 och 20 sakta men säkert (ökningstakten minskar dock), så fler kärnor är alltid bättre (om än inte så mycket bättre till slut). Det där är dock ideala fall, så det framgår inte om det till exempel kostar resurser att administrera alla kärnor.

Skitsnack!

Kodar man från början med många trådar i åtanke så går det att utnyttja hur många trådar som helst. Problemet uppstår när man försöker skapa nåt som ska funka även med bara en eller två trådar.

Tja, på sätt och vis. Den vanligaste anledningen till hack i spel är att något måste kopieras från RAM till grafikkortet, eller, några storleksordningar värre, från din SSD till ram till grafikkortet. Eller, helt otänkbart uselt, från din roterande disk till grafikkortet via ram.

Nej, det går inte. Det är bevisat att så inte är fallet, av flera olika anledningar. Kom igen när du läst på lite.

Världens enklaste exempel: Räkna hur många gånger det står "hej " i en fil.

Kom tillbaka när du har ditt perfekt parallella program.

Han har dock rätt när det gäller särskilda nischade applikationer, men de har alltid trådat bra pga instruktionerna är lätt att parallellisera i sin natur, fast jag är medveten om att det inte var det du syftade på.

Ditt exempel så skulle man kunna låta en kärna första skanna filen, för att sedan dela upp den i så många delar du har kärnor, distribuera ut dem och gå igenom det de fick för att sedan sammanställa och presentera antal hej. Fast vi det laget så vore det snabbare att låta första kärnan som går igenom filen räkna dina hej och presentera det innan den skickar vidare till resten av kärnorna

Som en replik till Torvalds utspel så tillhör jag väl till de "få" då som inte kan få nog av CPUer/kärnor på desktop. Å andra sidan så gäller det de flesta i min umgängeskrets också. Hans frågeställningar angående nyttan av mängder av CPU kärnor på Smartphones etc. är jag helt med på.

Det är precis samma sak på majoriteten av folks datorer, majoriteten av dem har ingen användning av fler än 4 kärnor (om ens det).

Exakt! Och hur ska du göra summeringen på noll tid? Det kommer ta log2(n) tid, där n är antalet cores. Så det blir inte exakt parallellt. Och om vi blandar in verkligheten: Jag kan trivialt enkelt skriva ett program som på en core saturerar minnesbandvidden på att räkna "hej", så det kommer inte gå snabbare med två cores.

För att inte tala om om filen är större än ram, och ligger på en SSD eller nåt.

Det är exakt det ahlmdals lag säger. I princip inga problem är exakt 100% parallella. Och även problem som är det till 90%+, som det där filsökningsproblemet på en teoretisk dator med oändligt snabbt och mycket minne, planar rätt snabbt ut allt eftersom man adderar fler cores (se grafen i artikeln).

Och jag tvivlar på att det skulle göra så speciellt mycket skillnad vad för bytekod man matar CPU:n med. Den kan ändå köra vad den vill internt (intels x86 är en load/store arkitektur med 160+ register internt)