SG.hu·2005. november 18.

Fejlesztők szerint lassítja a szervereket a HyperThreading

A processzorgyártó szerint a technológia a többszálas üzemmód révén a szoftverek futásának gyorsítását, vagyis a teljesítmény növelését hivatott elősegíteni, több fejlesztő azonban ezzel ellentétesen vélekedik.

Az érdekes jelenségre elsőként Slava Oks, a Microsoft SQL Server 2005-ön dolgozó egyik fejlesztő hívta fel a figyelmet, aki internetes naplójában korábban részletesen ismertette a problémát. Eszerint tesztelőik - és vásárlóik - érdekes visszaesést figyeltek meg az SQL Server teljesítményében, amely nagy terhelésnél indokolatlanul mértékű teljesítmény-veszteséget okozott, és gyakorlatilag felemésztette a processzor kapacitását. A Hyperthreading (HT) kikapcsolásával azonban egy csapásra normalizálódott a helyzet és a teljesítmény visszaugrott a megszokott szintre.

A szoftver két processzort lát
A helyzet ironikus, hiszen a technológia éppen a teljesítmény növelésére, a programok futási sebességének gyorsítására szolgál, nemcsak a szervereknél, de még az asztali gépeknél is. Ahogy az Intel ismertetője fogalmaz, segítségével gyorsabbá és hatékonyabbá tehetjük PC-nket, mégpedig a processzor erőforrásainak maximalizálásával és két külön szoftverlánc egyetlen processzorral történő párhuzamos futtatásával. Az erre felkészített szoftverek két külön processzornak látják a CPU-t, és ki is használják az ebből adódó lehetőségeket.

A bejegyzésből kiderül, hogy a beérkező jelentések igaznak bizonyultak, és a hiba reprodukálható. Ebből a célból Oks egy rövid példaprogramot is mellékelt írásához, amely alapján a vállalatok eldönthetik, érdemes-e kikapcsolni a HT-üzemmódot. A probléma ugyanis nem mindenkit érint, és gyakorisága nagyban függ a hardvertől és az alkalmazott szoftverektől. A gond az erőforrások, egészen pontosan az első- és másodszintű gyorsítótárak megosztásából ered, például amikor egy rendszerszál és egy "worker", vagyis munkát végző szál fut egyszerre. A HT-technológia alkalmazásakor előfordulhat, hogy az eredetileg szintén a teljesítmény növelésére szánt gyorsítótár nem bírja kiszolgálni a megnövekedett igényeket, ami a sebesség drasztikus csökkenéséhez vezet.

Szerverekről és nagy terhelésről lévén szó, a probléma nem érinti az otthoni felhasználókat. Mindenesetre ismét kitűnően példázza, hogy nem minden arany, ami fénylik. A történetből ismét legnagyobb vetélytársa, az AMD profitálhat, amely ezentúl már erre is hivatkozhat, saját megoldását kínálva alternatívaként.

Kapcsolódó cikkek és linkek

Bejelentették az új HyperTransport technológiát Hyper-Threading: pro és kontra Intel, SiS: HyperThreading támogatású chipsetek Intel: Hyperthreading, fokozott adatbiztonság HyperThreading minden 533 MHz-es FSB-jû P4-ben?HyperThreading az idén megjelenõ 3,06 GHz-es P4-ben Hyper-threading az új Intel Xeon chipekben Intel ↗

Hozzászólások

Jelentkezz be a hozzászóláshoz.

Azt én is elhiszem, hogy a két szál a cache-t kicsit összezavarja, és néha többet dobnak el, mint kéne, és a hibás jóslás is többe kerül..
De most is a MS termékérõl beszélünk, csak most a C fordítóról :)
Amúgy ha profiling után újrafordítanák a kódot, akkor biztos hatékonyabb lenne.

Na errõl van szó. Lehet ezt kultúráltan is.
Köszi a linket, olvasom.

"jól értem, a "Microsoft SQL Server 2005" hyperthreading hibája alaján gondolja a "szakember", hogy a hyperthreading technológia a szar?"

