Windows og Linux egner sig ikke til 8 kerner

myplacedk (44) skrev:

Hvis jeg har én tråd, som tager al den CPU den kan få, trækker den 50% af mine to kerner.
Laver jeg to tråde, trækker de begge 50% på hver kerne.

Det lyder som om de har et pænt stykke optimeringsarbejde liggende foran sig.

Hvis man kun kører én CPU intensiv tråd, så bør den forblive på samme CPU hele tiden. For når den bliver på samme CPU, så vil der være større chance for at de data den skal bruge allerede ligger i cache.

Kører man to CPU intensive tråde bør de for det meste have hver deres CPU.

Nogen gange kommer der små opgaver der lige skal bruge nogle få mikrosekunder CPU tid, og det kan godt interrupte en CPU og resultere i at en tråd derfor bliver flyttet. Det er OS kernens opgave at sørge for, at det ikke forekommer.

I nogle få tilfælde kan det give mening at køre to CPU intensive tråde på samme CPU. Det giver dog kun mening, hvis de kommunikerer så meget med hinanden, at kommunikationen ellers kunne blive en flaskehals.

Husk nu - en CPU er en komplet enhed, altså med cache, controller, bro og hele pivetøjet. En kerne er en del af en CPU. Der er stor forskel.. De fleste PC'er idag, har én CPU, få har to... Jeg tror ikke der laves PC-mobos der understøtter mere? Jeg har mindes ihvertfald ikke at have set dem. Og så er det Intels HT-tek., der intet har at gøre med nogen af delene, men blot emulerer (stærkt forsimplet) en fordobling af kerner.

Husk det lige til resten af diskussionen - at holde begreberne i de rigtige kasser hjælper til at holde diskussionen på sporet. :-)

nyx (52) skrev:

Husk nu - en CPU er en komplet enhed, altså med cache, controller, bro og hele pivetøjet. En kerne er en del af en CPU. Der er stor forskel..

Set fra OS synspunkt er der ikke den store forskel. Et OS kunne sagtens implementeres på en måde hvor det overhovedet ikke skelner mellem om kerner sidder på samme CPU eller på forskellige CPUer.

Performance mæssigt kan der være forskelle. De to cores der sidder i en chip kan deles om nogle af cache lagene. Men med den måde L1 cache normalt implementeres på, så er det umuligt for to cores at deles om L1 cache. Jeg ved ikke om de kan deles om L2 cache.

De første multicore CPUer var vist nok lavet sådan at alle niveauer af caches var seperate til hver CPU. Men der er performance at vinde ved at to cores deles om en cache. For det første vil cache lines som begge ville have i deres cache kun skulle ligge der én gang. På den anden side bliver det compliceret at afgøre hvilke cachelines der skal smides ud. Må en core have lov at monopolisere cachen? Hvis den ene core er idle, eller kører kode med et meget lille working set, ville det være ok at lade cachen fylde op med data som den anden skal bruge.

Det er lidt skræmmende, hvor meget man kan finde ud om, hvad en anden process foretager sig, blot ved at måle på cache performance. Man kan så vidt jeg ved bryde mange AES implementationer ved at måle på cache performance. Det gælder i øvrigt uanset om processerne kører i parallel på to cores med delt cache, eller om de kører med time slicing på en enkelt core.

De fleste PC'er idag, har én CPU, få har to... Jeg tror ikke der laves PC-mobos der understøtter mere? Jeg har mindes ihvertfald ikke at have set dem.

Der findes mange boards med fire CPU sokler. De er primært rettet imod servere.

Og så er det Intels HT-tek., der intet har at gøre med nogen af delene, men blot emulerer (stærkt forsimplet) en fordobling af kerner.

Set fra OS side er der mig bekendt heller ingen forskel i det tilfælde. Men HT performer ikke nær så godt som to fysiske cores. Så for at opnå god performance er OS nødt til at holde styr på om to logiske processorer er i samme fysiske core.

F.eks. vil to processer kører hurtigere hvis de scheduleres på to forskellige cores end hvis de scheduleres på to hyperthreads på samme core.

I de situationer hvor man så faktisk bruger begge hyperthreads vil de kører langsommere fordi de deles om afviklingsenheder. Derfor er det vigtigt, at når man har brug for busy loops (f.eks. spinlocks i kernen), så skal man en gang per gennemløb afvikle en bestemt instruktion, der fortæller CPUen, at den skal bruge flere resourcer på den anden hyperthread.

Så vidt jeg husker manglede teknologien en mulighed for at prioritere de to threads. Normalt vil resourcer deles ligeligt imellem dem. Men hvis der er tale om processer, der har forskellig prioritet på OS niveau, så ønsker man som regel, at den med højest prioritet kører med samme hastighed som den ville have gjort, hvis den havde haft den CPU core for sig selv. Det ville være smart, hvis OS kunne fortælle CPUen om den skulle køre med ligelig fordeling af resourcer imellem de to hyperthreads, eller om den ene skulle køre med fuld hastighed og den anden kun får hvad der er til overs. Men så vidt jeg ved findes der ikke sådan en feature i hyperthreading teknologien.

En måde man kunne bruge hyperthreading på var at lade den ene hyperthread udelukkende håndtere interrupts, og den anden udelukkende køre processer. De eneste interrupts som den med processer så skulle modtage skulle så være IPI fra den anden hyperthread når der var brug for preemption. Jeg aner ikke om der er nogen OS der har afprøvet hvordan det ville virke, så jeg ved ikke om det giver mening fra et performance synspunkt.