Šta je novo?

Kataklizma HyperThreading(izm)a

  • Začetnik teme Začetnik teme Nedjo
  • Datum pokretanja Datum pokretanja
Poslednja izmena:
Sto da kompajliraju sa intelovim kompajlerom kad imaju svoj 😀
 
Samo mala primedba, ne treba kritikovati hyper-threading kao koncept, vec Intel-ovu implementaciju u NetBurst arhitekturi.

Hyper-threading kao mogucnost jednog jezgra procesora da izvrsava vise thread-ova 'simultano' je dobar koncept, koji u praksi moze da funkcionise od sasvim lepo (IBM Power 5, 2 jezgra x 2 thread-a) do izvrsno (Sun Niagara, 8 jezgara x 4 thread-a).

Problem sa Intel-ovom implementacijom je sto je broj execution jedinica za obradu mikro instrukcija mali, pa nema mnogo vajde od hyper-threading-a. Hyper-thread-ing je zapravo naknadno ubacen u NetBurst arhitekturu da zamaskira neefikasnost dugackog pipeline-a, dok su Power 5 i Niagara od pocetka dizajnirani sa hyper-threading-om na umu i imaju znatno vise execition jedinica po core-u.

Prava je steta sto AMD-ovi zvanicnici karakterisu hyper-threading kao nesto lose (cisto iz marketinskih razloga verujem).
 
Ko zna, mozda sutra kada implementiraju Multithreading u Athlon procesore kazu kako je to nesto extra.... to ti je uglavnom cista PR pljuvachina, sto je i normalno. 🙂
Ja sam pre izvesnog vremena govorio o tome da je SMT mogao da bude implementiran u AMD K8 procesore, bas kao sto je implementiran i u Power5 ili SUN Niagaru, ali neki ovde su tvrdili kako je za to neophodan 31-stepeni pipeline. :d Ni Power 5, a ni Niagara nemaju ni 20-stepeni pipeline, a SMT radi kako treba. Athlon ima dovoljno izvrsnih jedinica, pravi out-of-order core, efikasan dekoder instrukcija itd... mozda se desi da neki od narednih dual core procesora ima multithreading.
 
Nema tu mnogo sta da se objasnjava, HTT funkcionise na principu deljenja resursa i samoj implementaciji nista ne fali. Ovo sto se desava sa MSSQL i nekim tamo Citrix-om je slicno automobilu sa dva motora, a jednim rezervoarom za gorivo i izduvnom cevi. Ako obe aplikacije koriste iste resurse logicno je da ce doci do zagusenja.

Ovo sto pricaju zaista nema smisla, niti je neki test, niti su dali neke konkretne podatke o instaliranom softveru i hardveru, nista, samo prazna kritika u stilu:

"Primetili smo u nekim slucajevima da se desava usporenje ali ne znamo ni zasto nastaje niti smo pokusali da ga otklonimo na pravi nacin profiliranjem nase aplikacije u realnoj situaciji i ispravljanjem problematicnog koda. Najlakse nam je bilo da ugasimo HTT i na srecu to je pomoglo pa da se mi ne bi dalje smarali da izbacujemo patch-eve i update-ove neka ga kupci naseg bloatware-a takodje iskljuce na svojim masinama."

Bullshit if you ask me. HTT mi jos nijednom nista nije usporio, a koristim ga od samog pocetka i nemam nameru da ga deaktiviram zbog lose pisanih aplikacija.
 
Pa sad, komentar ti je stvarno "bullshit if you ask me"; sto si tako iskljuciv? Ako ti nisi imao problema sa time, ne znaci da niko nije imao problema. Ocigledno tvoje i njihovo koriscenje racunara nisu isti scenariji. Za desktop je HTT ok stvar, ali za neke serverske primene simulacija dva jezgra nije najbolje resenje.
 
Poslednja izmena:
drfedja je napisao(la):
Ko zna, mozda sutra kada implementiraju Multithreading u Athlon procesore kazu kako je to nesto extra.... to ti je uglavnom cista PR pljuvachina, sto je i normalno. 🙂

