Fejlesztõk szerint lassítja a szervereket a HyperThreading
Jelentkezz be a hozzászóláshoz.
#32
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.
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.
Ha már kivan a faszod az idióta szignókkal csinálj te is egyet.
#31
Na errõl van szó. Lehet ezt kultúráltan is.
Köszi a linket, olvasom.
Köszi a linket, olvasom.
#30
"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.
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.
#29
Persze ettõl még részben igaz, amit a másik topikban írtál.
#28
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.
#27
>>"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 ;)
>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 ;)
Ha már kivan a faszod az idióta szignókkal csinálj te is egyet.
#26
"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
Microsoft Windows XP a legjobb? Arról senki se tehet, hogy te nem láttál még mást.
muhaahahhahahaha
Ha már kivan a faszod az idióta szignókkal csinálj te is egyet.
#25
jól értem, a "Microsoft SQL Server 2005" hyperthreading hibája alaján gondolja a "szakember", hogy a hyperthreading technológia a szar?
Muhahahahahaha
Muhahahahahaha
Ha már kivan a faszod az idióta szignókkal csinálj te is egyet.
#24
"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:
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:
#23
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...
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...
#22
Oszinten szolva nem erdekel hogy hiszel e vagy sem. Ha kicsit is erdekel a dolog es nem akarsz hulyesegeket beszelni akkor utananezel.
#21
Hiszek neked ha belinkelsz egy blokkdiagrammot. Ha lehet olyat is, ahol 2 fpu van.
#20
"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 (Oracke/IBM), a nagy válalatinál ugyan kombinálva már nem, de egyenként még mindig legyõzi õket %ban. És a növekedõ tendenciát is magáénak tudhatja.
ez az általad optimizálatalan sql server megjelenése óta folyamatosan dönti a teljesítmény rekordokat. gyorsabban, nagyobb adatbázison képes jól dolgozni és könnyebben használható marad mind fejlesztõi és adminisztrációs oldalról, mind a vállalati menedzsment szempontjából, mint pl az évtizedekek óta legjobbnak számító Oracle.
de nem kell félni, tudom, h csak ugrattál :)
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 (Oracke/IBM), a nagy válalatinál ugyan kombinálva már nem, de egyenként még mindig legyõzi õket %ban. És a növekedõ tendenciát is magáénak tudhatja.
ez az általad optimizálatalan sql server megjelenése óta folyamatosan dönti a teljesítmény rekordokat. gyorsabban, nagyobb adatbázison képes jól dolgozni és könnyebben használható marad mind fejlesztõi és adminisztrációs oldalról, mind a vállalati menedzsment szempontjából, mint pl az évtizedekek óta legjobbnak számító Oracle.
de nem kell félni, tudom, h csak ugrattál :)
#19
Zeneszerkesztéskor is jobb, ha ki van kapcsolva, mert akkor kisebb késleltetéssel is lehet zenélni, nem kezd el recsegni
#18
Sajnos ezt is rosszul tudod. A szuperskalar processzorok (a mai x86-osok mind ilyenek) tobb parhuzmos futoszalaggal rendelkeznek. Ugyis mondhatnam hogy a 486-osokban volt utoljara 1 futoszalag. Egy mai cisc prociban tipustol fuggoen van 1-2 alu, 1-2 fpu, sse sse2 stb futoszalagok, es ezeken kepes parhuzamos vegrehajtasra. Egy ilyen proci atlagban 2-3 utasitast bocsat ki ciklusonkent.
A P1 volt az elso x86-os szuperskalar processzor, es ezert volt az hogy fele akkora orajelen is gyorsabb volt egy 486-osnal.
A P1 volt az elso x86-os szuperskalar processzor, es ezert volt az hogy fele akkora orajelen is gyorsabb volt egy 486-osnal.
#16
több thread soha nem lassabb mint az 1 , csak akkor ha rosszabb a cache kihasználás , és megnövexik a cache miss
a 2 szál kettéosztja a cache-t és ez jobban befolyásolja negativ irányba a teljesitményt mint a több thread miatti nyereség
a 2 szál kettéosztja a cache-t és ez jobban befolyásolja negativ irányba a teljesitményt mint a több thread miatti nyereség
Mi van, bamba paraszt, még most sem buzog föl benned Árpád vére?” (McSzéchenyi)
#15
Tisztázzunk valamit, nem futószalagOK vannak, hanem EGY darab futószalag (illetve ez a HT esetén kibõvül egy virtuális futószalaggal), erre vannak felfûzve a CPU részegységei. Mivel a futószalag hosszú (tehát sok részegységbõl áll) ezért lehetnek rajta kihasználatlan elemek (illetve a duplikáció miatt).
Nem igazán tudom hogy mi a problémád. Ugyanarról a triviális dologról beszélünk és szerintem elég értelmesen írtam le.
Nem igazán tudom hogy mi a problémád. Ugyanarról a triviális dologról beszélünk és szerintem elég értelmesen írtam le.
#14
igen jol ertetted, nem a kihasznalatlan futoszalagok miatt, hanem a tul hosszu futoszalagok miatt tette be.
#13
Lol!!!<#worship><#nyes>
\"The voices are back... Excellent.\"
#12
"Csak annyiban tevedsz hogy az intel nem a kihasznalatlan pipeline-ok miatt tette be a HT-t, hanem a tul hosszu futoszalag miatt. "
Jó, akkor két kérdésem lenne:
1. Szerinted mi a futószalag a CPU-knál angolul?
2. Szerinted mi a 'pipeline' CPU-knál a magyarul?
Jó, akkor két kérdésem lenne:
1. Szerinted mi a futószalag a CPU-knál angolul?
2. Szerinted mi a 'pipeline' CPU-knál a magyarul?
#10
Csak annyiban tevedsz hogy az intel nem a kihasznalatlan pipeline-ok miatt tette be a HT-t, hanem a tul hosszu futoszalag miatt.
A P4 hosszu futoszalagjaihoz nem tarsul aranyosan jobb elagazas becsles, ezert lassabb a p4 a legtobb altalanos celu alkalmazasban (ahol viszonylag sok az elagazas). A hosszabb futoszalag csak magasabb orajelen terul meg. Az intel ott szamitotta el magat, hogy gyartastechnologiai okok miatt nem sikerult kihoznia a 4-5ghz-s p4-eket (ahol mar latszodott volna a hosszabb futoszalag elonye)
Na de hogy visszakanyarodjunk a temahoz:
Amikor egymas utan, egymastol fuggo utasitasokat hajtunk vegre akkor jelentosen romlik a teljesitmeny, ilyenkor jo ha van egy teljesen fuggetlen szal, ahonnan teljesen fuggetlen utasitasokkal feltolthetjuk a futoszalagokat.
Mivel HT-nal a ket szalat fizikailag ugyanazok a futoszalagok hajtjak vegre, ezert ugyanazt a futoszalagot (pl ALU) egyszerre csak 1 szal tudja hasznalni.
Altalanos celu felhasznalasnal ahol az osszes futoszalag osszes fokozatat tekintve viszonylag alacsony a kihasznaltsag a HT-vel jelentos teljesitmenynovekedest lehet elerni.
Es itt jon a bibi szervereknel, ahol a programok (pl az emlitett sql server) az atlagosnal sokkal jobban ki tudja hasznalni a procit (mert jol van megirva es keves a fuggo utasitas). Ilyenkor a masik szalnak muszaj varakoznia.
De ez igy onmagaban nem magyarazat a lassulasra.
Lassulas azert kovetkezik be, mert a tobbszalu vegrehajtasnal bejon egy csomo uj dolog (szal szinkronizacio, szalak eroforras managementje) amik a multiprocesszoros rendszerekre jellemzoek es ezt mind kezelnie kell az oprendszernek. Tehat a HT miatt kapunk egy csomo uj feladatot, de a specalis alkalmazas miatt nemlehet kihasznalni a HT elonyeit.
A P4 hosszu futoszalagjaihoz nem tarsul aranyosan jobb elagazas becsles, ezert lassabb a p4 a legtobb altalanos celu alkalmazasban (ahol viszonylag sok az elagazas). A hosszabb futoszalag csak magasabb orajelen terul meg. Az intel ott szamitotta el magat, hogy gyartastechnologiai okok miatt nem sikerult kihoznia a 4-5ghz-s p4-eket (ahol mar latszodott volna a hosszabb futoszalag elonye)
Na de hogy visszakanyarodjunk a temahoz:
Amikor egymas utan, egymastol fuggo utasitasokat hajtunk vegre akkor jelentosen romlik a teljesitmeny, ilyenkor jo ha van egy teljesen fuggetlen szal, ahonnan teljesen fuggetlen utasitasokkal feltolthetjuk a futoszalagokat.
Mivel HT-nal a ket szalat fizikailag ugyanazok a futoszalagok hajtjak vegre, ezert ugyanazt a futoszalagot (pl ALU) egyszerre csak 1 szal tudja hasznalni.
Altalanos celu felhasznalasnal ahol az osszes futoszalag osszes fokozatat tekintve viszonylag alacsony a kihasznaltsag a HT-vel jelentos teljesitmenynovekedest lehet elerni.
Es itt jon a bibi szervereknel, ahol a programok (pl az emlitett sql server) az atlagosnal sokkal jobban ki tudja hasznalni a procit (mert jol van megirva es keves a fuggo utasitas). Ilyenkor a masik szalnak muszaj varakoznia.
De ez igy onmagaban nem magyarazat a lassulasra.
Lassulas azert kovetkezik be, mert a tobbszalu vegrehajtasnal bejon egy csomo uj dolog (szal szinkronizacio, szalak eroforras managementje) amik a multiprocesszoros rendszerekre jellemzoek es ezt mind kezelnie kell az oprendszernek. Tehat a HT miatt kapunk egy csomo uj feladatot, de a specalis alkalmazas miatt nemlehet kihasznalni a HT elonyeit.
#9
Láttam valahol egy winupdaten ki nem adott frissítést és hozzá tartozó leírást egy registry érték átírásáról ami a kétszálú fleadatkezelést javítja a 2 magos processzoroknál. Elgondoltam hogy HT-hez megérné-e kipróbálni. Látta, esetleg kipróbálta valaki? (majd mindejárt megkeresm a linket)
#8
te ilyen marketinges vagy, mi? :D sok ilyen üres szó lehet a tarsolyodban ...
a sql szerver 2005öt dilettánsok irták, azért lassu HT alatt ;)
az intel a szar netburst ellensulyozására találta ki a HT-t, amire a többmagos szerverkörnyezetben semmi szükség.. ahogy már láttuk nem ez az elsõ HT fiaskó: volt az biztonsági probléma, amit azóta sem nagyon reklámoznak :)
a sql szerver 2005öt dilettánsok irták, azért lassu HT alatt ;)
az intel a szar netburst ellensulyozására találta ki a HT-t, amire a többmagos szerverkörnyezetben semmi szükség.. ahogy már láttuk nem ez az elsõ HT fiaskó: volt az biztonsági probléma, amit azóta sem nagyon reklámoznak :)
Forza.
#7
háháháhá
xbox360+komputer
#6
Egyébként már vitatkoztam itt másokkal a témakörben, akkor vettem a fáradságot és írogattam magyarázatokat is.
Itt megtekinthetõ:
http://www.sg.hu/cikkek/39987
#28
Itt megtekinthetõ:
http://www.sg.hu/cikkek/39987
#28
#5
Jah, lásd 64 bites CPU-k 32 bites OS-ek alatt...
#4
Optimizáció és kompatibilitás kérdése az egész.
![[NST]Cifu](https://media.sg.hu/forum/avatars/10356591011409433815.png)
#3
Az Intel kétmagos procijai között is van olyan, amely HT-s, vagyis a szoftver felé négymagosnak látszik. A kérdés itt az, hogy az adott szoftverrel, amelyet többmagos rendszerre felkészítettek, képes-e megbírkózni a HT.
Természetesen a HT a legtöbb esetben gyorsulást okoz, de amit a fenti eset is mutatja, olykor éppen lassitja a rendszert...
Természetesen a HT a legtöbb esetben gyorsulást okoz, de amit a fenti eset is mutatja, olykor éppen lassitja a rendszert...
A csapatmunka roppant fontos: rajtad kívül másra is l?hetnek!
#2
Ez nagyon ciki, pedig az ötlet maga nem rossz. Az a baj inkább hogy a HT kihasználásához megfelelõ módon kell a szoftvereket kialakítani, ami két külön mag esetén nyilvánvalóan kihagyható, ezért a kutya nem fog vele foglalkozni.
lol...
A bölcsek nem tudósok - a tudósok nem bölcsek Lao-Ce