Conroe in action!!!

Space · 18.05.2006

Od silnih pesnika,pa do ljudi koji pisu sve sto nije vezano na temu,evo malo svezih rezultata.Pozeljno je sve da se procita!:d
http://www.xtremesystems.org/forums/showthread.php?t=99882
http://www.xtremesystems.org/forums/showthread.php?t=99892

kovacm · 18.05.2006

moderatori su obrisali pesmu?

stormwatch153 · 18.05.2006

Jedno glupo pitanje, ovo je vec postavio jean citalac na XS forumu, zasto nigde nema linka za oficijalne rezultate?

The pocetnik · 18.05.2006

stormwatch153 je napisao(la):
Jedno glupo pitanje, ovo je vec postavio jean citalac na XS forumu, zasto nigde nema linka za oficijalne rezultate?

Mozda, zato sto CPU jos nije zvanicno izasao u prodaju...

okmijun · 18.05.2006

kovacm je napisao(la):
moderatori su obrisali pesmu?

Da bre ja se sinoc slatko nasmejao
al je cenzura... :whip:

stormwatch153 · 18.05.2006

The pocetnik je napisao(la):
Mozda, zato sto CPU jos nije zvanicno izasao u prodaju...

Heh...veoma lukav i zanimljiv odgovor...nisam mislio na oficijalne testove...nego na validaciju linka 🙂 😀

MadTexel · 18.05.2006

audiofreak je napisao(la):
To za latenciju instrukcija nije tacno jer ne prolaze sve instrukcije kroz sve stepene u pajplajnu i postoje razni nacini za skracivanje latencija. Vec smo se mcekovic i ja raspravljali na tu temu pa da ne bih pisao sve ponovo potrazi ovde na benchu, dao sam cak i link na PDF gde lepo pise kakvi su "trikovi" korisceni u Netburst arhitekturi za smanjenje latencije instrukcija.

I pored takvih smanjivanja, dubok pipeline je dubok pipeline, pa još sa malo registara. Nemoj sad da spominješ preimenovanje registara jer se ništa ne može meriti sa istim brojem vidljivih registara.

Sto se tice broja registara, sve je to lepo (taj RISC koncept) ali po meni je sasvim svejedno da li imas 128 registara na raspolaganju ili 8 i hardverski register renaming.

Taj RISC koncept nije priča za malu decu ili tako nešto, već realnost koju svi koriste. Uostalom, P4 nema klasičan instrukcijski keš već čuva dekodirane operacije čija je dužina 8B (zaključak na osnovu analize drugih parametara). Ili ti misliš da je zaista moguće izvršavati instrukcije kojima je jedan source operand u memoriji u pipelineu?

Možda jeste isto ako pišeš program u C/C++, F77/90/95. U Javi je sigurno svejedno kad je JVM stek mašina. Međutim, iz ugla (bar) dve grupe ljudi stvar je bitno različita. Prvi su ljudi koji prave kompajlere jer većina heuristika za alokaciju registara pada ako je broj registara manji od 16. Drugi su projektanti procesora. Čini se da nisi upoznat sa kompleksnošću algoritama za preimenovanje registara. Sem što su prilično složeni, zahtevaju dosta resursa (pa i neke nezgodne komponente) i samim tim su neprijatelj visokog takta.

Odakle ti ta ideja da integer programi imaju manji stepen paralelizma??? Dokle god je izracunavanje u pitanju moze se paralelizovati. Pogotovo ako je u pitanju obrada slike, zvuka -- bilo kakva multimedija jer nemoj zaboraviti sve su to integerski podaci. Sto se tice loop unrolling to je samo jedna od tehnika koja se koristi.

Ideja mi odatle gledajući SPEC testove i poredeći ih int i fp delove. Ti poslovi o kojima pričaš su primarno DSP, a integeri/fixed point se često koriste samo zbog sporosti fpa. Ist, činjenica je da su do skoro fp DSPovi bili srazmerno skupi i da fp troši više struje pa je sasvim razumljivo da je uložen napor da se razviju integer algoritmi. Zatim, nisam video procesor (sem DSPova) koji ima integer množenje brže od floating point množenja. Što se tiče tehnika optimizacije, razmotavanje petlji je jedna od najosnovnijih i najefektnijih. Ali da ovo ne preraste u thread o optimizacijama...veruj mi da MIPS Pro kompajleri imaju sve optimizacije koje ti mogu pasti na pamet, i još po neku. 😀 Što se tiče obrade slike: misliš li na zezalice tipa Photoshop ili na stvari poput analiza, filtriranje, segmentacija, morfologija..?

To da dokle ima računanja posao se može paralelizovati je glupost. Paralelizacija je moguća samo kad nema međuzavisnosti po podacima i ni u jednom drugom slučaju. Ako paralelizuješ primer dole možeš da počneš da pišeš doktorsku disertaciju, a na osnovu patentnih prava za tu tehniku bio bi (dolarski) milioner.

addui at,zero,200
addui t7,zero,100
ori at,t7,80

Ovo ni prosleđivanje ne bi spasilo stallova, tako da o paralelizaciji nema govora.

Hajde ako te ne mrzi objasni mi ukratko razliku, nemam vremena trenutno da se smaram time.

Mi pričamo o procesoru, a ti ne razlikuješ osnovne pojmove? :-devil-: :wall: Arhitektura je ono što se vidi iz asemblera: broj registara, njihova širina, set instrukcija, tipovi podataka. Broj i dubina pipelinova (ako ih uopšte ima), asocijativnost keša, širina magistrale, sve je to stvar organizacije konkretnog CPUa. Nije valjda da kroz asembler vidiš da li je proces 90 ili 65 nm? 😀

Ne vidim problem u tome.

Ako ti ne vidiš problem ne znači da ga nema. Sem manje mogućnosti za razmotavanje petlji mnogo važnije je da to dosta koči optimizujuće kompajlere.

Posto iza 2 nema tacke pretpostavljam da si hteo da kazes dva adresna formata. Ni tu ne razumem u cemu je problem?