Tesko da Athlon sa 12-stage pipelineom moze da emulira dodatno jezgro...
 
Poslednja izmena:
silverglider je napisao(la):
Pa sad, komentar ti je stvarno "bullshit if you ask me"; sto si tako iskljuciv? Ako ti nisi imao problema sa time, ne znaci da niko nije imao problema. Ocigledno tvoje i njihovo koriscenje racunara nisu isti scenariji. Za desktop je HTT ok stvar, ali za neke serverske primene simulacija dva jezgra nije najbolje resenje.

Ma nisam ja iskljuciv -- jasno je da HTT nije dobar za svaku vrstu primene racunara, ali me nervira pristup tipa "nesto ne radi daj da iskljucimo da vidimo moze li da ide auto bez toga" umesto "daj da popravimo ako nesto ne valja".

Najlakse je upreti prstom u drugoga. Neka oni prvo pogledaju zasto im taj server radi tako lose (to bar nije tesko!) pa onda ako stvarno nije do njihovog loseg koda (u sta iskreno receno sumnjam) nek se zale i pljuju po jednom sasvim solidnom tehnoloskom resenju.

Takodje nije na mestu ni poredjenje sa dual-core Opteronom. HTT nema duplirane sve execution unite kao sto to imaju dva fizicka jezgra.
 
Audiofreak,mislim da ovo nije prvi put da se ovako nesto desava na serverskom frontu(gde su "najgori" uslovi rada po procesor).Pisao je Inq o tome pre par meseci,dok se sad ovo ponovo nije desilo.Ko zna sta je u pitanju...
 
Silver ima pravo kada kaze da HTT ima smisla za desktop gde se povremeno nesto moze paralelno izvrsiti i dobiti na performansama ali na serverima se ocekuje pravi paralelizam sa visestrukim resursima i zaista se dogadja da nesto sto je pisano za viseprocesorsko okruzenje radi sporije na implementaciji koja to u sustini nije.
 
audiofreak je napisao(la):
Ma nisam ja iskljuciv -- jasno je da HTT nije dobar za svaku vrstu primene racunara, ali me nervira pristup tipa "nesto ne radi daj da iskljucimo da vidimo moze li da ide auto bez toga" umesto "daj da popravimo ako nesto ne valja".

Najlakse je upreti prstom u drugoga. Neka oni prvo pogledaju zasto im taj server radi tako lose (to bar nije tesko!) pa onda ako stvarno nije do njihovog loseg koda (u sta iskreno receno sumnjam) nek se zale i pljuju po jednom sasvim solidnom tehnoloskom resenju.

Kako nisi iskljuciv? I u ovom postu si opet pokazao iskljucivost tipa "to je super tehnologija, greska 100% lezi na drugima, tj. losem kodu". Ljudi ocigledno jesu pogledali zasto im server radi tako lose cim su zakljucili da im HTT predstavlja usko grlo. Tada i oni (po meni sasvim legalno) mogu da postave pitanje "zasto da mi menjamo kod da bi ga prilagodili tehnoloskom resenju koje ni nije namenjeno da tera ovaj softver"? Da je u pitanju neka entry-level baza, pa da i imas slucaj, ali za jednog teskasa u oblasti DB servera - ne.
 
silverglider je napisao(la):
Kako nisi iskljuciv? I u ovom postu si opet pokazao iskljucivost tipa "to je super tehnologija, greska 100% lezi na drugima, tj. losem kodu".

Pa zasto me teras da citiram samog sebe!?

audiofreak je napisao(la):
...po jednom sasvim solidnom tehnoloskom resenju.

Gde sam ja tu rekao da je to "super tehnologija"?!?

silverglider je napisao(la):
Ljudi ocigledno jesu pogledali zasto im server radi tako lose cim su zakljucili da im HTT predstavlja usko grlo.

Pitanje za tebe:

Da li su zakljucili ZBOG CEGA im HTT predstavlja usko grlo?

Ja samo pokusavam da objasnim da je to "gledanje" ocigledno bilo na nivou "zeza nas auto, nece da ubaci u trecu", a "resenje" u stilu "nema veze, necemo popravljati menjac, vozi ga u drugoj".

