Positive labresultater på AMDs 12-kjerne

[Simen1]

(om windows klarer å delegere applikasjons tråder til en annen CPU, noe jeg er litt usikker på)

Null problem. Selv Windows klarer å fordele tråder mellom mange prosessorer. De vanlige desktop-utgavene er begrenset til maks 1 eller 2 sokler avhengig av versjon, mens server-variantene kan kjøre inntil 64 sokler (avhengig av versjon).

 

NUMA (som først kom til Windows-verden med Win XP x64 Edition) kan til og med prioritere programmenes minneområder i forhold til hvilken prosessor minnet er koblet nærmest. Hensikten er å minimere latency og minimere flaskehalser som HTT-busser og FSBer.

[Theo343]

Det er vel ingen her som tviler på, håper jeg, at det er problemer med å finne gode arbeidsområder for en 12kjerne? De er det mange av for mange OS plattformer.

Endret 22. oktober 2009 av Theo343

[Gjest Slettet-Pqy3rC]

NUMA (som først kom til Windows-verden med Win XP x64 Edition) kan til og med prioritere programmenes minneområder i forhold til hvilken prosessor minnet er koblet nærmest. Hensikten er å minimere latency og minimere flaskehalser som HTT-busser og FSBer.

Ja, og herunder lå usikkerheten min; Dersom et kjørende program starter en ny tråd vil da denne nye tråden kunne kjøre på en annen CPU ? Minnedelegeringa vil jo kunne utgjøre en liten utfordring siden programmets (main thread) kjører på en annen CPU, en risikerer jo etterhvert voldsomme mengder CPU til CPU kommunikasjon.

 

Har hørt tidligere hørt (hear-say) at applikasjonstråder kun kjører på samme CPU som applikasjonens main thread, men det kan godt være at dette ikke er (eller har vært) tilfelle.

[Simen1]

OSet kan fritt styre hvor tråder skal kjøres og hvor i minnet trådene skal få et minneområde i forespurt størrelse. Ulike OS prioriterer ulikt.

 

Windows 95, 98, Me hadde ikke støtte for flere prosessorer.

 

Windows 2000 hadde enkel støtte for 2 prosessorer, men ikke NUMA. Det viste ikke forskjell på virtuelle kjerner (HyperThreading), fysiske prosesser og flere kjerner på samme prosessor. Det behandlet minnet som ett uniformt område. Det eneste som var noe problem på den tiden var at det burde vist forskjell på virtuelle kjerner og ekte prosessorer i dual Xeon HT systemer. F.eks kunne det finne på å la to tråder i et to-trådet program, kjøre på samme fysiske prosessorkjerne i stedet for på hver sin. Det ga svært dårlig gevinst av å kjøre to tråder. Men man kunne velge manuelt å kjøre på kjerne nr 0 og 2 hvis man visste at disse ikke var samme fysiske kjerne.

 

Windows XP 32 bit og 2003 32 bit skjønte forskjell på fysiske kjerner og virtuelle kjerner. Det forbedret multitrådytelsen i en del situasjoner. Men det hadde ikke NUMA og kunne derfor ikke prioritere minneområder ulikt. Det var heller ikke noe problem før Opteron (2 sokler) ble lansert i 2003, siden det var den første i sin klasse med separate minneområder.

 

Windows XP 64 bit og 2003 64 bit fikk støtte for NUMA. Det vil si muligheten til å prioritere minneområde som hører til den fysisk nærmeste prosessoren. Den hadde som sine forgjengere støtte for å prioritere mellom fysiske og virtuelle prosessorer. Det ble senere patchet for å skjønne dobbeltkjerner og quad-kjerner.

 

Windows Vista, 2008 og 7 skjønner forskjell på virtuelle, fysiske og flerkjerne-prosessorer, samt NUMA for minneområder. Det er også gjort optimaliseringer mot ulike programmer. Men også her er man avhengig av patching for nye prosessorer. Uten patchene vet ikke Windows hvordan prosessorkonfigurasjonen og minneområdene er delt opp og bør prioriteres.

[Gjest Slettet-Pqy3rC]

Ok Simen1, takk for infoen.