Intelovo tvrdoglavo insistiranje na dvoadresnom formatu instrukcija kad je poznato da kompajleri više vole troadresni. x86 instrukcije imaju raznorazne dužine pa se postavlja pitanje što nisu ubacili još par bitova za kodiranje posebnog destination registra.

Ovo nema veze sa SSE2 nego sa sirinom data busa ali pretpostavljam da ti je to jasno ako znas razliku izmedju arhitekture i organizacije? :trust:

Naprotiv, to nema veze sa širinom busa. Inače, procesori ne bi mogli da imaju po 64 elemnta u registru (svaki element 64b tj double - ukupno 4096 bitova). Takvi procesori nisu bili ne znam ni ja šta, nacrti ili beta verzije, već su se proizvodili i prodavali.

Uopste nisi u pravu. Prvo vecina proracuna ne trazi double precision matematiku pa je float (koga ima 4 u SSE) sasvim dovoljan. Inace i uraditi dva deljenja ili mnozenja u double precision za vreme koje je potrebno za jedan inace preko FPU je cist car.

Da naravno. Većina poslova ne zahteva double. Još veći broj poslova ne zahteva fp aritmetiku. Nažalost, postoji dosta poslova gde je korišćenje double preciznosti imperativ. Recimo, iterativno poboljšavanja rešenja sistema jednačina. I u Cu zgrađene f-je su sve double.

Inace SSE ADDPS (4x float ADD) traje 4-5 taktova sa throughputom 2, dok MULPS traje 6-7 (Northwood-Prescott) sa istim throughputom. To znaci da imas od 1-1.25 taktova za sabiranje (po elementu) i 1.5-1.75 taktova za mnozenje. Pride, sta mislis o tome koliko traje jedan ciklus kod svakog od tih procesora?

Jako lepa priča. Nisi naveo tačne latencije i repeat rateove instrukcija, a throughput je simpatična mera, ali nije baš reprezentativna kod skalarnih i kvazivektorskih instrukcija. Zbog malog broja registara veća je mogućnost register spilla što znači da mora da se poteže keš ili memorija. Za program koji sabira 4-5 registra i to radio 10^10 puta, sve će biti super. Ali, u praksi su od interesa uglavnom daleko veći workloadi.

Odavno su ljudi videli da se izvršne jedinice mogu optimizovati za smanjivanje latencije ili povećanje throughputa i obično se za skalarne smanjuje latencija, a za vektorske povećava throughput. Međutim, pošto SSE ima vektorčiće sa 2 ili 4 elementa to je suviše malo posla da se povećanje latencije amortiziuje na velikom broju korisnih opepracija.

Jel se ovo odnosi na mene? Ako je odgovor da onda si debelo pogresio jer ja imam iskustva sa tim.

Dobro..ti si jedan. Ajde da krenemo da brojimo sve one koji pričaju o optimizacijama za novi procesor, grafičku ili šta već, a koliko od tih ljudi programira, i to ne u VBu, PHPu, Perlu i sličnim jezicima. Ispade da su potrebne optimizacije i napor kao da se program prebacuje na drui procesor i os.

Mozda u odnosu na AltiVec i tome slicno ali na x86 platformi je jos uvek suvise nova (citaj slabo se koristi). Ako si mislio da je bajata u smislu tehnike onda ne bi bilo lose da kazes i koje su tehnike po tebi bolje?

Bajata u smislu da se o tome (skoro) sve zna. Vektorizujući kompajleri postoje 30 godina i danas teško da postoji petlja koju bi čovek mogao da vektorizuje, a kompajler ne. Uostalom, sad je nekih 7 godina kako je izašao P3 i doneo SSE instrukcije.

To zavisi od mnogo faktora. Ako je kod napisan tako da je lokalitet podataka los onda ni najbolji kompajler ne moze tu nista da uradi. Uzgred, nisi naveo da li je taj rezultat postignut MSVC ili ICC kompajlerom. Ja ti iz licnog iskustva mogu reci da su retka ubrzanja manja od 50% za ispravno napisan algoritam.

To je ubrzanje MSVC6 vs ICC7. Ima dosta kodova čiji je i vremenski i prostorni lokalitet uglavnom katastrofalan, ali takva je priroda problema i jedino drastično povećanje keša može da pomogne.

Ja naprotiv verujem da je kamen o vratu LEGACY kod, kao i neznanje i nezainteresovanost programera da koriste sofisticiranije metode od brute force.

Taj legacy kod je x86, koji je čist CISC i nije pravljen sa idejom da se brzo izvršava. Sa druge strane, delimično si u pravu. Recimo ulančane liste kao vrlo popularna struktura su nemoguće za vektorizaciju. Strukture za pamćenje slabo popunjeih vektora su uglavnom domen specijalizovanih primena koje ne spadaju u domen "opštih" programerskih stvari. FPU stek je bio i ostao jedan od najvećih kamena o vratu koji sprečava kompajler da optimizuju kod.

Ja priče o specijalnom asm kodiranju, specijalnim makroima i funkcijama uglavnom ne priznajem. Dobar kompajler će uglavnom uspeti da optimizuje lepo napisan kod, da ubaci pozive specijalnih funkcija na većem nivou optimizacije. Eventualno uz upotrebu nekih direktiva (standardnih tipa OpenMP ili zavisnih od kompajlera). Srećom, i Intel i AMD su postali svesni toga pa isporučuju standardne biblioteke optimizovane za svoje procesore.

Probao ja, Ooura algoritam koji koristim je par puta brzi nego recimo qsort iz C runtime biblioteke. I onda u cemu je problem? Reci cu ti ja -- u algoritmu i kodu, a ne u hardveru.

Poenta sa FFT je da je to nešto što je zahtevno i, mnogo bitnije, od interesa u praksi. Recimo za obradu signala i rešavanje parcijalnih jednačina. Isto važi i za iterativne solvere koji su jedini poznati metod da se reše ogromni sistemi jednačina (100K-1M +). Dotični metodi zbog načina smeštanja matrice jako opterećuju memorijski sistem, ali ko misli da je to loše, neka smisli bolje.