to se tice gresaka u kodu, jedna od najcescih gresaka koje uzrokuju lose performanse kod HTT-a su tesne spin petlje gde jedan thread ceka da se promeni neka varijabla pa je proverava previse cesto troseci bezveze bandwidth. Resenje za to je pause instrukcija u petlji koja je na drugim x86 arhitekturama jednaka nop instrukciji, a za NetBurst je hint da je u pitanju spin i da ne treba da radi spekulativno citanje varijable stotinak prolaza unapred troseci bezveze resurse koje bi drugi thread pametnije iskoristio.

Drugi problem se javlja ako oba thread-a (ili aplikacije) koriste iste resurse (oba FPU ili oba integer jedinice).

Treci se javlja ako imaju dva procesora sa HTT u racunaru pa OS (ili sama aplikacija!) radi los scheduling threadova i stavlja threadove koji trose iste resurse na isto jezgro umesto na drugo.

silverglider je napisao(la):
Tada i oni (po meni sasvim legalno) mogu da postave pitanje "zasto da mi menjamo kod da bi ga prilagodili tehnoloskom resenju koje ni nije namenjeno da tera ovaj softver"?

Pa ceka, ako nije ni namenjeno zasto ga onda teraju na tome i cude se sto ne valja?!? Cemu onda cela ova prica?!?

Inace postoje aplikacije koje su multithreadovane (na primer 7-zip) i koje i na HTT postizu neko ubrzanje, a one koje nemaju ubrzanje makar rade korektno tj. ne usporavaju sto ovde nije slucaj. To je razlog zasto ja sumnjam na los kod.
 
audiofreak je napisao(la):
Ja samo pokusavam da objasnim da je to "gledanje" ocigledno bilo na nivou "zeza nas auto, nece da ubaci u trecu", a "resenje" u stilu "nema veze, necemo popravljati menjac, vozi ga u drugoj".

Ne, tvoje objasnjenje (kad vec pokusavas da poredis omiljenim situacijama sa kolima) izgleda malo previse banalno, jer si vec u njega ugradio svoju pretpostavku o postojanju kvara. Problem vise podseca na situaciju kada nakacimo prikolicu za kamion na hondu civic i nastaje problem zbog otpora vazduha, itd. Tvoj predlog je da se prikolica vrati u proizvodni pogon i prilagodi hondi civic. Na sta je komentar ostalih: "halo, to je prikolica za kamion...". Ali sto da ne, problem je kod njih; honda civic je sasvim solidan auto kada se pametno koristi, trosi samo 6 litara na 100km, itd. itd.

Pa ceka, ako nije ni namenjeno zasto ga onda teraju na tome i cude se sto ne valja?!? Cemu onda cela ova prica?!?

Zasto ga teraju? To ces vec njih morati da pitas konkretno zasto; pretpostavljam da je to zbog ljudi koji vole da ushtinu na hardveru i hteli bi da im obican desktop hw ima ulogu malo jaceg DB servera. Tu na svetlo dolazi cela ova prica - "probajte sa iskljucenim HTT-om". Ne da bi neko opalio samar Intelu ili da se povede sad ideoloski rat, nego kao najobicniji prakticni tips&tricks, kao sto za zimnicu sledi savet "probaj sa vinobranom".
 
silverglider je napisao(la):
Tvoj predlog je da se prikolica vrati u proizvodni pogon i prilagodi hondi civic...

Ne, moj predlog je ipak malo drugaciji:

1. Da se prikolica za kamion ne kaci na Hondu Civic jer je Honda Civic nije kamion nego automobil.

2. Ako vec mora da se kaci onda ili neka se prilagodi Hondi ili neka se ne tupi kako Honda ne ide dobro u tako ekstremnoj situaciji.

Hipoteticka situacija: sta bi se recimo desilo da na sistemu imate gomilu programa, svi koji profitiraju od na primer SSE instrukcija izmedju 15 i 30%, i samo jedan koji se uspori kad su ukljucene? Da li bi od tog proizvodjaca softvera (te crne ovce) prihvatili savet da iskljucite SSE da bi njihov softver radio normalno? Ja licno bi ih poslao tamo gde sunce ne sija i nasao drugi program.