Szó nincs arról, hogy bármelyik is szar lenne. Bár a cikkben nincs szó az okokról, a #10-ben leírt magyarázat valószínûleg helytálló. Ez alapján arról van szó, hogy az MSSQL programozói olyan jól kódot írtak, ami teljesen kihasználja a proci minden részét, így HT nem gyorsít rajta sokat. Viszont többszálú futás költségei terhelik, vagyis lassabb lesz. Ez annyiban az MS hibája, hogy illett volna tesztelni HT-s gépeken, és kiküszöbölni a lassulást úgy, hogy a fizikai és nem a logikai procikat tekintik egységnek.

Persze ettõl még részben igaz, amit a másik topikban írtál.

Itt kimondottan az Intel HT-jérõl van szó, ami nem egy teljes SMT. Egyébként máshol is elõfordul lassulás miatta.

>>"a sql szerver 2005öt dilettánsok irták, azért lassu HT alatt ;) "

>azek a diletténsok 5 év alatt egy olyan sql servert hoztak össze, ami a kis és közép válalati felhasználásban mára nagyobb piacot ural mint a második és a harmadik együttvéve

A microsoft közeli statisztikai cégek szerint, akik évekig állították, hogy az IIS több gépen fut, mint az apache, egészen addig, amíg kénytelenek voltak beismerni, hogy ez csak a windows környezetben futó gépekre igaz, csak darabszámra, és nem volumenre (kérések száma ill az illetõ cég éves mérlege).

Tudod mit? Igazad vaaan ;)

"Microsoft Windows XP a legjobb. Arról senki se tehet, hogy te nem értesz hozzá."

Microsoft Windows XP a legjobb? Arról senki se tehet, hogy te nem láttál még mást.

muhaahahhahahaha

jól értem, a "Microsoft SQL Server 2005" hyperthreading hibája alaján gondolja a "szakember", hogy a hyperthreading technológia a szar?

Muhahahahahaha

"Ha nem érdekel hogy hiszek e neked, akkor miért kötöttél belém?"

Ezt talán nem így kellene felfogni. Fako célja nyilván nem az volt, hogy beléd kössön, hanem hogy egy általa tévesnek tartott állítást helyesbítsen, hogy mások ne téves infókat tanuljanak meg. Hogy te személy szerint elhiszed-e vagy sem, az egyéni probléma.

Az a helyzet, hogy Fakonak van igaza.

Talán itt érdemes elindulni: http://arstechnica.com/paedia/c/cpu/part-2/cpu2-4.html
Innen aztán több felé lehet továbbmenni, mármint van pár jó link. Az egyik éppen multithreading, superthreading and hyper-threading témában.

Egy idézet, arra vonatkozólag, hogy miért is nem tudják sokan - akár pl. programozók sem - pontosan, mélyeségeiben, hogy is vannak ezek a dolgok:
"The previous article covered the processor as it is visible to the programmer. The register files, the processor status word, the ALU, and other parts of the programming model are all there to provide a means for the programmer to manipulate the processor and make it do useful work. In other words, the programming model is essentially a user interface for the CPU.

Much like the graphical user interfaces on modern computer systems, there's a lot more going on "under the hood" than the simplicity of the interface would imply. <...>"

Érdemes a fenti ponton kezdve olvasgatni (én is ezt fogom tenni, mert én sem követtem a dolgokat ilyen szinten), de ime egy kép - egy ugyancsak superscalar PPC G4e proci felépítésérõl -, jól látható, hogy minden egység 1-1 pipeline:

Ha nem érdekel hogy hiszek e neked, akkor miért kötöttél belém?

Egyébként amíg nem bizonyítod be hogy akár HT által használt futószalag (tudod, amit a predikció és a részegységek használnak) BÁRMI köze van bármilyen másik futószalaghoz a CPU-ban, addig kitartok amellett hogy csak egy darab futószalag van amire a részegységek fel vannak fûzve. És legjobb tudásom szerint csak egy darab FPU van az Intel chipekben.

Ha nem tudod állításodat bebizonyítani és az sem érdekel hogy a többiek elhiszik e amit ide írsz, akkor esetleg kifejthetnéd hogy egyáltalán minek írsz ide bármit is? Tudod az okos embert az okostojástól a bizonyíték választja el. Nálam most csak egy hiányos tudással rendelkezõ okostojás vagy. És szerintem a rokonaidat hülyézzed...

További bejegyzések a fórumban...