Naspram ovoga, računanje broja Pi na milione decimala iznova i iznova je u domenu zanimljivosti. Lep sport, ali u praksi je ~30 tačnih cifara plafon. "Testovi" tipa računanje Fibonačijevih brojeva, kao i sintetički testovi su gubljenje vremena i zaluđivanje naroda. Isto kao što se ni performanse CPUa ili CPU/RAM ne mogu oceniti na osnovu jednog ili dva broja i na osnovu toga reći šta je definitivno brže.

Nedjo · 18.05.2006

Au! Medtexele ja se s tobom ne bi zayebavao 😀
Dok sam mogao pratiti ovaj post odozgo je bio fenomenalan. verovatno je jos bolji kasnije, ali ostavicemo Audiju da sudi o tome (ako moze 😉)

audiofreak · 18.05.2006

MadTexel je napisao(la):
Nemoj sad da spominješ preimenovanje registara jer se ništa ne može meriti sa istim brojem vidljivih registara.

Koja je prednost veceg broja vidljivih registara ako postoji zavisnost izmedju podataka i ako se podaci moraju ucitavati u registre u svakom slucaju?
Kod dobro optimizovanog x86 koda, skoro da nema spilovanja vrednosti iz varijabli u memoriju.

MadTexel je napisao(la):
Uostalom, P4 nema klasičan instrukcijski keš već čuva dekodirane operacije čija je dužina 8B (zaključak na osnovu analize drugih parametara).

Pogresan zakljucak. Ovde (PDF) imas malo detaljniju (da ne kazem brutalnu) analizu trace cachea i njegove organizacije.

MadTexel je napisao(la):
Ili ti misliš da je zaista moguće izvršavati instrukcije kojima je jedan source operand u memoriji u pipelineu?

Naravno da je moguce, cemu ti sluzi cache i prefetcher?

Nagradno pitanje za tebe, kako RISC ucitava vrednost iz memorije u registar? Meditacijom? Ili je i to instrukcija kojoj je source oprand memorija?!?

MadTexel je napisao(la):
Možda jeste isto ako pišeš program u C/C++, F77/90/95. U Javi je sigurno svejedno kad je JVM stek mašina.

I meni je u asembleru svejedno, uvek ima dovoljno registara ako se problem razbije na dovoljno male celine sto je i inace preporucljivo.

MadTexel je napisao(la):
Međutim, iz ugla (bar) dve grupe ljudi stvar je bitno različita. Prvi su ljudi koji prave kompajlere jer većina heuristika za alokaciju registara pada ako je broj registara manji od 16.

To je mozda problem nekome, Intelovcima nije sigurno -- moraces ili da mi verujes na rec ili da disasembliras sam pa da vidis koliko je efikasan.

MadTexel je napisao(la):
Drugi su projektanti procesora. Čini se da nisi upoznat sa kompleksnošću algoritama za preimenovanje registara. Sem što su prilično složeni, zahtevaju dosta resursa (pa i neke nezgodne komponente) i samim tim su neprijatelj visokog takta.

Ako su tako nepogodni, i neprijatelji visokog takta, a RISC ih nema -- kako to da onda RISC vec ne radi na 10+ GHz?

MadTexel je napisao(la):
Ti poslovi o kojima pričaš su primarno DSP, a integeri/fixed point se često koriste samo zbog sporosti fpa.

Nije ni to tacno, vec zato sto apsolutno nema potrebe za vecom preciznoscu. Takodje, kod mesanja audio signala razlicitih amplituda fixed point je daleko bolji od floating pointa -- o tome procitaj ovde.

MadTexel je napisao(la):
Što se tiče obrade slike: misliš li na zezalice tipa Photoshop ili na stvari poput analiza, filtriranje, segmentacija, morfologija..?

Wiener filtriranje, dekonvolucije, itd.

MadTexel je napisao(la):
To da dokle ima računanja posao se može paralelizovati je glupost.

Napisi mi to u C-u, mrzi me da se smaram sa desifrovanjem RISC instrukcija.

MadTexel je napisao(la):
Nije valjda da kroz asembler vidiš da li je proces 90 ili 65 nm? 😀

Vidim ako izvrsim CPUID instrukciju i procitam odgovarajuci MSR. I sta sad? :-devil-:

MadTexel je napisao(la):
Sem manje mogućnosti za razmotavanje petlji mnogo važnije je da to dosta koči optimizujuće kompajlere.

Prvo, zasto mislis da je razmotavanje kljucna optimizacija? Drugo, zasto mislis da 8 registara koci optimizujuce kompajlere? Iskreno, kad si poslednji put pogledao x86 asemblerski kod? Ako je to u vreme Pentiuma 1 i uparivanja instrukcija za U i V pajpove onda je krajnje vreme da pogledas ponovo, pogotovo kod koji generise ICC.

MadTexel je napisao(la):
Intelovo tvrdoglavo insistiranje na dvoadresnom formatu instrukcija kad je poznato da kompajleri više vole troadresni.

Koliko vidim njihov kompajler se vise nego dobro snalazi sa tim sto ima, a sto bi neko preko hleba pogacu... :smoke:

MadTexel je napisao(la):
Naprotiv, to nema veze sa širinom busa. Inače, procesori ne bi mogli da imaju po 64 elemnta u registru (svaki element 64b tj double - ukupno 4096 bitova).

Koliko su cesti takvi procesori? Na kom taktu takav cip maksimalno moze da radi? Kakav cache mora da ima? Data bus? Memoriju? Koliko to sve kosta? Da li je za desktop?

MadTexel je napisao(la):
Nažalost, postoji dosta poslova gde je korišćenje double preciznosti imperativ. Recimo, iterativno poboljšavanja rešenja sistema jednačina.

Znam, ali postoji nacin da neke delove racunas sa FP a medjurezultate samo u double ukoliko procenis da je dovoljno precizno i da se dobija u brzini.

MadTexel je napisao(la):
I u Cu zgrađene f-je su sve double.

C++ ima overload za float verzije.

MadTexel je napisao(la):
Nisi naveo tačne latencije i repeat rateove instrukcija, a throughput je simpatična mera, ali nije baš reprezentativna kod skalarnih i kvazivektorskih instrukcija.