Nije mi jasno zasto toliko branite proizvodjace glomaznog softvera?!? Pa oni se razbise od para prodajuci bloatware i jos im je tesko da se prilagode potrebama kupaca?!

Jasno je da ja kao kupac necu kupiti softver ciji minimum hardware requirements moja masina ne moze da ispostuje. Ali ako kupim skup softver ciji autori tvrde da moja masina moze da ga tera onda hocu da ga tera za sve pare sa sve HTT, MMX, SSE, SSE2, SSE3, 3DNow!, 3DNow+, Altivec, GPGPU, itd. Zabole me bas uvo sto njih optimizacija softvera kosta -- ionako trose pare nas kupaca. Uostalom, bolje da njih kosta optimizacija nego mene kupovina novog skupog hardvera da bih terao neko neoptimizovano smece na njemu. Ako nisu u stanju da idu u korak sa novim tehnologijama onda po mom misljenju treba da propadnu.

Ocigledno je da se oko ovoga nikada necemo sloziti jer ja smatram da su duzni da izbace fix u softveru, a ne da nam nude hardverski workaround u vidu iskljucivanja mogucnosti hardvera koje nisu kompatibilne sa njihovim kodom, tako da ja odustajem od dalje diskusije.
 
audiofreak je napisao(la):
Hipoteticka situacija: sta bi se recimo desilo da na sistemu imate gomilu programa, svi koji profitiraju od na primer SSE instrukcija izmedju 15 i 30%, i samo jedan koji se uspori kad su ukljucene? Da li bi od tog proizvodjaca softvera (te crne ovce) prihvatili savet da iskljucite SSE da bi njihov softver radio normalno? Ja licno bi ih poslao tamo gde sunce ne sija i nasao drugi program.

I dalje mesas babe i zabe, poredeci desktop i server funkcionalitet. Racunar na kojem treba da radi SQL teskas kao heavy-duty DB server ne tera jos gomilu programa. To su namenske masine.

audiofreak je napisao(la):
Nije mi jasno zasto toliko branite proizvodjace glomaznog softvera?!? Pa oni se razbise od para prodajuci bloatware i jos im je tesko da se prilagode potrebama kupaca?!

Zameni u ovom pasusu "proizvodjace glomaznog softvera" sa "proizvodjace procesora" odnosno "Microsoft" sa "Intel" i razmisli onda da li je trebalo to da nas pitas.


audiofreak je napisao(la):
Jasno je da ja kao kupac necu kupiti softver ciji minimum hardware requirements moja masina ne moze da ispostuje. Ali ako kupim skup softver ciji autori tvrde da moja masina moze da ga tera onda hocu da ga tera za sve pare sa sve HTT, MMX, SSE, SSE2, SSE3, 3DNow!, 3DNow+, Altivec, GPGPU, itd. Zabole me bas uvo sto njih optimizacija softvera kosta -- ionako trose pare nas kupaca. Uostalom, bolje da njih kosta optimizacija nego mene kupovina novog skupog hardvera da bih terao neko neoptimizovano smece na njemu. Ako nisu u stanju da idu u korak sa novim tehnologijama onda po mom misljenju treba da propadnu.

Ukoliko me secanje ne vara, niko nije tvrdio da je taj db server totalno neoptimizovan za sve i svasta, nego da jedino sa ukljucenim HTT-om ima problema u izvesnom usporenju. Verujem da u celom MS-u ima neko ko je cuo za optimizaciju do sada.

