Hyper-threading strikes back!

[mcekovic]

Sudeci prema vesti za VR-Zone-a, Hyper-threading se vraca sa novom Intelovom Nehalem architekturom!

http://www.vr-zone.com/?i=4322

Ako ga ovaj put naprave kako valja (a trebalo bi, posto su valjda nesto naucili od NetBurst HT fijaska 😉 ), to bi bio znacajan pomak. Quad-core sa 8 thread-ova, 😀 . Genralno sa HT konceptom nema problema (Sun Niagara, IBM Power 5), vec je bilo problema sa HT implementacijom u nesrecnom NetBurst-u.

Takodje, pominje se da bi arhitektura jezgra sa dva virtuelna pipeline-a bila asimetricna, jedan bi imao vise resursa na raspolaganju. Core 2 jezgro je vec sada dovoljno siroko (ima dovoljno izvrsnih jedinica) da se HT itekako isplati.

 

[drfedja]

HT nije bio uopste lose implementiran, ali je pitanje kolika je korist bila od njega. Sustinski, u programima koji koriste prednosti multiprocesiranja donosio je ubrzanje, ali to ubrzanje je bilo dovedeno na nivo kakav bi trebalo da bude i bez njega. Drugim recima, HT u Netburst-u sluzio za popunjavanje supljikavog pipeline-a.
Simetric Multithreading na procesorima poput Power 5 ili nerodjene Alphe EV8 ima malo drugaciju filozofiju i implementaciju. S' obzirom na to da su to u pitanju superskalarne 8-way arhitekture, toliki paralelizam nije lako iskoristiti, pa tako siroki procesori sa puno izvrsnih resursa mogu da po potrebi glume vise jezgara i da dele vise threadova na jedno fizicko jezgro. To je dosta dobra ideja, ali je pitanje koliko je naprednog softvera koji ce to da iskoristi i koliko ce implementacija efikasno da bude odradjena na x86 arhitekturi.

 

[mcekovic]

HT nije bio uopste lose implementiran, ali je pitanje kolika je korist bila od njega. Sustinski, u programima koji koriste prednosti multiprocesiranja donosio je ubrzanje, ali to ubrzanje je bilo dovedeno na nivo kakav bi trebalo da bude i bez njega. Drugim recima, HT u Netburst-u sluzio za popunjavanje supljikavog pipeline-a.
Simetric Multithreading na procesorima poput Power 5 ili nerodjene Alphe EV8 ima malo drugaciju filozofiju i implementaciju. S' obzirom na to da su to u pitanju superskalarne 8-way arhitekture, toliki paralelizam nije lako iskoristiti, pa tako siroki procesori sa puno izvrsnih resursa mogu da po potrebi glume vise jezgara i da dele vise threadova na jedno fizicko jezgro. To je dosta dobra ideja, ali je pitanje koliko je naprednog softvera koji ce to da iskoristi i koliko ce implementacija efikasno da bude odradjena na x86 arhitekturi.

Slazem se. Kad sam rekao lose implementiran, zapravo sam mislio da nije bilo prevelike koristi od njega koliko bi moglo da bude da je NetBurst pipeline bio siri. Tj. kad su vec uvodili HT, trebali su i pipeline da prosire.

 

[genuine]

koliko sam razumeo nesto slicno radi UltraSparc T1 sa 4 jezgra koje mogu da po 4 niti izvrsavaju... nesto mi samo nije jasno... jel ti procesori imaju duplirane registre pa svaka nit ima svoj set?

 

[DeanXP]

Ono sto u startu treba imati na umu jeste da UltraSparc T1 ne koristi Simultaneous Multithreading (SMT) nego Vertical Multithreading. Ima samo jedan jedini ALU tako da nikako ni ne moze istovremeno da izvrsava vise threadova kao sto zahteva SMT, nego se prebacuje sa thread-a na thread kako jedan zablokira. Ima 4 zasebna register file-a za svaki thread. UltraSparc T2 vec ide na kombinaciju SMT i VT tako da moze da izvrsava 8 threa-ova po jezgru (svako ima 2 ALU-a).

SMT ce sigurno igrati ogromnu ulogu u buducim procesorima. Imlementacija SMT-a u Nahalem-u ce se verovatno drasticno razlikovati od one u Netburst-u.
Cak ce i buduci AMD procesori verovatno koristiti SMT, mada na nesto specificniji nacin.

 

[audiofreak]

HTT nije uopste bio los jer je sa svega 5% dodatnih resursa u jezgru donosio do 25% bolje performanse, a o laksem multitaskingu da i ne govorimo.

