Ami a Bulldozer tesztből kimaradt

A Microsoft ütemező frissítése

Már a Bulldozer-alapú központi egységek megjelenése előtt sejteni lehetett, hogy a speciális felépítés okán az aktuális operációs rendszerek nem tudják majd optimálisan kezelni a termékeket. Linuxhoz a nyílt forráskódból eredően szinte azonnal megérkezett a szükséges frissítés, de a Microsoft operációs rendszereihez csak idén januárban futott be a hivatalosan is végleges megoldás.

Hirdetés

A probléma forrása a Bulldozer CMT-alapú multi-threading megoldása, mely egy modulon belül két különálló integer magot és ezek között megosztott front-endet, L2 cache-t és FPU-t vonultat fel. Abban az esetben, ha csak a modul egyetlen magjának oszt ki feladatot az operációs rendszer, akkor az az összes rendelkezésre álló, alapvetően megosztott erőforráshoz szükséges jogot megkaphatja. Így értelemszerűen több erőforrásból lehet képes gazdálkodni egyetlen mag, amivel nőhet a számítási teljesítmény. Természetesen ezzel a tervezők is tisztában voltak, így a koncepciót alapvetően a Turbo Core köré tervezték, amely legalább két, teljesen inaktív "alvó" modul esetén olyan mértékben lett volna képes megemelni az üzemben lévő aktív modul(ok) órajelét (Max Turbo), hogy ez a megosztott erőforrásokból fakadó esetleges teljesítménybeli csorbát kényelmesen kompenzálta volna. Egyelőre gyártástechnológiai problémák miatt ez nem valósult meg, így a maximális turbó órajel sem éri el az ideális, korábban megcélzott szintet.

Ebből eredően néhány, kevesebb (2-4) magot kihasználó alkalmazás nem fut optimálisan a szóban forgó processzorokon. Példának okáért bizonyos, maximum négy magot kihasználni képes szoftverek jelenleg akkor futhatnak leggyorsabban egy nyolcmagos, Bulldozer-alapú processzoron, ha csak minden második maghoz (azaz négy modulhoz) van hozzárendelve a négy szál. Ezzel az adott folyamat a lehető legtöbb, modulon belüli erőforrásból gazdálkodhat, miközben az elsőszintű turbó (All Core) még mindig működésbe léphet, amennyiben a CPU még nem érte el a TDP limitet.


[+]

A szálakat alapértelmezésben az operációs rendszer ütemezője osztja ki az általa látott magok/szálak között, de ebbe szerencsére (vagy sajnos) az adott program készítője bármikor beavatkozhat kézzel, ugyanis ez az úgynevezett affinitás programozási eszközökkel szálszinten is állítható, nemcsak hagyományosan, programszinten (pl. a Windows Feladatkezelőjében látott módon). Azért szerencsére, mivel azok a programok, melyek készítésénél törődnek ezzel, ott további eszközök (Windows-frissítés, új ütemező) nélkül már ma is megoldható olyan ütemezés kialakítása, amely teljes mértékben megfelel a programkészítők szándékainak. Viszont azért sajnos, mert amelyik programnál nem törődnek vele, az az operációs rendszerre lesz utalva, ami jelenleg egyetlen általános megoldást tartalmaz csak, ez pedig bizonyos programok számára előnyös, mások számára pedig hátrányos lesz.

Az eddig megjelent Windows operációs rendszerek szokása, hogy amennyiben az alkalmazás nem határozza meg saját szálkezelését, akkor az ütemező az összes mag között folyamatosan dobálgatja a szálakat, ami a mai processzoroknál már korántsem optimális. Ez a fajta működés állítólag még az évekkel ezelőtti, egyetlen magos processzorokból összeállított, több CPU-s rendszerek (szerverek) idejéből való, ugyanis ilyen módon átlagban könnyebb volt hűteni a teljes rendszert, mintha csak egyetlen kis része lett volna folyamatosan terhelve. A modern kor többmagos megoldásainak viszont ez már több szempontból sem megfelelő. Egyrészt amennyiben a szálak folyamatosan vándorolnak a CPU magjai között, úgy azokat még akkor sem lehet hosszabb időre lekapcsolni, ha valójában a teljes processzorra vetített terhelés még az 50%-ot sem éri el. Ennek ilyen esetben a CPU fogyasztása láthatja kárát, valamint Bulldozer esetében a turbó is, ami csak akkor képes huzamosabb ideig a legmagasabb órajelet produkálni, ha legalább két modul úgynevezett C6 módban pihen, azaz teljesen le van kapcsolva.


Windows 7 - 4 modul optimális kiosztás mellett [+]

A jelenlegi helyzet arra késztette az AMD-t, hogy a Microsofttal együttműködve elkészítsenek egy frissítést, mely a Windows 7 és Windows Server 2008 R2 operációs rendszerekhez telepíthető. A csomag első része a KB2645594 jelzésű frissítés, mely a szálkezelésen változtat, azaz először minden modulnak csak egyetlen programszálat oszt ki az ütemező. Második lépésben a KB2646060 nevű frissítést kell telepíteni, ami megakadályozza, hogy a modulok idő előtt teljesen lekapcsolt, C6 módba kerüljenek, miközben végrehajtandó programszálak várnak rájuk. Az ebbe a módba való leállás, majd visszaállás viszonylag sok időbe telik, miközben a modulhoz nem lehet hozzáférni. Fontos kihangsúlyozni, hogy egy négymodulos Bulldozernél egy 6-8 magot kihasználó alkalmazás semmilyen hasznot nem tud húzni az egészből. Ugyanez igaz egy kétmodulos Bulldozer és egy 4 magot kiaknázó szoftver esetében is. Utóbbi szituációban csak egy 2 szálas programnál várhatunk javulást. Mindezek ismeretében kijelenthetjük, hogy az asztali Bulldozerek esetében pozitív hatás csak az enyhén többszálúsított alkalmazásoknál várható, és ott is csak akkor, ha a szoftver készítője a fent említett módon nem határozta meg előre az affinitást.


A Windows 8 feladatkezelője [+]

A fentiektől eltekintve azt leszögezhetjük, hogy a Windows 7 és az azt megelőző Windows operációs rendszerek szálkezelési modellje felett már eljárt az idő, így talán nem is csoda, hogy az év vége felé érkező Windows 8 ezen a téren is változásokat fog hozni. Mindenesetre addig is lássuk, hogy mennyit számít a Microsoft által publikált frissítés!

A cikk még nem ért véget, kérlek, lapozz!

Azóta történt

Előzmények

Hirdetés