Problem sa tvojim stavom je u tome sto gledas na stvar iskljucivo iz ugla optimizacije, ignorisuci realan model poslovnih odluka: meni u firmi treba ozbiljan DB server da bih zavrsio neki posao; u odabiru sigurno necu krenuti od procesora za koji mislim da je kul. Stavim na sto DB server, razvojne alate, kompatibilnost, literaturu, raspolozivost developera za tu platformu, hardver, itd. I ako se odlucim za MS platformu (kao dominantnu, jelte, u firmama), imam informaciju da me taj SQL server sa (samo) 25 licenci kosta reda velicine 15K ili 20K eura. U takvoj konstelaciji mi uopste nije vazno da razbijam glavu da li je starija koka ili jaje, tj. da li bi MS trebalo da optimizuje SQL server i za HTT ili ne. Najmanji mi je problem da uzmem za taj server neki drugi procesor za razliku od nekoliko stotina eura po procesoru. To su sve lego kockice, i hardver i softver. Nema potrebe da emotivno reagujem i durim se sto sto
nisu sve podesili i za moj omiljeni model procesora, kad za malu razliku u parama dobijam optimalno resenje i kompletan projekat funkcionise kako bi i trebalo.


A sad, zasto ljudi teraju sw na hardveru koji ne ispunjava neki dat system requirements? Tja, verovatno zbog istog razloga zbog kojeg je u uputstvu za mikrotalasnu explicitno napisano da se macke i ostali kucni ljubimci ne stavljaju unutra. Ekstreman primer, ali sluzi ilustraciji.
 
silverglider je napisao(la):
Racunar na kojem treba da radi SQL teskas kao heavy-duty DB server ne tera jos gomilu programa. To su namenske masine.

Pa sta ce onda na njemu jos i Citrix Terminal server?!?

silverglider je napisao(la):
audiofreak je napisao(la):
Nije mi jasno zasto toliko branite proizvodjace glomaznog softvera?!? Pa oni se razbise od para prodajuci bloatware i jos im je tesko da se prilagode potrebama kupaca?!
Zameni u ovom pasusu "proizvodjace glomaznog softvera" sa "proizvodjace procesora" odnosno "Microsoft" sa "Intel" i razmisli onda da li je trebalo to da nas pitas.

Tebi nesto sa prioritetima operacija nije u redu. Reci mi zar zaista mislis da hardver treba razvijati prema starom softveru?!?

silverglider je napisao(la):
Verujem da u celom MS-u ima neko ko je cuo za optimizaciju do sada.

Ima, ima -- bas nedavno sam mu prijavljivao bagove u optimizaciji (tacnije nedostatak iste) vezano za spillovanje registara pri ulasku u funkciju i store to load forwarding sa najnovijim Visual Studio 2005 C++ kompajlerom.

silverglider je napisao(la):
U takvoj konstelaciji mi uopste nije vazno da razbijam glavu da li je starija koka ili jaje, tj. da li bi MS trebalo da optimizuje SQL server i za HTT ili ne.

Ako sam ja dobro razumeo tekst taj server je terao dva softverska paketa i moguce je cak da se medjusobno nisu slagali kad je HTT bio ukljucen. Vrlo je moguce da bi svaki za sebe radio sasvim OK.
 
audiofreak je napisao(la):
Pa sta ce onda na njemu jos i Citrix Terminal server?!?

Jao, daj covece, je l' stvarno na ovo mora da spadne diskusija da mora sad da se uopste poredi situacija DB+TS vs DB+"gomila programa"?? Pusti...


audiofreak je napisao(la):
Tebi nesto sa prioritetima operacija nije u redu. Reci mi zar zaista mislis da hardver treba razvijati prema starom softveru?!?

Stvarno mi nije jasno kako si iz onog mog pasusa dosao uopste do ovog pitanja?


audiofreak je napisao(la):
Ima, ima -- bas nedavno sam mu prijavljivao bagove u optimizaciji...

Ajde navedi mi jedan program (kompleksniji od "hello world" nivoa) koji nema nijedan bag ili makar previd? Ako sa nekim ko se bavi programiranjem treba uopste da se o tome raspravlja, onda...
 
silverglider je napisao(la):
Jao, daj covece, je l' stvarno na ovo mora da spadne diskusija da mora sad da se uopste poredi situacija DB+TS vs DB+"gomila programa"?? Pusti...

Pa sam si rekao da treba da bude samo DB, a ne DB+x.

Hajde da rezimiramo:

