Linus Torvalds sågar fler processorkärnor

Även då har man inte speciellt mycket nytta av det, egentligen.

Titta på din cpu-användning och se hur ofta datorn går över 50% totalt. Just nu har jag Wolfenstein på ena skärmen, en youtubefilm och det här browserfönstret på en annan, och på den tredje är spotify (pausad, men lyckas ändå dra 4% CPU). Min totala CPU-användning ligger på under 30%.

Däremot så är ju prisskillnaden så minimal att det inte direkt finns någon mening med att inte köpa den dyrare, för de fall där man faktiskt använder flera cores (säg, packar video eller liknande).

Bara att slänga min nyinköpta 5820 processor i skräplådan å skaffa nåt annat då

Extremt låg, eftersom på den tiden så fick varje ny generation 2x mer transistorer, ungefär.

Och 640k var aldrig ett mjukvaru problem.

Däremot så var det ett rätt stort problem för x86-program som körde i icke-protected mode på de fösta CPU:erna, eftersom de inte hade mer än 20-bittars addressbuss, det är därför rätt omöjligt för dem att komma åt mer än 1Mb.

640k kommer från att adressutrymmet var uppdelat i två områden, ram och "allt annat".

I det andra området fanns det plats för hårdvaran som man kunde accessa direkt (384K total max, då) t.ex. grafikminne och så.

Så det är begränsningarna i de första x86-cpu:erna som satte gränsen till 1Mb, och det är moderkortens val av adressering som bestämmer vilka adresspinnar som går vart, i princip. DOS var egentligen inte inblandat alls. 286 och uppåt hade 24 bittars bus, och en MMU som kunde mappa om vilket minne som gick att komma åt från ett specifikt program (i icke-protected mode var det fortarande bara max 1Mb dock)

På samma sätt har de senare 32-bittars CPU:erna begränsningar (istället för 20, sedan 24 bittars minnesbuss var de 32-bittars följt av 34-bittars), och man var tvungen att dela addressutrymmet mellan RAM och annat.

Och våra nuvarande "klient" 64-bittars CPU:er har oftast 36-bittars minnesbuss delad mellan RAM och annat.

Av ekonomiska skäl. Inte för att någon tror att ingen någonsin vill ha mer minne. Utan för att det _just nu_ inte är direkt relevant att supporta mer.

Ok, jag som inte är ingenjör eller raketforskare (som alltid man jämför med), för att tala enkelt barnspråk med mig - min 4790 var helt onödig eller? (inte för att jag skulle gjort något bättre med den stackars tusenlappen jag hade sparat) Även i Photoshop där benchmarks pekar på andra resultat. Vad vet jag..jag är nöjd i alla fall..;)

På många sätt skalar dock HT bättre än faktiskt kärnor. Även i såna server-saker som transcodning av webbsidor ger HT ungefär 80% bättre prestanda än icke-HT, men elförbrukningen ökar bara med 10%. Så, ja, det ger lite mindre än faktiska kärnor, men väldigt väldigt billigt sett till kisel och elförbrukning. Det är ett bra sätt att gömma minneslatensen.

På vilket sätt skulle HTT hjälpa dig då menar du? Hur många skärmar du använder är det väl ändå GPU som avgör vad du klarar av, har ingenting med fler trådar att göra. Det gick att multitaska på single core CPU'er med.

Det är därför man brukar ha väldigt många hårddiskar i raid och har ramdrive m.m

Annars är detta flaskning intressant. Jag är knappast ensam om att ha program som går segt (med segt det tar många timmar att kompilera), fast processorn knappt utnyttjas enligt windows och det har inte så stor betydelse om man kör från SAN med över 10 hårddiskar, SSD eller vanlig mekanisk hårddisk. Och man undrar vart tusan ligger flaskhalsen?
-Det finns många förklaringar, min misstanke är dock att windows prestandamätare är kass på att avgöra om enskilda delar i en cpu är överbelastad. Så om det står att man använder 30% av en kärna så kanske det inte finns någon kraft alls kvar i kärnan för att göra jobbet snabbare och den ändå flaskar?
På samma sätt som när nätverkspel laggar så kan man inte enbart se på hur mycket nätverket enligt windows är belastat.

Mjo, fast så fort man pratar om kluster, speciellt när de är på flera olika kontinenter, blir lås lite väl segt.

Och share-nothing är kanske lite väl hårt beskrivet, även om det är rätt hype just nu, read-almost-only data är vad man oftast har i praktiken, även om man kanske rent konceptuellt kapslar in det hela i meddelanden eller liknande.

Men så fort man har flera olika separata CPU:er i datorn (inte cores) har man ju i praktiken klustrade datorer när det gäller x86 (NUMA).

Lås blir då rätt enkelt väldigt dyra, så om man vill ha avsevärt mer än de 8-16 cores som är standard nu för tiden använder man allt som oftast icke-lås metoder för saker som hashtabeller etc, och försöker separera jobbet i flera oberoende trådar/processer/whatever som inte behöver skicka speciellt mycket data.

Men det jag kommenterade vad just användet av mutex-lås i originalinlägget, just mutex-lås och context-switching är inte ett störe problem för att parallellisera saker. Mutexar för att man kan designa bort dem i princip helt, och context-switching dels för våra datorer är rätt bra på det (till en viss gräns) och dels för att det ändå inte är så där speciellt användbart att ha avsevärt fler beräkningar igång samtidigt än man har cores ändå. Så om man har 1000 saker som vill ha 100% CPU körandes samtidigt så är just context-switchnigen inte direkt det största problemet man kommer ha om man inte har 1000 cores.

Tja. Microsoft Visual studio, om det är det du använder, är inte speciellt bra på parallell kompilering. Så det är nog din flaskhals.