Nece biti, naveo sam tacne latencije i repeat rate. Throughput je mera koliko taktova treba da protekne pre nego sto moze da startuje sledeca ista takva instrukcija, znaci prakticno isto sto i rate.

MadTexel je napisao(la):
Zbog malog broja registara veća je mogućnost register spilla što znači da mora da se poteže keš ili memorija.

Postoji gomila ljudi koja se tripuje da veci broj registara nesto znaci. To su uglavnom programeri koji pisu spageti kod od 100-nak funkcija u jednom fajlu -- svaka sa po minimum 50 varijabli ciji su nazivi plafon 2 slova, bar deset nested for petlji i inline funkcijama unutar drugih funkcija. Pritom, nemilice stede beline i ne koriste { space ni propisnu indentaciju i posle se cude sto je sve to sporo i sto im trebaju ne sati nego dani da nateraju kod da uopste proradi. Za njih preporucujem Linux Kernel Coding Style kao pocetnu tacku u edukaciji i uopste nemam zelju da se dalje sa takvima prepucavam.

MadTexel je napisao(la):
Bajata u smislu da se o tome (skoro) sve zna. Vektorizujući kompajleri postoje 30 godina i danas teško da postoji petlja koju bi čovek mogao da vektorizuje, a kompajler ne. Uostalom, sad je nekih 7 godina kako je izašao P3 i doneo SSE instrukcije.

Skoro svaka petlja u kojoj postoji konverzija tipova za koju ne postoji direktna instrukcija u setu se ne moze automatski vektorizovati. Probaj i sam pa ces videti.

MadTexel je napisao(la):
To je ubrzanje MSVC6 vs ICC7. Ima dosta kodova čiji je i vremenski i prostorni lokalitet uglavnom katastrofalan, ali takva je priroda problema i jedino drastično povećanje keša može da pomogne.

MSVC6 je uzasan. ICC7 je sada vec star, a ICC9 je mnogo agresivniji u optimizaciji. Takodje, pitanje je koje ste switcheve koristili za ICC.

Sto se tice lokaliteta to se da srediti. Ne znam da li si upoznat sa cinjenicom da se nekad vise isplati prepakovati podatke da budu blizu pa pustiti obradu nego raditi obradu nad podacima koji imaju los lokalitet. No i to moze da se proba...

MadTexel je napisao(la):
Taj legacy kod je x86, koji je čist CISC i nije pravljen sa idejom da se brzo izvršava.

Upoznaj se malo bolje sa pojmom legacy kod.

Primer - kod koji izaziva Partial register stall (zbog pristupa celom registru nakon upisa samo jednog dela):

Kod:

cmp	eax, ecx
setle	dl
and	edx, 0xFF

Resava se prosto:

Kod:

xor	edx, edx
cmp	eax, ecx
setle	dl

I prvu i drugu sekvencu generise kompajler. Prvu generise MSVC6, a drugu svi moderniji. I jedno i drugo je smislio covek, a u prvom slucaju doticni nije imao pojma o hardveru i nacinu na koji funkcionise. O tome ja pricam.

MadTexel je napisao(la):
Ja priče o specijalnom asm kodiranju, specijalnim makroima i funkcijama uglavnom ne priznajem. Dobar kompajler će uglavnom uspeti da optimizuje lepo napisan kod...

Tacno, ali izuzetaka ima i tada se mora raditi rucno. Ako treba neki primer samo reci, tu sam.

MadTexel je napisao(la):
Poenta sa FFT je da je to nešto što je zahtevno i, mnogo bitnije, od interesa u praksi.

Danas se FFT moze racunati i na GPU.

MadTexel je napisao(la):
Isto kao što se ni performanse CPUa ili CPU/RAM ne mogu oceniti na osnovu jednog ili dva broja i na osnovu toga reći šta je definitivno brže.

Sa ovim se slazem.

GIGAFAN · 18.05.2006

Mala skola mikroprocesora,cpu-a,i sl. 😀

Space · 18.05.2006

stormwatch153 je napisao(la):
Heh...veoma lukav i zanimljiv odgovor...nisam mislio na oficijalne testove...nego na validaciju linka 🙂 😀

Procitaj pazljivo oba linka ivideces da postoji CPU-Z validacija.

DARK SIDE · 18.05.2006

Ovi programeri razvukli prichu 😀
A ovaj core duo ili conroe ili kako vec?Jel to radi bolje ono shto ste ispisali gore?Taj kesh,mesh,trt mrt,risc-cisc(uh ovo bilo davno)...cccccc..😀
Odosmo van thread-a.@Spacemaster pokusava da bude"back on track"....odlucio sam se da kupim taj 6600 i gotovo...opet cu da puknem lovu 😀...bice razvoda braka...😀

illidan · 18.05.2006

Conroe by FUGGER

odgovara vam ovo?

DARK SIDE · 18.05.2006

illidan je napisao(la):
Conroe by FUGGER

odgovara vam ovo?

"OUCH!!!

that was heard from an AMD engineer when he had a look at this score"
😀 😀 :d 😉

Space · 18.05.2006

Covek vec postovano!

illidan je napisao(la):
Conroe by FUGGER

odgovara vam ovo?

:d

illidan · 18.05.2006

sorry nisam video, citao sam tred na xs 🙂

neka brisu ovo modovi 🙂

genuine · 19.05.2006

Zar ne postoje procesori u GaAs na 10GHz i jace... GaAs je uvek isao na 4 puta vecoj frekvenciji od Si .... jedino sto ne moze toliki stepen integracije problema zbog odvodjenja toplote?

kovacm · 19.05.2006

audiofreak je napisao(la):
Koja je prednost veceg broja vidljivih registara ako postoji zavisnost izmedju podataka i ako se podaci moraju ucitavati u registre u svakom slucaju?
Kod dobro optimizovanog x86 koda, skoro da nema spilovanja vrednosti iz varijabli u memoriju.

zar renaming registara nije patch za x86 procesore da bi legacy kod mogao da radi? i uostalom sta je vidljivo (kakvi i koliko) registara kod x86 - 8?? a koliko/sta u AMD64 modu?

audiofreak je napisao(la):
Koliko su cesti takvi procesori? Na kom taktu takav cip maksimalno moze da radi? Kakav cache mora da ima? Data bus? Memoriju? Koliko to sve kosta? Da li je za desktop?

nije ni bitno... ionako sve sto dolazi iz intela za x86 je vec odavno vidjeno... tako da ce se i za desktop jednog dana pojaviti ovakvi monstrumi...

Snejk · 19.05.2006

Pade i 12 sekundi.. Možda i jeste glupavi super PI, ali da je brzo, brzo je.

morbius · 19.05.2006

genuine je napisao(la):
Zar ne postoje procesori u GaAs na 10GHz i jace... GaAs je uvek isao na 4 puta vecoj frekvenciji od Si .... jedino sto ne moze toliki stepen integracije problema zbog odvodjenja toplote?

SiGa čipovi podnose i mnogo viši takt od toga. Ali postoje razlozi zbog čega se oni ne primenjuju u PC-u.
Enivej, ovo ti je žešći offtopic i pazi da u budućnosti ne ubacuješ ovakve stvari u threadove koji sa tim nemaju veze. Ovde se priča o Conroe-u.

Maki · 19.05.2006

Jedno maleno pitanje....

Narode, nisam pratio Intel scenu neko vreme, pa sam neupućen..
Jako mi se svideo Pentium D 805 pa sam mislio da se ponovim, koju ploču/čipset da odaberem, da kasnije mogu daubacim Conroe. Ja sam overkloker u srcu i duši pa predložite neku ploču koja je dobra za to.
Fala!!

audiofreak · 19.05.2006

Maki je napisao(la):
Narode, nisam pratio Intel scenu neko vreme, pa sam neupućen..
Jako mi se svideo Pentium D 805 pa sam mislio da se ponovim, koju ploču/čipset da odaberem, da kasnije mogu daubacim Conroe. Ja sam overkloker u srcu i duši pa predložite neku ploču koja je dobra za to.
Fala!!

Ako si overclocker cekaces neku Asus ili Gigabyte (ili cak DFI) plocu koja je Conroe Ready. Za sada takvih nema u prodaji jer jos nisu napravljene.
Ako si weekend overclocker kao ja onda ces uzeti Intel Bad Axe rev 304 pa navise. Samo da te upozorim da je cena te ploce preko 250e.

DARK SIDE · 19.05.2006

Maki je napisao(la):
Narode, nisam pratio Intel scenu neko vreme, pa sam neupućen..
Jako mi se svideo Pentium D 805 pa sam mislio da se ponovim, koju ploču/čipset da odaberem, da kasnije mogu daubacim Conroe. Ja sam overkloker u srcu i duši pa predložite neku ploču koja je dobra za to.
Fala!!

Plocha koja prima Intel Conroe je intel plocha sa 975bx(bad axe) chipsetom i malo je teze naci kod nas.Ove ostale idu samo do Intel Preslera 9XXX.A primaju i seriju 8XXXX...preporuchujem Asus p5wd2 jer joj je cena pala na 160eu.
PS.malo si off topic ali ajd'...da budem fer i ja sam chesto...😀

audiofreak · 20.05.2006

Sad videh rezultate -- znaci bruka. Jos kad bi fugger postovao Sandru (bandwidth)...

MadTexel · 20.05.2006

audiofreak je napisao(la):
Koja je prednost veceg broja vidljivih registara ako postoji zavisnost izmedju podataka i ako se podaci moraju ucitavati u registre u svakom slucaju?
Kod dobro optimizovanog x86 koda, skoro da nema spilovanja vrednosti iz varijabli u memoriju.

Prednost je kod obrade petlji, vidi dole. Skoro? Na tvom kodu ili uopšte? Imaš neku nezavisnu studiju da potkrepiš tu tvrdnju?

Pogresan zakljucak.

Predlađem da tu ispravku pošalješ i autorima knjige u koji su između ostalog radili analizu P4. Profesori na priznatim američkim univerzitetima, iza sebe imaju dosta praktičnih projekata iz oblasti procesora.

Naravno da je moguce, cemu ti sluzi cache i prefetcher?

Bilo koja ALU operacija kojoj je jedan operand u memoriji koja nije keširana. Ili push/pop neke memorijske lokacije.

Nagradno pitanje za tebe, kako RISC ucitava vrednost iz memorije u registar? Meditacijom? Ili je i to instrukcija kojoj je source oprand memorija?!?

Nagradno pitanje za tebe: da li si u životu programirao jedan RISC? Rekao bih da nisi...
MIPS: lw a0,8(sp) <-- load word u a0, sa adrese sp+8
ili sa hardverskim imenima: lw $4, 8($29). Word je 32b
Alpha: LDL R4,8(R29)
PA-RISC: LDW GR4,8(GR29)
Postoje i parnjaci koji rade sa sa 64b podacima.

Jedino se učitava vrednost i ništa više. Uostalom, i ALU operacije koje potežu sa memorijom se interno izdele baš na ovakve operacije. To ni Intel ne krije.

I meni je u asembleru svejedno, uvek ima dovoljno registara ako se problem razbije na dovoljno male celine sto je i inace preporucljivo.

Sasvim razmuno i preporučljivo, ali ima slušajeva kad to nije tako, a ti slučajevi su od interesa u primenama.

To je mozda problem nekome, Intelovcima nije sigurno -- moraces ili da mi verujes na rec ili da disasembliras sam pa da vidis koliko je efikasan.

Ti si, naravno, kompajlirao kod kao da ima 16, 32, 64 registra i onda si na osnovu toga doneo zaljučke? Tako se meri uticaj broja registara na kompajler. Ovako, ti porediš izlaz Intelovog kompajlera sa samim sobom.

Ako su tako nepogodni, i neprijatelji visokog takta, a RISC ih nema -- kako to da onda RISC vec ne radi na 10+ GHz?

I RISC procesori koriste te tehnike. Zatim, takt zavisi i od tehnologije izrade gde Intel ima prednost zbog većeg tržišta.

I molim te, nemoj da porediš taktove i uz njih peak performanse. Deluješ smešno. Samo konkretni rezultati iz aplikacija i testova tipa SPEC, NASPB, PERFECT, LL i slični. Već sam napisao poređnje Alphe i R10000, vidi razliku između peak performansi i rezultata u radu.

Nije ni to tacno, vec zato sto apsolutno nema potrebe za vecom preciznoscu.

Jel ovo thread o procesoru opšte namene ili DSPu za obradu zvuka? Odlepi se od obrade audio signala, ima još dosta drugih primena. Ja ti mogu reći da je fixed nepotreban za SOR algoritam. Ili možda GMRES ili BiCGSTAB. Što ne probaš da ih realizuješ u fixed aritmetici? I procesorima opšte namene manjka dosta DSP stvari kao što je aritmetika sa zasićenjem i brz MAC.

Wiener filtriranje, dekonvolucije, itd.

Pošto mnogo voliš audio, jel si mislio na audio ili sliku?

Napisi mi to u C-u, mrzi me da se smaram sa desifrovanjem RISC instrukcija.

Jak programer u asembleru, plus što pokazuješ da nisi programirao na takvim procesorima a pričaš kako rade. Ovo stvarno postaje bespredmetno. 🙂

c=a+b;
e=c+d:

Slučaj prave zavisnosti (u terminologiji kompajlera) ili RAW hazard (u terminologiji procesora).

Vidim ako izvrsim CPUID instrukciju i procitam odgovarajuci MSR. I sta sad? :-devil-:

Aha. I onda iz neke tabelice izvadiš podatak koliko taj procesor ima stepeni pipelinea, u kojem je procesu radjen i slične podatke. A šta kad izađe nov procesor? :-devil-:

Prvo, zasto mislis da je razmotavanje kljucna optimizacija? Drugo, zasto mislis da 8 registara koci optimizujuce kompajlere? Iskreno, kad si poslednji put pogledao x86 asemblerski kod?

To povećava koristan posao u petlji, daje scheduleru više prilike da rasporedi instrukcije, da sakrije latenciju load i fp operacija. I povećava potrebu za registrima. Uostalom, primer iz prakse, probaj da ga oboriš: KAI front end za IBM RS/6000 je pomoću unroll-and-jam i scalar replacment ubrzavao SPEC Matrix300 test 4.58 puta. To je jedan od glavnih razloga zašto je taj test izbačen. Koja optimizacija sem blokiranja može da proizvede takva ubrzanja?Takođe, razmotavanje petlji je osnova za vektorizaciju.

x86 ozbiljnije gledao pre oko godinu dana, ovlaš često. U međuvremenu sam uglavnom gledao kod sa 32 int i 32 fp registra, svi 64b.

Kada si ti zadnji put kodirao na nekom RISC procesoru? Nikad?

Koliko vidim njihov kompajler se vise nego dobro snalazi sa tim sto ima, a sto bi neko preko hleba pogacu... :smoke:

Ili kompajler sličnog kvaliteta kao na drugim platformama?

Koliko su cesti takvi procesori? Na kom taktu takav cip maksimalno moze da radi? Kakav cache mora da ima? Data bus? Memoriju? Koliko to sve kosta? Da li je za desktop?

Radili su na nekih 500 MHz pre 10ak godina, izrađeni u ECL tehnologiji, ali bilo ih i u CMOS, bez keša, cela memorija SRAM. Brkaš pojmove. Registar može da ima 64 elementa od po 64 bita, ali ne znači da će u jednom ciklusu da sve obradi. Koju to memoriju traži? Prosto: koliko para toliko muzike. Ako hoćeš procesor koji brže računa i da je to na realnim workloadima moraš da imaš brzu memoriju. Brz i jeftin procesor relativno lako napraviti, brza memorija je malo krupniji zalogaj. Za to je delom kriv trend smanjivanja jer mesto da glavna memorija bude organizovana u (recimo) 4 banke sa 4 modula postoji samo 1, eventualno 2 modula. Zamisli P4 na 3GHz, sa EDO RAMom. Sumnjam da bi to bio spektakularan procesor čim podaci izađu iz L2 keša.

Cena je prava sitnica danas, pošto napraviti takav registarski fajl nije mudrost, niti zahteva mnogo prostora, u stvari manje nego za skalarni r.f. iste brzine. Cena se lako amortizuje na ogromnom broju proizvedenih primeraka. Međutim, nije valjda problem na 100M tranzistora dodati 100-200K kad su slične registre imali procesori koji su celi imali u oko 800K tranzistora, pride rađeni u procesu od 1 mikron.

Znam, ali postoji nacin da neke delove racunas sa FP a medjurezultate samo u double ukoliko procenis da je dovoljno precizno i da se dobija u brzini.

Naravno da ovo treba raditi uvek gde se može. Nažalost, to često nije moguće. Ti previše generalizuješ iskustva iz svoje oblasti na ostale primene.

C++ ima overload za float verzije.

Ima to i C, na IRIXu. Standardizacija na papiru i u realnosti?

Nece biti, naveo sam tacne latencije i repeat rate.

I u međuvremenu imaš senku koju treba pokriti nečim. Više registara, više šansi da se senka pokrije. Throughput je koliko instrukcija izađe u svakom ciklusu.

Postoji gomila ljudi koja se tripuje da veci broj registara nesto znaci. To su

snip

Eno lameri na Riceu i u NASAi. Tvoj komentar deluje razumno, ali ga praksa demantuje. Najjednostavnije petlje tipa DAXPY, SAXPY, DOTPROD kad se razmotaju traže dosta registara.

Preprouka: sem Intelove literature, pogledaj i neku drugu, ali ne Linux nego recimo kako to radi NASA, dizajn procesora, guidove za vektorizaciju i paralelizaciju na Crayovima. Crayu je ona bila sve, a Intelu fin dodatak.

Skoro svaka petlja u kojoj postoji konverzija tipova za koju ne postoji direktna instrukcija u setu se ne moze automatski vektorizovati. Probaj i sam pa ces videti.

Nagradno pitanje: a zašto set instrukcija nije malo bolje dizajniran?
Pre nisu mogle da se vektorizuju petlje sa ifom u sebi, ili petlje koje su radile sa sparse matricama. Danas se i jedno i drugo, naročito drugo, vektorizuje bez većih problema.

MSVC6 je uzasan. ICC7 je sada vec star, a ICC9 je mnogo agresivniji u optimizaciji. Takodje, pitanje je koje ste switcheve koristili za ICC.

Znači otprilike, kad Intelov procesor zastari, onda je kompajler za njega dobar. Drugo, tada sam upoređivao brzine kompajlera. Sad sve ide Intelovim, a baš me nije mnogo zanimalo da se igram opcijama i beležim podatke.

Sto se tice lokaliteta to se da srediti. Ne znam da li si upoznat sa cinjenicom da se nekad vise isplati prepakovati podatke da budu blizu pa pustiti obradu nego raditi obradu nad podacima koji imaju los lokalitet. No i to moze da se proba...

Ne znam da li si upoznat sa pojmovima: unit stride access, non-unit stride access, scather/gather?

Upoznaj se malo bolje sa pojmom legacy kod.

snip

I prvu i drugu sekvencu generise kompajler. Prvu generise MSVC6, a drugu svi moderniji. I jedno i drugo je smislio covek, a u prvom slucaju doticni nije imao pojma o hardveru i nacinu na koji funkcionise. O tome ja pricam.

Legacy kod različitim ljudima različito znači. Nekima je sav kod u Fortranu legacy :-devil-: i to uglavnom onima koji ga nikad nisu videli.

Borlandovi daju još gori kod, čak i bez optimizacija koje se vide iz aviona, provereno u praksi. Ostaje mi da se zapitam zašto se VC6 i dalje koristi i podržan je od solidnog broja firmi i zašto Intel nije ranije počeo da razvija kompajlere.

Tacno, ali izuzetaka ima i tada se mora raditi rucno. Ako treba neki primer samo reci, tu sam.

GMRES i BiCGSTAB. Fixed point ako može. 😀

Danas se FFT moze racunati i na GPU.

"Svi procesori teže da postanu opštenamenski."
Ipak, GPUovi nemaju podršku za double i veliku količinu memorije. Za obradu slike ili signala, ok, za rešavanje ozbiljnijih PDEova - truba.

Rade GPUovi danas i iterativna rešavanja za PDEove. Super za dinamiku fluida u igrama. Ali niko pri zdravoj pameti neće uzeti da na GPU računa simulaciju turbine.

audiofreak · 20.05.2006

Mnogo si bre opsiran. Pokusacu da budem sto kraci jer smo i onako offtopic.

MadTexel je napisao(la):
Prednost je kod obrade petlji, vidi dole. Skoro? Na tvom kodu ili uopšte? Imaš neku nezavisnu studiju da potkrepiš tu tvrdnju?

Ja je licno nisam video, a bavim se time od prvog Pentiuma.

Na mom kodu nema spilova uopste. Na kompajlerovom retko, zaista retko kad i to ako je f-ja suvise kompleksna sto sam rekao da treba izbegavati.

Cak i kada u sred petlje radis nesto sa konstantom iz memorije jer nemas slobodan registar samo prvi prolaz ima penal, posle toga ta konstanta se vuce iz cachea. Pa nisu ovi danasnji procesori toliko mutavi bas kao sto bi ti da ih predstavis pred ostarelim RISC-om.

MadTexel je napisao(la):
Predlađem da tu ispravku pošalješ i autorima knjige...

Koje knjige?

Citat iz pentopt.pdf koji sam ti naveo kao izvor: Caching uops rather than opcodes enables the P4 to use RISC technology on a CISC instruction set. Na istom mestu (strana 76) imas detaljnu analizu trace cachea i duzine dekodiranih instrukcija i uopova, da ne smaram druge citatima uzmi lepo pa procitaj.

MadTexel je napisao(la):
Jedino se učitava vrednost i ništa više.

A sta je mov eax, [esp + 8] nego samo ucitavanje vrednosti i nista vise? :trust:

MadTexel je napisao(la):
Ti si, naravno, kompajlirao kod kao da ima 16, 32, 64 registra i onda si na osnovu toga doneo zaljučke?

Ja sam kompajlirao isti kod istim kompajlerom (ICC) sa istim optimizacijama za 32 bitni mod (8 registara) i za 64 bitni mod (16 registara) i uporedjivao performanse dobijenog programa jer je to ono sto ljude zanima, a ne da li je kompajleru lako ili tesko sa malo registara.

Pri tom sam vodio racuna da to bude kod koji nece profitirati od vece sirine reci kako mi rezultat ne bi zbog toga bio bolji u 64-bitnom modu. To testiranje sam vrsio jos kada se pojavio prvi Athlon 64 2800+ 754 i prva verzija 64-bitnog XP-a. Razlike u performansama su bile manje od 3%.

MadTexel je napisao(la):
Jel ovo thread o procesoru opšte namene...

Jeste, a posto RISC nikako nije procesor opste namene (jer bi se inace masovno koristio svugde) tu je kraj dalje diskusije.

MadTexel je napisao(la):
...jel si mislio na audio ili sliku?

Na sliku.

MadTexel je napisao(la):
Jak programer u asembleru, plus što pokazuješ da nisi programirao na takvim procesorima a pričaš kako rade.

Nikad nisam rekao da sam programirao RISC. Da me ikada zanimalo naucio bih SINTAKSU.

MadTexel je napisao(la):
c=a+b;
e=c+d:

c1 = a1 + b1;
c2 = a2 + b2;
e1 = c1 + d1;
e2 = c2 + d2;

Tako se to resava cak i kad imas samo 8 registara.

MadTexel je napisao(la):
Koja optimizacija sem blokiranja može da proizvede takva ubrzanja?Takođe, razmotavanje petlji je osnova za vektorizaciju.

Ima ih suvise da bih nabrajao ovde zaista.

MadTexel je napisao(la):
x86 ozbiljnije gledao pre oko godinu dana, ovlaš često.

Ako si gledao izlaz iz MSVC6 (pa cak i 2003) ili iz GCC3.x onda nisi nista video.

MadTexel je napisao(la):
Kada si ti zadnji put kodirao na nekom RISC procesoru? Nikad?

Ponavljas se. Vec sam rekao da nisam nikad niti me zanima da pisem deset RISC instrukcija da bih emulirao neku slozeniju instrukciju.

MadTexel je napisao(la):

Ili kompajler sličnog kvaliteta kao na drugim platformama?

Kliknite za proširenje...

Daj neki primer zivog kompajlera na tim drugim platformama, nesto sto se jos uvek razvija. Nisam u toku.

MadTexel je napisao(la):

Najjednostavnije petlje tipa DAXPY, SAXPY, DOTPROD kad se razmotaju traže dosta registara.

Kliknite za proširenje...

Kad razmotavas petlju gledas da je razmotas onoliko puta koliko je potrebno da popunis jednu liniju cachea podacima koji se obradjuju, odnosno da citas i snimas po jednu liniju cachea odjednom. Sve preko toga nema nikakvog smisla. Jedna linija na P3 je 32 bajta, na P4 je 64 bajta. To znaci 2 ili 4 XMM registra od po 16 bajtova s tim sto i P4 radi lepo i sa 32 bajta jer ima write buffere.

MadTexel je napisao(la):

nego recimo kako to radi NASA, dizajn procesora, guidove za vektorizaciju i paralelizaciju na Crayovima.

Kliknite za proširenje...

Jesu to oni sto im se ruse satlovi i ginu astronauti zbog loseg proracuna oplate?

MadTexel je napisao(la):

Znači otprilike, kad Intelov procesor zastari, onda je kompajler za njega dobar.

Kliknite za proširenje...

Zaista ne znam na osnovu cega si dosao do tog zakljucka. 9.1.022 vec podrzava i Core arhitekturu kao i sve prethodne prema tome... :smoke:

MadTexel je napisao(la):

Ne znam da li si upoznat sa pojmovima: unit stride access, non-unit stride access, scather/gather?

Kliknite za proširenje...

Naravno da jesam. Resavao sam takve probleme prepakivanjem podataka neposredno pre obrade. i dobijao lepa ubrzanja. Sto se tice scather/gather to bolje lezi GPU-ovima zbog specificne organizacije cachea i nacina pristupa memoriji. Ubrzanja u odnosu na vec uzasno optimizovan CPU kod na pomenuti nacin su od 4-8x u aplikacijama koje smo ortak i ja optimizovali.

MadTexel je napisao(la):

Borlandovi daju još gori kod, čak i bez optimizacija koje se vide iz aviona, provereno u praksi.

Kliknite za proširenje...

:d

MadTexel je napisao(la):

Ostaje mi da se zapitam zašto se VC6 i dalje koristi i podržan je od solidnog broja firmi i zašto Intel nije ranije počeo da razvija kompajlere.

Kliknite za proširenje...

Ja se to pitam svaki dan.

GMRES i BiCGSTAB. Fixed point ako može. 😀

MadTexel je napisao(la):

Ipak, GPUovi nemaju podršku za double i veliku količinu memorije. Za obradu slike ili signala, ok, za rešavanje ozbiljnijih PDEova - truba.

Kliknite za proširenje...

Double jos nema, to je istina, cak je i float problematican kad je bandwidth u pitanju cak i sa GDDR3 na 1800MHz.

MadTexel je napisao(la):

Ali niko pri zdravoj pameti neće uzeti da na GPU računa simulaciju turbine.

Kliknite za proširenje...

Ali veruj mi da ce to biti sasvim normalno za najdalje godinu dana.

Kliknite za proširenje...

ivica · 20.05.2006

Ajte ..gde su ti moderatori...Nek sav ovaj offtopic..izmedju Madtexela i Audiofreak-a prebace uposeban tread...Audiofreak vs. Madtexel

Po meni ste totalno dva sveta...CISC(audiofreak) vs. RISC(madtexel)
Sve ima svoje prednosti i mane...

Shto se tiche pada shatla Columbije...neko je bio lenj da istestira..te skupe zashtitne ploche dovoljno...Mislili su ako je toliko skupo mora da ni metak ne moze da prodje..😀 a ironije li obichana pena ga je oborila. Pa da su samo proshetali oko shatla astronauti ...primetili bi tu rupu...ovako platili su glavom.
Da se razumemo...biti astronaut je vec stavljanje glave u torbu.

Nego varatimo se mi na Conroe-a ljudi...

Ohoho...pade 12s.
Shta da se kaze...Conroe je kapetan o' belu ladju na reci Tualatin...😀

Ala sam se istripovao..kad je chovek rekao da ce da kupi 6600...chovek pomisli na 'vidia-u...😀...Ali...E....Core 2 Due je to bre..😀

Lepo je videti...QPB od preko 1500MHz...tj. od 1600MHz..odnosno FSB od 400Mhz..ej 400Mhz interno..a i miltiplikator ispod 10...😀

Ne zna se shta vishe donosi ovaj skor...taj FSB ili kesh ili arhitektura....? Mozda sve zajedno.

ivica · 20.05.2006

genuine je napisao(la):
Zar ne postoje procesori u GaAs na 10GHz i jace... GaAs je uvek isao na 4 puta vecoj frekvenciji od Si .... jedino sto ne moze toliki stepen integracije problema zbog odvodjenja toplote?

Isli su oni na stotine GHz...neka keramika je u pitanju..i naravno superprovodni efekti...Josh uvek daleko od desktop primene.

genuine · 21.05.2006

moguce..
e sad conroe .. sta je promenjeno u arhitekturi u odnosu na pentium 4 i koliko to moze da koristi?

audiofreak · 21.05.2006

@genuine:
Vec se pisalo o tome, procitaj ceo thread. Za tebe i mene asm programere imace nove SSE4 ekstenzije 😀

Conroe in action!!!

Slavan

Čuven

Banned

Čuven

Čuven

Banned

Čuven

Čuven

Banned

Slavan

Slavan

Banned

- Bike Camper -

Banned

Slavan

- Bike Camper -

Slavan

Čuven

Čuven

Rambo Amadeus

Maki

Guest

Banned

Banned

Banned

Čuven

Banned

Čuven

Čuven

Slavan

Banned