1. Teraju softver na masini koja nije namenjena za to (tvoj post, cetvrta recenica), s tim se slazem.
2. Teraju DVA serverska softvera (MSSQL i Citrix) na JEDNOJ masini (prvi pasus teksta) za sta si takodje ti rekao (a i s tim se slazem) da nije dobra stvar.
3. Porede babe i zabe (HTT procesor .VS. pravi dual-core procesor), naravno da je potonji bolji.

Sve to na stranu, pogledao sam blog i primer koda koji izaziva ovakvo ponasanje. Sustina je u tome da HTT CPU deli L1 i L2 cache i da thread koji "prelazi" velike kolicine memorije (lazywriter na primer) trashuje cache i ponekad cak onemogucava drugi thread koji radi na istom fizickom jezgru da dobije spinlock.

Ja pretpostavljam da postoji nacin da se to nekako drugacije resi bez iskljucivanja HTT. Na primer po defaultu na P4 je L1 Cache u adaptivnom modu odnosno prilagodjava se trenutnim potrebama logickih jezgara sto znaci da jedno jezgro moze dobiti i ceo L1 ako mu treba. Pretpostavljam da bi prelazak u shared mode (moze se podesiti softverski npr. iz CPU MSR programa) mozda mogao da pomogne u ovoj i slicnim situacijama (mada u njihovom primeru na blogu ne pomaze -- proverio sam).

Druga stvar koja se iz ovoga namece -- proizvodjaci procesora (i AMD i Intel) su uprkos opasnosti od ovakvih problema najavili nove procesore koji ce imati deljenu cache hijerarhiju izmedju FIZICKIH jezgara. Kako to moze uticati na performanse serverskih aplikacija moze se videti iz ovog scenarija.
 
Poslednja izmena:
U prilogu poboljsana verzija koda koji izaziva ovaj HTT problem (original mozete naci na ovom blogu) pa koga zanima (Monteboy?) neka ih uporedi.
Problem se moze dosta ublaziti ali se ne moze u potpunosti izbeci jer je posledica deljenja cache-a i zapravo nema velike veze sa samom HyperThreading tehnologijom. Verovatno bi se isto desilo i sa dual-core procesorom kada bi L1&L2 bili deljeni.
 

Prilozi

Nadam se da cu kada dodjem do trece godine razumeti o cemu vi ovde pricate, a kada dodjem do cetvrte da cu znati ko je u pravu.
 
audiofreak je napisao(la):
Pa sam si rekao da treba da bude samo DB, a ne DB+x.
...
2. Teraju DVA serverska softvera (MSSQL i Citrix) na JEDNOJ masini (prvi pasus teksta) za sta si takodje ti rekao (a i s tim se slazem) da nije dobra stvar.
...

Nope, izvlacenje iz konteksta; nisam rekao da treba da bude samo DB, nego da je to namenska masina, sto znaci da se na tome ne tera "gomila programa", a ne da ne sme da se potera makar i jedan program pored DB servera (pogotovo ako admin zna prosecna opterecenja koje doticni programi imaju).

To sto taj drugi program ima serverski karakter znaci da program po prirodi opsluzuje klijente, ali ne da i nuzno zauzima gro cpu/ram resursa. Jedan SSHd je takodje server program, ali tesko da ce sam po sebi da pojede cpu time. Sto se tice ovog terminal servera, ljudi su u specifikaciji jasno naveli preporuku glede system requirementsa; za opsluzivanje terminala i remote desktop konekcija za 1-20 konkurentnih konekcija preporuka je P3@550MHz, 20-40 P3@700MHz, itd, sto jasno ilustruje nekakvo skaliranje - nikakvu duali i ostalo nisu preporuceni. MS-ova specifikacija za 2k3 terminal services je takodje tu negde - P133 sa 128MB, 550MHz recommended.

audiofreak je napisao(la):
Problem se moze dosta ublaziti ali se ne moze u potpunosti izbeci jer je posledica deljenja cache-a i zapravo nema velike veze sa samom HyperThreading tehnologijom.