Tja, nja? Sant, att det är 100% betyder inte att hela kärnan används. Det kan vara bra mycket mindre om det hela är RAM-bandviddsbegränsat, t.ex.
Men om det står 30% idlar CPU:n 70% av tiden.

Det är nämligen det den mäter, 100% betyder att den kör _något_ som inte är idle loopen 100% av tiden.

Så, ganska precis tvärt om. 30% betyder att den kärnan kan göra jobbet minst 3.3ggr snabbare om inget annant ställer till det.

Det har mer att göra med att det mäter belastningen på ditt nätverkskort, inte på ditt nätverk, din router, mediakonverter, alla nätverk och routrar mellan din dator och servern, serverns belastning och saker som databasservrar servern använders belastning etc.

Menar bara att man vanligtvis kanske kör fler samtidiga program än den "normala användaren" om man har flera skärmar, inget annat, kanske lite därför de flesta kör som kör flera skärmar gör det. Jag generaliserar säkert.

En extreme hyperthreading dodeca core med super extreme retina 3D-turbo samt extra stor L2-cache... i en telefon! Praise the lord and keep the marknadsföringsord flöda så man kan lapa mer av den sötsmakande elitismen så man kan stilla behovet av att ha det bästa utan något egentligt behov mer än njutningen av att får köpa och äga det Strömförbrukning? Tänd på lite mer uran så löser den biten sig.

Så klart att jag inte vet hur skillnaden är på deras nya octa, har heller inte påstått annat mer än hur pass klenare den befintliga är i jämförelse, vad Samsung säger (för att sälja in sig) och vad folk spekulerar i innan de ens finns tester struntar jag helt i.

Läs cardeci's inlägg på #62

Detta var intressant då fick jag lära mig något nytt, jag trodde ej den mätte idle tiden.

Men om man har program som kompilerar filer och tar timmar där varken cpu eller hårddisken är flaskhalsen så vad är då kvar? (cpun ligger på runt 30% och gå från ssd till mekanisk påverkar ej så mycket) I alla trådar har folk sagt att snabbare ramminne knappt hjälper någon.
Även om kompilatorn är dåligt skriven så finns det en hårdvara som begränsar hur fort den kan exekvera.

Du behöver få ditt byggsystem att bygga filer parallellt.

Med unixa (egentligen gnu make) system så går oftast det ut på att skriva 'make -j<nuffra>' istället för 'make'. Nuffra är hur många samtidiga kompileringar den ska köra ( cores+2 är rätt lagom).

Med Visual Studio kan man fippla runt i options->project->build nånstans för att ställa in det.

Märk dock att om dependencies i kompileringen är uppsatta fel (eller, rätt om man har otur) kanske den inte kan kompilera mer än en fil itaget ändå.

Och i alla fall så kommer det inte gå snabbare om det bara är en fil som kompileras, kompilatorer är inte speciellt parallelliserade just nu (även om det till viss del går att göra saker som optimering av individuella funktioner samtidigt, även om det skulle dra .. rätt mycket .. RAM om man inte är väldigt försiktig)

Nu i janurirean så finns en dator på en av våra största elkejdor.

Processor: Intel® Celeron™ J1900 Quad Core, 2,0-2,41 GHz
Grafik: Intel HD Graphics
Minne: 8 GB DDR3

Det är väl lite datorn ovanför som Linus Tornvald syftar på då den för okunniga kan se ut som värsta gamingdatorn. (den är dock skitbillig)

Anledningen till att han har ganska rätt är att många program är rätt sekventiellt skrivna(mycket kod körs inte på flera trådar och därmed inte på flera CPUer). Men visst finns det prestanda att hämta vid exempelvis sex kärnor istället för fyra men i de flesta program är denna skillnad liten.

Vilket jag passande kan visa med just Amdahl's lag för parallelisering(körning på flera CPUer)

S = Teoretisk andel prestandsökning jämfört mot en kärna.
N = Antal Processorer
P = Delar av programmet som kan multitrådas och därmed dra nytta av parallelising

25% av koden skriven multitrådat
Sex kärnor: 1/(0,75+0,25/6) = 1/0,792 = 1,26
Fyrakärnor: 1/(0,75+0,25/4) = 1/0,8125 = 1,23

50% av koden skriven multitrådat
Sex kärnor: 1/(0,5+0,5/6) = 1/0,583 = 1,71
Fyrakärnor: 1/(0,5+0,5/4) = 1/0,625 = 1,6

75% av koden skriven multitrådat
Sex kärnor: 1/(0.25+0,75/6) = 1/0,375 = 2,67
Fyrakärnor: 1/(0,25+0,75/4) = 1/0,4375 = 2,29

Som ni ser så är sex CPUer bara 3% snabbare än fyra CPUer när programmet som körs är skrivet till 25% i multitrådad kod. Denna skillnad springer sen iväg till 38% prestandaökning när 75% av koden är skriven multitrådat. Dock så är det mer sannolikt att programmen som körs är skrivna till större delen i sekventiell kod och därmed problemet.

Hur tycker ni det är vid fler kärnor vid realtidstillämpningar. Där just spel är en sådan vanlig applikation, dock inte den allvarligaste.

Det är en sak hur snabbt en cpu kan exekvera ett program, men det är en annan att kunna garantera att alla delar exekverar inom en bestämd tid. Där min uppfattning är att fria kärnor med bra marginal över för olika trådar är bra för att säkerhetställa ens realtidskrav. Förenklat så ju fler trådar på varje kärna, ju större är risken att ens viktiga tråd inte får exekvera omedelbart och så länge som den behöver för att uppfylla realtidskraven.
Nu är som sagt spel kanske inte det allvarligaste realtidssystemen, men det finns många andra där man kan missa viktig kommunikation..

Oja, jag vet att windows suger att köra realtidssystem på.