Hyper-Threading, PROHARDVER! módra
Mindezek után felmerül a kérdés, hogy optimális esetben növeli-e (és ha igen, mennyire) a feldolgozás sebességét a Hyper-Threading, s ebből mennyi írható a párhuzamosítás, mennyi a hardveres multitaszking számlájára. Erre egy egyszerű, saját készítésű, külön ehhez a cikkhez (teszthez) tervezett tesztprogramot használtunk. (tapsvihar, a szerkesztők szerényen mosolyognak, megadják a linket a programhoz)
A specifikációk szerint két szál használhatja egyszerre a HT-gel ellátott processzor végrehajtóegységeit. Azaz két FPU végrehajtóegység esetén lehetséges, hogy az egyik szál az egyik, a másik szál pedig a másik végrehajtóegységeket használja. Ennek természetesen csak akkor van jelentősége, ha az a szálrészlet, amely például FPU-t használ, szálon belül nem párhuzamosítható, mert ha igen, akkor HT nélkül is ki tudja használni a processzor erőforrásait, erre való a szuperskalár (több, azonos típusú pipeline-os) működés. Tehát ahhoz, hogy megmérjük, mennyit tud maximálisan gyorsítani a HT technológia, két nem párhuzamosítható szálat kell futtatni.
A párhuzamosíthatatlanságot (milyen szép szó) úgy biztosítottuk, hogy egy szál nem csinál mást, mint egy adott (egész vagy lebegőpontos) számokból álló tömbön végez műveletet, és az összes műveletvégzés cikluson belül történik, ráadásul a ciklus nem párhuzamosítható. Az integer egységet megdolgoztató rész szorzásokat és összeadásokat végez, míg a lebegőpontos egységet terhelő gyökvonást és trigonometrikus számításokat. A szálak "HIGHEST PRIORITY" beállítással futnak, mivel a "TIME CRITICAL" már a futási idő mérését is megnehezítette. Mindenképpen biztosítani kellett, hogy szálak egyszerre fussanak, így először a program az FPU és az ALU sebességét összehasonlítja, és ehhez igazítja az elvégzendő műveletek számát. A szálak együttes indítása hand-shakinggel (kézfogásos módszerrel) történik, azaz "szólnak" egymásnak, és amikor mindegyik "készen van", akkor kezdik a számolást. Az eredmény a futási idő hossza. Ennyit a programról, beszéljenek az eredmények:
A Hyper-Threading nélküli futásidők úgy növekednek, ahogy több és több szál fut párhuzamosan, a lassulás egyenesen arányos azok számával. Ez nem meglepő, bármely szokásos processzoron így történne. Emiatt nem jellemző egy programon belül a párhuzamosítás, hiszen az egyprocesszoros gépeknél semmilyen nyereséget nem hozna, csak a programozást bonyolítaná. Ellenben bekapcsolt HT mellett jelentősen megváltozik a kép. Egy szál ugyanolyan gyorsan fut le, ami természetes, ám két párhuzamos szál futási ideje jelentősen kisebb, mint kikapcsolt HT esetén. A különbség körülbelül 50%. Tehát ha HT-es processzorunk van, és két feladatot szeretnénk végrehajtani, akkor célszerű párhuzamosan, mivel a vezérlő ténylegesen képes egyszerre használni több erőforrást, például az egyik szál az egyik ALU egységet, a másik szál pedig az egyik FPU egységet használja. Erre egy HT-gel nem rendelkező processzor nem lenne képes (abban az esetben, ha a szál egy feladata belül nem párhuzamosítható). Több, azaz 4, 8 stb. szál párhuzamos futtatásánál ugyanúgy érvényesülnek a HT előnyei, de 4 szál pontosan kétszer annyi idő alatt fut le, mint 2, két logikai processzor nem hozhat további gyorsulást, azaz ha >1 szál fut párhuzamosan, akkor maximálisan 50%-os gyorsulást várhatunk.
A HT sebességnövelő hatása tehát igaz, és valóban a párhuzamos feldolgozáson alapszik, a "hardveres multitaszk" pedig nem segíti elő a gyorsulást. Minket meggyőzött arról, hogy van létjogosultsága, megfelelően megírva a programokat jelentős gyorsulás érhető el, főleg ahhoz képest, hogy milyen kevés plusz tranzisztorral, magméret növekedéssel érték el mindezt az Intel mérnökei. Kíváncsian várjuk az első többszálú programokat.
Hogy merre fejlődik tovább a Hyper-Threading, az nagyban függ az egyéb architekturális fejlesztésektől is, mivel semmi értelme 4 logikai processzort alkalmazni, ha nincs mellette 4 FPU és 4 ALU egység, így valószínűleg várni kell a kisebb csíkszélességű gyártás megjelenésére.
(Emvy)