Ako nemaju veze sa HTT-om, kako objasnjavas da se performanse povecaju kada se HTT iskljuci?



E sad, zanimljivost u celoj prici nije kritika ljudi kako su se drznuli to da startuju na tom pentiumu (sto sam vec bio prokomentarisao, pa necu dodavati) i to cak dva programa paraleleno, nego je zanimljivost u dobijenoj brzini sa i bez HTT-a.
 
Poslednja izmena:
silverglider je napisao(la):
Ako nemaju veze sa HTT-om, kako objasnjavas da se performanse povecaju kada se HTT iskljuci?

Kao sto rekoh problem je u deljenom cache-u i u threadu koji suvise agresivno koristi isti (jer nije optimizovan da recimo radi sa manjim blokovima podataka). Sam HTT nema nikakve veze sa tim, da je dual-core sa deljenim cacheom isto bi se desilo. Problem je u softveru koji nije napravljen da se ponasa pristojno sa deljenim resursima i koji pretpostavlja da je cela masina njegova.

Nemam vise ni vremena ni zivaca da se objasnjavam, ko razume (i ko zeli da razume) shvatice.
 
Kakav si ti sofista ako ces sada da odustanes? :d
 
audiofreak je napisao(la):
Kao sto rekoh problem je u deljenom cache-u i u threadu koji suvise agresivno koristi isti (jer nije optimizovan da recimo radi sa manjim blokovima podataka). Sam HTT nema nikakve veze sa tim, da je dual-core sa deljenim cacheom isto bi se desilo. Problem je u softveru koji nije napravljen da se ponasa pristojno sa deljenim resursima i koji pretpostavlja da je cela masina njegova.
ovo sto si izneo su chiste spekulacije! Apsolutno ne postoji pouzdan nacin da ti argumentovano mozes da tvrdis da je problem do deljenja cachea!
 
silverglider je napisao(la):
E sad, zanimljivost u celoj prici nije kritika ljudi kako su se drznuli to da startuju na tom pentiumu (sto sam vec bio prokomentarisao, pa necu dodavati) i to cak dva programa paraleleno, nego je zanimljivost u dobijenoj brzini sa i bez HTT-a.
Kako ih nije sram? 😀 :d 😀

@Audio
/* vezano za sistem vrednosti 😉 */
Znas li koliko je skuplji (vredniji) SQL ili neki drugi profi softver od jednog obicnog parceta silikona? Svako ko ulazi u te vode gleda da se prilagodi softveru (tj. trazi makinu koja ce da vuce debelu prikolicu a ne obratno).

Inace mislim da nema smisla emotivno se vezivati za neko parce HW (osim ako to nije 3Dfx) :eyebrows:
 
audiofreak je napisao(la):
Kao sto rekoh problem je u deljenom cache-u i u threadu koji suvise agresivno koristi isti (jer nije optimizovan da recimo radi sa manjim blokovima podataka). Sam HTT nema nikakve veze sa tim, da je dual-core sa deljenim cacheom isto bi se desilo. Problem je u softveru koji nije napravljen da se ponasa pristojno sa deljenim resursima i koji pretpostavlja da je cela masina njegova.

Ovo je sasvim moguce. Ali to ipak ne opravdava Intel i njegovu kobajagi implementaciju hyperthreading-a nakalemljenu na NetBurst. Da bi hyperthreading funkcionisao kako treba mora se imati vise izvrsnih jedinica.
 
audiofreak je napisao(la):
Tebi nesto sa prioritetima operacija nije u redu. Reci mi zar zaista mislis da hardver treba razvijati prema starom softveru?!?

milslim da je je ovo definitivno dobar stav. Intel je iz svog Pentiuma4 izbacio barrel shifter i shiftovanje prebacio na Pentiumov ALU koji je isti posao obavaljao 7 puta sporije nego 486 (1 clock))! Shitovanje se obilno koristilo za sve i svasta, npr. deljenje sa 2 je bilo mnogo brze shiftovanjem nego upotrebom odgovarajuce operacije deljenja. Glavni problem je sto su i kompajleri koristili ovaj trik, nisam siguran ali verujem da su i posle pojave Pentiuma4 i Athlona ostale ove legacy optimizacije...