Problem je uvek bio i ostao u XP scheduler-u koji ne zna da razlikuje logicka i fizicka jezgra i koji radi ocajan load balancing.

Kako je HTT delio resurse (samo arhitekturalno stanje je bilo duplirano, a ne i izvrsne jedinice) bilo je koristi samo ako su dva threada uopsljavala razlicite jedinice (npr. jedan samo ALU, drugi samo FPU). Retko koji softver je to znao da iskoristi, a ni danas situacija nije mnogo bolja.

Po mom misljenju, bez brzeg dekodera nema smisla ubacivati HTT u Core arhitekturu jer je decoding bandwidth po mom misljenju knap za ovo sto sada imamo.

U 64-bitnom kodu se zbog prefiksa odnosno duzih instrukcija vec oseca usporenje od ~5% u odnosu na 32-bitni kod mada je tako i na Opteronu sto je i logicno jer je AMD64/EM64T samo natakaren na x86 dodavanjem instrukcijskih prefiksa.

Takodje ne vidim ni da ima mnogo dupliranih izvrsnih jedinica koje bi mogle tako nesto da rade, a samo tagovanje instrukcija da bi se znalo za koje su logicko jezgro namenjene zahtevale bi verovatno slican pristup onome iz Netbursta, tj. mozda im opet zatreba trace cache.

Sto se tice Core 2 Duo, moj utisak posle nesto vremena provedenog u optimizaciji za njega je da je arhitekturalno jako slican Netburstu. Cak i Intelov kompajler generise potpuno identican kod za Northwood, Prescott, Banias (Pentium M) i Core/Core 2 Duo.

Licno, mnogo vise nego povratak HTT-a me raduje novih 50-tak instrukcija iz SSE4 seta ukljucujuci tu CRC32, POPCNT, PCMPESTRI/PCMPESTRM i PCMPISTRI/PCMPISTRM primitive jer sam ja jos davno govorio da je neophodno ici u pravcu ugradjivanja malih usko specijalizovanih izvrsnih jedinica u procesore koje ce obavljati tipicne programske zadatke (poput izracunavanja CRC) velikom brzinom.

Preostale instrukcije su takodje izuzetno korisne i napokon ce omoguciti automatsku vektorizaciju kompleksnijih izraza (npr. koda sa slozenim uslovima u telu petlje) tako da ja ocekujem pravu malu revoluciju u razvoju softvera.

 

[okmijun]

meni licno ovo zanimljivije
Bloomfield will contain an integrated memory controller that requires a new socket refresh called Socket B with 1366 contact pads.

 

[Nedjo]

Obzirom da je ovo dve godine udaljena buducnost, pitnaj je koliko i sta ce se sve izmeniti.

 

[DeanXP]

Kako je HTT delio resurse (samo arhitekturalno stanje je bilo duplirano, a ne i izvrsne jedinice) bilo je koristi samo ako su dva threada uopsljavala razlicite jedinice (npr. jedan samo ALU, drugi samo FPU). Retko koji softver je to znao da iskoristi, a ni danas situacija nije mnogo bolja.

Obzirom na malo jedinica, Netburst je dosta koristi od HTT-a imao po verticali (kad jedan thread blokira drugi moze da nastavi) - slicno Niagari.

Po mom misljenju, bez brzeg dekodera nema smisla ubacivati HTT u Core arhitekturu jer je decoding bandwidth po mom misljenju knap za ovo sto sada imamo.

Ubedljivo najslabija tacka Core arhitekture je decoding. Predecoder zajedno sa malim (svega 64B) buffer-om za predekodirane instrukcije su najuze grlo.

Takodje ne vidim ni da ima mnogo dupliranih izvrsnih jedinica koje bi mogle tako nesto da rade, a samo tagovanje instrukcija da bi se znalo za koje su logicko jezgro namenjene zahtevale bi verovatno slican pristup onome iz Netbursta, tj. mozda im opet zatreba trace cache.

Trace cache ce skoro sigurno napraviti comeback (cak i u AMD-ovoj mikroarhitekturi), ali ipak mora da se usavrsi njegova proizvodja (u Netburst-u je em zahtevao posebne tranzistore, em radio na polovini frekvencije).

 

[drfedja]

Nisam znao da trace cache radi na pola brzine. Interesantno. Inace, sto se tice Hyperthreadinga, potpuno se slazem da je P4 imao sasvim ok implementiran HT, dobici u SMT aplikacijama su sasvim ok.