BTW Intel Pentium4 sa HT-om radi osetno bolje u Windowsu od recimo AMD bez HT-a. Prosto je neverovatan osecaj koliko sve radi mekse i kako Windows bolje i brze reaguje na komande. npr. pri pakovanju video materijala ili renderingu kliknete na start meni i on se odmah pojavi na intelu dok na AMD kad je CPU 100% zauzet uvek postoji lag (jeste da ce AMD brze da zavrsi posao ali 😉 ) ...mogu samo da zamislim kako bi radio AMD DualCore 😀
 
kovacm je napisao(la):
Prosto je neverovatan osecaj koliko sve radi mekse i kako Windows bolje i brze reaguje na komande. npr. pri pakovanju video materijala ili renderingu kliknete na start meni i on se odmah pojavi na intelu dok na AMD kad je CPU 100% zauzet uvek postoji lag
Druze, gori si od Saleta koji oseca wireless lag na desktopu :d
 
Nedjo je napisao(la):
ovo sto si izneo su chiste spekulacije! Apsolutno ne postoji pouzdan nacin da ti argumentovano mozes da tvrdis da je problem do deljenja cachea!

Nedjo, ja se ne bavim spekulacijama. Postoji primer koda na onom blogu pomenutom u njihovom tekstu koji izaziva ovakav problem i pad performansi bas tako sto jedan thread namerno trashuje cache izazivajuci time usporenje drugog threada.

mcekovic je napisao(la):
Ali to ipak ne opravdava Intel i njegovu kobajagi implementaciju hyperthreading-a nakalemljenu na NetBurst.

Sa 5% dodatih tranzistora do 30% ubrzanja u optimizovanim aplikacijama je po meni sasvim solidna implementacija. Naravno da moze bolje ali to bi onda bilo i primereno skuplje, a ovo je gratis.

mcekovic je napisao(la):
Da bi hyperthreading funkcionisao kako treba mora se imati vise izvrsnih jedinica.

To bi svakako pomoglo u vecini slucajeva, medjutim ako je resurs za koji se threadovi nadmecu L1/L2 cache kao u ovom slucaju, tu onda nema pomoci osim da se uradi optimizacija i da se thread koji je gladan memorije natera da radi u malim blokovima koji staju recimo u 1/4 cache-a.

OFFTOPIC:

kovacm je napisao(la):
Glavni problem je sto su i kompajleri koristili ovaj trik, nisam siguran ali verujem da su i posle pojave Pentiuma4 i Athlona ostale ove legacy optimizacije...

Jesu, ostale su mnoge legacy optimizacije. Svaka nova generacija procesora ima svoje cake medjutim nista od ovoga pomenutog ne utice tako drasticno na performanse kao L1/L2 cache miss, samomodifikujuci kod, denormali/izuzeci u floating point izracunavanju, blokiranje store to load/load to store forwarding-a ili nepredvidljiv ishod grananja.

Naravno, grananje nikad ne moze biti 100% predvidljivo ali ima slucajeva gde se performanse mogu popraviti veoma prostim izmenama programa. Interesantno je da kad se pomenu optimizacije vecina ljudi odmah pomisli na asembler i tesko razumljive stvari, a uopste ne mora da bude tako. Evo primera:
Kod:
switch (a) {
case 0:
    Radi0();
    break;
case 1:
    Radi1();
    break;
case 2:
    Radi2();
    break;
case 3:
    Radi3();
    break;
}
Ako znamo da je a najcesce jednako 2 onda je bolje napisati ovako:
Kod:
if (a == 2) {
    Radi2();
} else {
    switch (a) {
    case 0:
        Radi0();
        break;
    case 1:
        Radi1();
        break;
    case 3:
        Radi3();
        break;
    }
}
Tako ce procesor (cak i AMD) mnogo lakse moci da predvidi ishod grananja, a mi uopste nismo morali da posegnemo za asemblerom i optimizujucim kompajlerima.
 
Poslednja izmena:
Nazad
Vrh Dno