Šta je novo?

Conroe izgleda jede FX za dorucak?

mcekovic je napisao(la):
...
Nadam se da hoce, ali u par interview-a koje sam procitao sa AMD zvanicnicima uvek se to kategoricki demantovalo, po pricipu HT = bljak-fuj...

@"AMD zvanicnici" :)

Ako 2.8HT u MAXu renda ko 3.36 bez HT dakle obican "normalan" procesor na sta se to onda oni gade????
Pa sigurno nece BSplayer ili WinAMP da imaju podrsku za HT, zna se zasta je to....bre. I tih 20% dobitka nisu prazna prica, to stvarno postoji.
 
audiofreak je napisao(la):
Kako si dosao do ovog citata?!? Lepo je Uros rekao da ce se postojece 128-bitne SSE instrukcije (dakle sve vektorske odnosno one koje rade na 4x 32 bita) izvrsavati za 1T umesto za 2T kao do sada.
Nisam siguran da ce ovo da dovede do drasticnog povecanja PROSECNOG IPC-a PROSECNE aplikacije ;). Dakle prosecna aplikacja je word, excel, browser, mail-client, pa i igrice. Pod 'procesnim' aplikacijama ne smatram PhotoShop, AutoCad, video-encoding itd.

audiofreak je napisao(la):
Kad bi jos samo pojedini ljudi shvatili koliko je NetBurst bio znacajan za razvoj i procesorske arhitekture i softvera i to ne samo Intelu...
To je isto kao kad bi rekao: 'Kad bi jos samo pojedini ljudi shvatili koliko su Komunizam i Socijalizam bili znacajani za razvoj i ljudskog drustva i civilizacije, i to ne samo SSSR-u...' :D :D :D Ipak, ne sporim da jeste doprineo, ali da su tada recimo napravili Conroe-a umesto NetBurst, mnogo bi vise doprineli!


audiofreak je napisao(la):
Nece biti da je skroz isto, HT je malo *******iji jer se ne mogu koristiti isti resursi u isto vreme -- npr. ne mozes u oba threada da koristis FPU jer jednostavno nemas dva.

Pa o tome i pricam, potrebna su 2 :).

audiofreak je napisao(la):
Aman covece, shvati vec jednom da IPC ne zavisi samo od duzine pajplajna!!! Zavisi direktno od mixa instrukcija koje izvrsavas i od toga koliko je jezgro "naklonjeno" kojoj vrsti instrukcija. NetBurst je bio "stimovan" za SIMD i streaming, a doziveo je nepravdu da se na njemu izvrsava legacy DJUBRE od koda! Kako ne mozes da shvatis tako prostu cinjenicu?!?

'Aman covece', SIMD i streaming NISU PROSECAN mix instrukcija, vec jako specifican!
 
Poslednja izmena:
okmijun je napisao(la):
Ako 2.8HT u MAXu renda ko 3.36 bez HT dakle obican "normalan" procesor na sta se to onda oni gade????
Pa sigurno nece BSplayer ili WinAMP da imaju podrsku za HT, zna se zasta je to....bre. I tih 20% dobitka nisu prazna prica, to stvarno postoji.

Da, ali 20% je malo, potrebno je bar 50% da opravda ulaganje u razvoj, koji je komplikovan.
 
mcekovic je napisao(la):
Optimizuja za HT je ista kao i za multi-core, tj. pisanje multi-threaded software-a.

Naravno da nije ista.

Da li ce HT dobro raditi ili ne, zavisi u velikoj meri od kesa i nacina na koji mu se pristupa/koristi, sto opet zavisi od optimizacije koda. Na kraju krajeva, HT koristi zajednicke resurse jednog jezgra (ukljucujuci i kes), sto se ne moze reci i za DC resenja.

Jedan primer> ako vise thread-ova, za svoje potrebe prebaci iz RAM-a u kes neke podatke, pozeljno je da prvi thread "pogodi" pravu lokaciju u memoriji, u smislu da dovuce u kes ono sto ce drugom ili trecem threadu zatrebati u nekoj kasnijoj fazi obrade.

Pazi, pricam samo o read zahtevima. Write zahteva jos komplikovanije procedure, zbog problema sa sinhronizacijom.
 
Poslednja izmena:
drfedja je napisao(la):
Uostalom, mozes da vidis test Intel Yonah procesora, sa 2MB shareovanog kesa, peformanse su na nivou X2 3800+

Definitivno, ali na FSB-u 166 i sa šugavom memorijom.. Već na FSB 233 razlika je preko 10% u 3D marku u odnosu na isto klokovani FX60. Sačekaj još 10ak dana da do ovih silnih overklokera stignu AOpen/ECS i975 desktop ploče pa ćeš videti šta će se desiti :D. Conroe je tek druga priča, ali da ne lupamo svi ovde, kad stigne, stigao je, pa ćemo da vidimo šta u tom trenutku nudi AMD, koliko je brži/sporiji i koje su optimalne varijante za naše pare..
 
Poslednja izmena:
genijalcin@23 je napisao(la):
Naravno da nije ista.

Da li ce HT dobro raditi ili ne, zavisi u velikoj meri od kesa i nacina na koji mu se pristupa/koristi, sto opet zavisi od optimizacije koda. Na kraju krajeva, HT koristi zajednicke resurse jednog jezgra (ukljucujuci i kes)...
OK, ali ako imas shared-cache (a svi teze ka tome) onda ovaj argument pada u vodu.
 
Snejk je napisao(la):
Definitivno, ali na FSB-u 166 i sa šugavom memorijom.. Već na FSB 233 razlika je preko 10% u 3D marku u odnosu na isto klokovani FX60. Sačekaj još 10ak dana da do ovih silnih overklokera stignu AOpen/ECS i975 desktop ploče pa ćeš videti šta će se desiti :D. Conroe je tek druga priča, ali da ne lupamo svi ovde, kad stigne, stigao je, pa ćemo da vidimo šta u tom trenutku nudi AMD, koliko je brži/sporiji i koje su optimalne varijante za naše pare..

Pokazalo se da je FSB kod Intelovih procesora faktor koji najvise utice na performanse.

Zato je tu sada shared kes, koji bi trebalo da malo popravi situaciju, barem dok se ne pojavi CSI, a zatim i integrisani memorijski kontroler.
 
genijalcin@23 je napisao(la):
Pokazalo se da je FSB kod Intelovih procesora faktor koji najvise utice na performanse.

Zato je tu sada shared kes, koji bi trebalo da malo popravi situaciju, barem dok se ne pojavi CSI, a zatim i integrisani memorijski kontroler.
Pa, FSB zaista utice na performanse kod Netburst procesora. Koliko ce da utice na performanse modifikovane P6 marhitekture zaista ne bih mogao da tvrdim.
 
Snejk je napisao(la):
Definitivno, ali na FSB-u 166 i sa šugavom memorijom.. Već na FSB 233 razlika je preko 10% u 3D marku u odnosu na isto klokovani FX60. Sačekaj još 10ak dana da do ovih silnih overklokera stignu AOpen/ECS i975 desktop ploče pa ćeš videti šta će se desiti :D. Conroe je tek druga priča, ali da ne lupamo svi ovde, kad stigne, stigao je, pa ćemo da vidimo šta u tom trenutku nudi AMD, koliko je brži/sporiji i koje su optimalne varijante za naše pare..
Zar mislis da ce 975 doneti neko drasticno ubrzanje, realno gledano vece nego sto donosi AM2 na AMD64 procesorima?
mcekovic je napisao(la):
OK, ali ako imas shared-cache (a svi teze ka tome) onda ovaj argument pada u vodu.
Ipak svako jezgro ima svoj L1 cache.
 
Poslednja izmena:
mcekovic je napisao(la):
OK, ali ako imas shared-cache (a svi teze ka tome) onda ovaj argument pada u vodu.

Ajde da zanemarimo na trenutak pricu oko cache-a, koja je jako bitna. Znaci dva jezgra i dva logicka procesora (i jedan cache :S: ). Ali ostavimo to sa strane, i ostavimo sa strane probleme "tehnicke" prirode, poput CPU Affinity. Evo, AF spomenu FPU.

A sto se tice 975...Pa recimo da vec sada Presleri imaju prilican boost u odnosu na 955x...Kako ce se ponasati sa Conroe-om, ostaje da se vidi.
 
Poslednja izmena:
audiofreak je napisao(la):
Evo primera kako su ovde neki "nepristrasni" navijaci u dve recenice iz istog pasusa:

#1:


#2:


Po ovome bi covek mogao da zakljuci da je bolje biti 3-5% brzi od samog sebe nego 20% brzi od onog ko je to bio do sada.

Mislim, sta reci... :trust:
Nisi me dobro skapirao. Sasvim je izvesno da ce AM2 biti brzi 3-5% u odnosu na S939, ali je sasvim neizvesno na osnovu onih fake benchmarka zakljuciti da ce biti konkurent brzi 20%.
audiofreak je napisao(la):
"Samo" je u ovom slucaju godinu dana ranije :D
Sta je tu cudno, pri prelasku na 0.13 mikronski proces situacija je bila jos gora . :D
 
mcekovic je napisao(la):
Slazem se.

OK, ali teorijski limit ipak postoji, zbog zavisnosti instrukcija po podacima:
1. A = B + C;
2. B = A + D;
Druga instrukcija ne moze da se izvrsi dok se ne zavrsi prva.
I AMD i Intel su jako blizu tog limita. Ne verujem da je povecanje prosecnog x86 IPC-a po core-u od 20-30% u odnosu na sadasnje stanje teorijski moguce ikada.
Moguce je poboljsati pristup memoriji, rad sa cache-om, smanjiti branch misspredict. Prosirivanjem execution core-a nije moguce povecati IPC u legacy x86 kodu. Integer execution je poboljsan najpre zbog niske latence L1 i L2 kesha, zbog uOps fusion-a i kojekakvih tweakova.
mcekovic je napisao(la):
Nadam se da hoce, ali u par interview-a koje sam procitao sa AMD zvanicnicima uvek se to kategoricki demantovalo, po pricipu HT = bljak-fuj.
Takodje, verujem da je razvoj SMT implementacije jako komplikovan i skup. Logicka kompleksnost procesora se dosta povecava, vise thread-ova se 'bori' za resurse jednog core-a, treba to sinhronizovati, puno prilika za bug-ove u procesoru. Multi-core pristup je logicki jednostavniji i jeftiniji za razvoj (ne i za proizvodnju, jer se neki resursi koji bi se mogli podeliti sigurno dupliraju).
Pa Intel tvrdi da je za implementaciju Hyperthreadinga potroseno relativno malo tranzistora.

mcekovic je napisao(la):
Shared-cache donosi ubrzanje i u multi-threaded aplikacijama, jer smanjuje potrebu za inter-core komunikacijom. Izgleda da Intel dobrim cache-om anulira i prestize AMD-ove glavne prednosti: integrisani memorijski kontroler i hyper-transport ('jednim udarcem ubija 2 muve'!).
Shared cache je jedno a memorijski kontroler je drugo. Prednost share-ovanog kesha sigurno postoji, a kolika je inter-core komunikacija, zavisi od vrste threadovanog softvera i od CPU affinity-ja. U oba slucaja intercore komunikacija je brza, na brzini procesora, samo je pitanje da li je dovoljno brza. Primera radi, Yonah nema shareovan L1, ali ima shareovan L2. Kod X2 se sva kesh koherencija obavlja preko crossbara. Definitvno, prednost shareovanog kesha je najvise vidljiv u ne-threadovanom softveru.
mcekovic je napisao(la):
AMD se okrenuo unapredjenjima eksterne komunikacije procesora (to je jednostavnije za razvoj!), dok i u AM2 kuca isti core kao i u prvom Athlon-u. Vreme je da malo porade i na tome.
Pa po toj logici isti core kuca i u Pentium M procesorima kao i u prvom Pentium Pro procesoru iz 1994. godine.
 
Poslednja izmena:
mcekovic je napisao(la):
da su tada recimo napravili Conroe-a umesto NetBurst, mnogo bi vise doprineli!

Kamo lepe srece, da je tako bilo odavno ne bih morao da trpim ovolike AMD-ovce koji drobe o AMD-ovoj "naprednijoj" arhitekturi koja uzgred brze izvrsava samo zastareli software.
Alo covece, da nije bilo NetBurst-a, ne bi bilo ni Conroe-a! Conroe ne bi imao takav cache ni memory disambiguation (aka replay), ni SSE2, ni sve ostalo dobro sto su odatle povukli. Takodje ne bi napredovali ni softverski algoritmi niti bi se mnogo sta desilo na polju optimizacije.

mcekovic je napisao(la):
'Aman covece', SIMD i streaming NISU PROSECAN mix instrukcija, vec jako specifican!

Pa gde sam ja rekao da jesu prosecan?!? Kazem da su trebali da budu vecinski deo miksa odavno, a tek danas bi se moglo reci da se koriste posle punih 6 godina.

Ponavljam ti jos jednom (i jos milion puta ako treba dok ne ukapiras!) da nema smisla suditi o NetBurst IPC samo na osnovu toga kako izvrsava 386/387 kod -- AMA BAS NIKAKVOG SMISLA!

drfedja je napisao(la):
Nisi me dobro skapirao. Sasvim je izvesno da ce AM2 biti brzi 3-5% u odnosu na S939, ali je sasvim neizvesno na osnovu onih fake benchmarka zakljuciti da ce biti konkurent brzi 20%.

I dalje te ne razumem -- ko to procenjuje da li su AM2 bench-evi real i da li su Conroe fake?!? Ili da jos pojasnim -- u Intel sumnjas i kazes fake pa otpisujes 20%, a u AMD ne sumnjas i kazes "sasvim je izvesno" (real, mada ne shvatam na osnovu cega?) i odusevljavas se sa mogucih 3-5%.

Pa zar nije to AM2 ubrzanje izmereno isto nekom sintetikom?!? I sad to je validno, a ovo drugo nije? Fanboyism at its best.
 
Poslednja izmena:
Audio jel mozes molim te malo da pojasnis i izkomentarises ovo pisanje francuza:

http://www.behardware.com/news/imprimer/8025/

Narocito ovu tvrdnju na kraju:

"We have to point out that during Intel's presentation at IDF, it was even less clear. Some Medias understood that all SSE instructions would be processed in one cycle. It is of course strictly impossible because for example the DIVPD (Packed Double-Precision Floating-Point Divide) instruction requires no less than 62 cycles for the Pentium M and 70 cycles for the Pentium 4!"
 
audiofreak je napisao(la):
Kamo lepe srece, da je tako bilo odavno ne bih morao da trpim ovolike AMD-ovce koji drobe o AMD-ovoj "naprednijoj" arhitekturi koja uzgred brze izvrsava samo zastareli software.
Alo covece, da nije bilo NetBurst-a, ne bi bilo ni Conroe-a! Conroe ne bi imao takav cache ni memory disambiguation (aka replay), ni SSE2, ni sve ostalo dobro sto su odatle povukli.

To se sove 'tesenje'. Ne mora uvek da se dese lose stvari da bi se desile dobre, mogu dobre da se dese i bez losih. Zasto da ne bi napravili sve to i na arhitekturi sa normalnim pipeline-om?


audiofreak je napisao(la):
Takodje ne bi napredovali ni softverski algoritmi niti bi se mnogo sta desilo na polju optimizacije.
Zaista ne znam kakve veze imaju software-ski algoritmi sa sakatim NetBurst-om :). A sto se tice napretka na polju optimizacije: sta ce nam specificna optimizacija za NetBurst kad postoji CPU koji moze sasvim fino i brzo da radi i bez nje? (A64, Conroe?) :)

audiofreak je napisao(la):
Pa gde sam ja rekao da jesu prosecan?!? Kazem da su trebali da budu vecinski deo miksa odavno, a tek danas bi se moglo reci da se koriste posle punih 6 godina.

A koliki je dobitak od koriscenja SSE/2/3 instrukcija u aplikacijama koje nisu obrada slike, rendering, video encoding itd. ?
 
Poslednja izmena:
ne programiram za x86 ali koliko kontam ne radi se o tome da se SSE instrukcije izvrsavaju u jednom ciklusu (buduci da su prilicno kompleksne pravo cudo bi bilo da se izvrse u jednom ciklusu). naime NetBurst je mogao da izvrsi jednu micro-ops SSE instrukcijije svaki drugi ciklus a Conroe moze svaki ciklus da izvrsi jednu micro-ops SSE instrukcije. e sad koliko je potrebno micro-ops da se izvrsi koja SSE instrukcija predpostavljam da pise u nekom manuel-u... :)
 
drfedja je napisao(la):
Zar mislis da ce 975 doneti neko drasticno ubrzanje, realno gledano vece nego sto donosi AM2 na AMD64 procesorima?

Ipak svako jezgro ima svoj L1 cache.

Ma batali tih par procenata zbog razlike i945>i975, poenta je onome što Yonah pokazuje na 3GHz, vazdušnom hlađenju i visokom FSB-u :D. Laptop upotreba je nešto drugo. :)
 
Nedjo je napisao(la):
Audio jel mozes molim te malo da pojasnis i izkomentarises ovo pisanje francuza:

Naravno, imas dva termina -- latency i throughput.

Latency je koliko je potrebno da se cela instrukcija zavrsi i da njen rezultat promeni arhitekturalno stanje.

Throughput je broj taktova nakon kog execution unit moze da primi sledecu instrukciju istog tipa.

Naravno da se ne moze izvrsiti 128-bitna SSE instrukcija za 1T. To ne moze cak ni AMD, ali ce zato biti moguce zapoceti izvrsavanje sledece 128-bitne SSE instrukcije vec u sledecem taktu. Ako se generise dobar kod moguce je da se vremena izvrsavanja instrukcija (latency) lepo preklope i da se dobije veliko ubrzanje. Naravno u legacy kodu koji ne koristi SSE ovo nece znaciti ama bas nista.

DIVPD inace ima i latency i throughput 70 taktova na P4 sto znaci da moze da se zapocne jedno (dva puta double precision) deljenje tek svakih 70 taktova. Za to vreme treba smisliti neki drugi posao za druge unite jer je FP_DIV zauzet, i "tesne" petlje (koje imaju malo instrukcija) sa deljenjem nemaju smisla jer njegova latencija nema cime da se sakrije. Zato se najcesce radi mnozenje sa reciprocnom vrednoscu koje traje 10x krace (7 taktova latencija i 2 takta throughput) umesto brute force pristupa.

EDIT:
Ovo bi moglo da znaci nesto drugo -- da Conroe ima 128-bitni data bus interno umesto dosadasnjeg 64-bitnog. Ne vidim kako bi drugacije bilo moguce da se svede vreme izmedju dve 128-bitne instrukcije na 1T.

mcekovic je napisao(la):
Zasto da ne bi napravili sve to i na arhitekturi sa normalnim pipeline-om?

Evo ti par odgovora pa izaberi:

-Zato sto 2000-te godine nije bilo proizvodnog procesa koji bi im omogucio da ta arhitektura sa 14 stage pipelineom radi na 3GHz.

-Zato sto su zeleli da probaju nesto drugacije i da nauce nesto novo pride stimulisuci ljude da rade istrazivanje na temu optimizacije, merenja performansi, profiliranja, validacije kompleksnog dizajna, itd.

-Zato sto AMD danas ne bi postojao da su uspeli :-devil-:

mcekovic je napisao(la):
A sto se tice napretka na polju optimizacije: sta ce nam specificna optimizacija za NetBurst kad postoji CPU koji moze sasvim fino i brzo da radi i bez nje? (A64, Conroe?)

Probaj da poteras na primer stari fraunhofer mp3 encoder (dos komanda) na tim procesorima pa mi reci da li je bolje to ili recimo gogo encoder? Kolika je razlika u brzini enkodiranja?

Uzmi SuperPI i PiFast43 i uradi 32M decimala u oba (u PiFast izaberi Chudnovsky algoritam) pa mi reci kojim od ta dva programa bi voleo da racunas PI na 32M decimala kad bi ti to bio svakodnevni posao?

Pritom ni jedan od ovih programa nije optimizovan specificno za NetBurst. Zaista se nadam da ti ne treba vise primera zasto je tvoj stav o izlisnosti optimizacije softvera potpuno pogresan. Ako treba jos samo reci, imam ih mali milion ali najpre postuj rezultate ova dva test zadatka koja sam ti zadao.

mcekovic je napisao(la):
A koliki je dobitak od koriscenja SSE/2/3 instrukcija u aplikacijama koje nisu obrada slike, rendering, video encoding itd. ?

Dobitak kod NetBursta postoji i od skalarnih varijanti SSE/2/3 instrukcija zbog toga sto se ne izvrsava obican integerski i FPU kod jer kao sto rekoh procesor daleko efikasnije izvrsava SSE/2/3 kod jer je za to PRAVLJEN.
 
Poslednja izmena:
AMD-ovo K8 jezgro je prilično istweak-ovano, upravo zbog toga AMD-u ne polazi za rukom da ga dodatno ubrza bez veće (i skupe) revizije. Ipak, Athlon 64 X2 za novo ležište bi ipak morao biti brži, ovo je zaista razočaranje. Realno bi bilo očekivati da bi Conroe mogao biti nešto brži, ali teško da ćemo videti kule i gradove, osim u Intelovom PR materijalu. Naravno, voleo bih da ne bude tako.
Ono što je Intel konačno uspeo sa Conroe-om je da ima dvojezgarni procesor koji nije sklepan, već je namenski napravljen. Štaviše, Intel ima prostora i za buduća ubrzanja, putem CSI magistrale pre svega koja će sprečiti da se jezgra otimaju o memorijski protok. Takođe, i Intel će svojim procesorima kasnije pridodati integrisani memorijski kontroler, a pre će preći i na četvorojezgarne procesore od AMD-a.

Tek će dalje umnožavanje procesorskih izvršnih jezgara uz odgovarajuću softversku podršku doneti bar delimično onako brz rast performansi na kakav su nas Intel i AMD navikli ranije. Conroe je definitivno Intelov korak u pravom smeru, ali je tek prvi i osnovni korak koji polako nagoveštava oblik stvari koje će doći.
 
morbius je napisao(la):
AMD-ovo K8 jezgro je prilično istweak-ovano, upravo zbog toga AMD-u ne polazi za rukom da ga dodatno ubrza bez veće (i skupe) revizije. Ipak, Athlon 64 X2 za novo ležište bi ipak morao biti brži, ovo je zaista razočaranje. Realno bi bilo očekivati da bi Conroe mogao biti nešto brži, ali teško da ćemo videti kule i gradove, osim u Intelovom PR materijalu. Naravno, voleo bih da ne bude tako.
Ono što je Intel konačno uspeo sa Conroe-om je da ima dvojezgarni procesor koji nije sklepan, već je namenski napravljen. Štaviše, Intel ima prostora i za buduća ubrzanja, putem CSI magistrale pre svega koja će sprečiti da se jezgra otimaju o memorijski protok. Takođe, i Intel će svojim procesorima kasnije pridodati integrisani memorijski kontroler, a pre će preći i na četvorojezgarne procesore od AMD-a.

Tek će dalje umnožavanje procesorskih izvršnih jezgara uz odgovarajuću softversku podršku doneti bar delimično onako brz rast performansi na kakav su nas Intel i AMD navikli ranije. Conroe je definitivno Intelov korak u pravom smeru, ali je tek prvi i osnovni korak koji polako nagoveštava oblik stvari koje će doći.

Prvi put da se u potpunosti slazem sa tobom.
 
morbius je napisao(la):
AMD-ovo K8 jezgro je prilično istweak-ovano, upravo zbog toga AMD-u ne polazi za rukom da ga dodatno ubrza bez veće (i skupe) revizije.
Ono sto bi AMD mogao da istweakuje na K8 jezgrima je cache arhitektura. Iskreno mislim da vise nema narocite potrebe za exclusive cache arhitekturom, kada su proizvodni procesi tako sitni. Vise ima stete nego koristi. K8 jezgro samo po sebi sigurno nije anemicno niti pati od nedostatka izvrsnih resursa.
morbius je napisao(la):
Ipak, Athlon 64 X2 za novo ležište bi ipak morao biti brži, ovo je zaista razočaranje. Realno bi bilo očekivati da bi Conroe mogao biti nešto brži, ali teško da ćemo videti kule i gradove, osim u Intelovom PR materijalu. Naravno, voleo bih da ne bude tako.
Intel je uvek manje ili vise obecavao kule i gradove sa svojim novim ili "novim" arhitekturama, pa je na kraju ispadalo da to i nije bas toliko mocno kao sto su pricali. Samo kad se setim pompeznih najava Netburst arhitekture, sa gomilom bombasticnih marketingskih naziva.
Voleo bih da zaista naprave mocan procesor, ali isto tako bih voleo i da konkurencija ne spava na lovorikama, a mislim da nece spavati, jer ako "zeleni" budu spavali, dobijacemo nove procesore po nenormalnim cenama i performanse na kasicicu.
morbius je napisao(la):
Ono što je Intel konačno uspeo sa Conroe-om je da ima dvojezgarni procesor koji nije sklepan, već je namenski napravljen. Štaviše, Intel ima prostora i za buduća ubrzanja, putem CSI magistrale pre svega koja će sprečiti da se jezgra otimaju o memorijski protok. Takođe, i Intel će svojim procesorima kasnije pridodati integrisani memorijski kontroler, a pre će preći i na četvorojezgarne procesore od AMD-a.
Intel je to vec uradio sa Yonah-om - da napravi namenski dvojezgarni CPU sa vrlo naprednim power managemantom.
Ne zaboravi da sa sadasnjom arhitekturom i novim proizvodnim procesom, AMD dosta lako moze da dodaje nova jezgra na CPU. Interna komunikacija izmedju jezgara je vrlo slicno resena kao HT linkovi kod Opterona 2xx i 8xx.
 
drfedja je napisao(la):
Ne zaboravi da sa sadasnjom arhitekturom i novim proizvodnim procesom, AMD dosta lako moze da dodaje nova jezgra na CPU. Interna komunikacija izmedju jezgara je vrlo slicno resena kao HT linkovi kod Opterona 2xx i 8xx.

Ja se ne bih slozio sa tim. Tehnicki moze lako da doda. Ali sudeci po AM2, vec 4800 x2 ne ume da iskoristi veci bandwidth DDR2 memorije, sta bi tek bilo sa 4 jezgra? Ili to ili AMD namerno nece da poboljsava performanse da ne bi ugrozio Opteron.
 
Kako mozes da sudis o AM2 koji se nije ni pojavio jos? Kao sto ja ne mogu da kazem koliko je zaista Conroe brz, osim sto mogu da lupam, nagadjam i naslucujem, tako ne mozes ni ti da kazes da li ce novi X2 procesori raditi kako treba sa DDR2 memorijom. Na osnovu simulacije DDR2 memorije na S939 platformi, u odnosu na DDR memoriju na 400Mhz ubrzanja bas i nisu tako mala.
Ako novi CPU ima samo 6100 MB/s realnog protoka, sa DDR2 800 memorijom, onda su zaista *****ali stvar i napravili losh memorijski kontroler, u sta sumnjam. Pre sumnjam u nezreli BIOS na doticnoj ploci gde su merene performanse memorije.
 
Poslednja izmena:
drfedja je napisao(la):
Kako mozes da sudis o AM2 koji se nije ni pojavio jos? Kao sto ja ne mogu da kazem koliko je zaista Conroe brz, osim sto mogu da lupam, nagadjam i naslucujem, tako ne mozes ni ti da kazes da li ce novi X2 procesori raditi kako treba sa DDR2 memorijom. Na osnovu simulacije DDR2 memorije na S939 platformi, u odnosu na DDR memoriju na 400Mhz ubrzanja bas i nisu tako mala.
Ako novi CPU ima samo 6100 MB/s realnog protoka, sa DDR2 800 memorijom, onda su zaista *****ali stvar i napravili losh memorijski kontroler, u sta sumnjam. Pre sumnjam u nezreli BIOS na doticnoj ploci gde su merene performanse memorije.

Pa ne mogu da sudim, lepo sam rekao "sudeci po..." misleci pritom na ono sto se o tome trenutno zna, a to je onaj test koji smo videli. Uzgred, mnogo vise sample-ova AM2 je vidjeno i testirano nego Conroe.

Meni se licno cini da AMD-u DDR2 ne lezi iz nekog razloga. Ili je to za 1GHz manji takt procesora, ili je crossbar, ili je mozda cak cache usko grlo (vrlo verovatno s obzirom na bedan cache rezultat u Sandri) ili nesto peto ali nesto tu ne stima.

Da je BIOS to iskreno sumnjam jer tajminzi najvise sto sam video da uticu je do 1.5%, a Sandra mnogo vise voli AMD nego Intela kad je mem. bandwidth u pitanju, evo Lukija ima veci bandwidth od mene sa Venice i DDR.
 
Poslednja izmena:
Mozda je stvarno moguce da ovi Eng sampleovi AM2-ke sto se testiraju imaju bagovit Mem. ctrl, te da ce finalna verzija umeti adekvatno da iskoriti BW DDR2-ke!?
 
audiofreak je napisao(la):
Pa ne mogu da sudim, lepo sam rekao "sudeci po..." misleci pritom na ono sto se o tome trenutno zna, a to je onaj test koji smo videli. Uzgred, mnogo vise sample-ova AM2 je vidjeno i testirano nego Conroe.
Jeste vidjeno, ali je testirano u ko zna kojim uslovima, sa ko zna kojom komandnom latencom i ko zna kakvim TREF parametrom, koji moze da "ubije" bandwidth i za par giga u sekundi. Znam o cemu pricam. Ranije verzije mem. kontrolera za A64 su mogle da se zaglupe, pa da imaju nenormalno nizak bandwitdh kada se ne podesi TREF kako treba.
audiofreak je napisao(la):
Meni se licno cini da AMD-u DDR2 ne lezi iz nekog razloga. Ili je to za 1GHz manji takt procesora, ili je crossbar, ili je mozda cak cache usko grlo (vrlo verovatno s obzirom na bedan cache rezultat u Sandri) ili nesto peto ali nesto tu ne stima.
Kao sto rekoh malo pre, nema razloga da nesto ne stima osim nedovrsenog BIOS-a i mem. kontrolera. Po cemu je DDR-I na CL3 4 - 4 - 8 sporiji od DDR2 na CL3 4-4-12 ? Nema razloga.

audiofreak je napisao(la):
Da je BIOS to iskreno sumnjam jer tajminzi najvise sto sam video da uticu je do 1.5%, a Sandra mnogo vise voli AMD nego Intela kad je mem. bandwidth u pitanju, evo Lukija ima veci bandwidth od mene sa Venice i DDR.
Sandra vise voli AMD ? :d
Pa i Science Mark ima veci bandwith na AMD-u. Sve je to zbog integisanog memorijskog kontrolera. FSB-om na 800mhz si ogranicen na komunikaciju od 6.4 GB/s i tvoj P4 komunicira sa northbridgeom tom brzinom i ne moze da da veci rezultat ni u jednom memorijskom testu nego sto je ta teorijska brzina protoka, pa makar mu nabudzio i dual DDR2 800. Zapravo kod Intela DDR2 ne donosi nikakvo znacajno ubrzanje u odnosu na Intel 875 sa DDR1 memorijom.
Tek kasnije kada su se pojavile varijante P4 procesora na 1066 Mhz FSB-u taj limit je malo pomeren na gore, pa je sada teorijski protok na FSB1066 mhz 8.5gb/s u odnosu na 6.4 gb/s kod AMD-a sa S939 podnozijem i dual DDR400 memarom. Ali kada na AMD nabudzis DDR600 memaru onda je teorijski protok 9.6 GB/s. Isto vazi i za DDR2, jer nema ogranicenja u vidu FSB-a.

AM2 CPU na 2.8 Ghz imace za DDR667 delilac 1/9, dakle memara ce raditi na 312mhz sto je ispod DDR2 667 specifikacije, osim ako ne nabudze polovicne delioce.
Evo juce do kasno sam se igrao sa Geil One memorijom sa TCCD chipovima i Venice 3000+ @2.8 Ghz. Dobici u odnosu na DDR400 na CL2.5 3-3-6 su znacajni i krecu se od 2 do 20 % ! Naravno, 0% se dobija na softveru kojem veoma malo znaci brzina komunikacije sa memorijom.
Primera radi Half Life 2 Canals demo na 2.8 Ghz na 200 Mhz ide 115 FPS, dok na 312 Mhz sa relativno labavim tajminzima ide 136 FPS. CSS2 ide 180 FPS na 200Mhz, a cak 205 FPS na 312 Mhz.
3D Mark01 Soft TnL daje 11700 markova na 200 Mhz a na 312 daje 12800 !
3D Mark03 koji je GPU zahtevan daje oko 300 poena vise na 312 Mhz, a CPU skor je sa 1230 povecan na 1425 poena.
U everestu Latency je 47 ciklusa sa DDR400, a sa DDR624 je 35.6 ciklusa !
U Sandri je mem bandwith oko 7700 MB/s, sa DDR400 je oko 5950 MB/s .
Winrar radi na DDR400 590 KB/s, dok na 624 mhz radi 710 kb/s.

Ne verujem da ce na zreloj AM2 ploci biti nesto manji rezultat, narocito ako su memorijski kontroler "trimovali" za vise latence koje ima DDR2.

Dakle, sadasnjim AM2 plocama ili mem. kontrolerima ili nesto debelo fali ili je DDR2 memorija bulja.
 
drfedja je napisao(la):
Jeste vidjeno, ali je testirano u ko zna kojim uslovima, sa ko zna kojom komandnom latencom i ko zna kakvim TREF parametrom, koji moze da "ubije" bandwidth i za par giga u sekundi.

Pa sam si rekao u nekom od postova da tajminzi malo uticu na bandwidth, odluci se vec jednom!

#1
#2
#3
#4

drfedja je napisao(la):
Sandra vise voli AMD ? :d

Da, ali ono sto sam hteo da kazem je da meni Everest daje vece rezultate od Sandre i da je taj rezultat koji je objavljen za AM2 los ako ja mogu da ga postignem sa sporijom memorijom.
 
audiofreak je napisao(la):
Pa sam si rekao u nekom od postova da tajminzi malo uticu na bandwidth, odluci se vec jednom!
Ono o cemu sam pricao nema veze sa standardnim CL TRAS TRCD TRP parametrima. Imao sam nekoliko primera na starijim Socket754 masinama da pri promeni TREF parametra memory bandwith padne za nekoliko GB/s.
Sa sadasnjim revizijama procesora i ploca, to nije slucaj.

audiofreak je napisao(la):
Ne znam sta si hteo sa ovim linkovima da mi pokazes... Nesto sto nisam znao ?
Ok, memorijski tajminzi uticu na performanse, to stoji. Ali velika brzina RAM-a potire labave tajminge. Takodje, sa visim taktom procesora raste "glad" za memorijskim protokom i to je fakat. Prema tome, na 2.2 ghz, nema mnogo smisla budziti dual DDR2 800, dok na 3.0 ghz dual core CPU masini vec ima mnogo vise smisla.
audiofreak je napisao(la):
Da, ali ono sto sam hteo da kazem je da meni Everest daje vece rezultate od Sandre i da je taj rezultat koji je objavljen za AM2 los ako ja mogu da ga postignem sa sporijom memorijom.
To su potpuno dva razlicita test programa. To je kao da si rekao, meni Quake 4 radi brze od HL2 :d


Sandra koristi WSTREAM algoritam i jos kojekakve optimizacije. Everest koliko vidim, meri memory read i write. Pitanje je samo kako ce P4 taj bandwidth da "provuce" kroz FSB i memoriju.
 
Poslednja izmena:
audiofreak je napisao(la):
Da, ali ono sto sam hteo da kazem je da meni Everest daje vece rezultate od Sandre i da je taj rezultat koji je objavljen za AM2 los ako ja mogu da ga postignem sa sporijom memorijom.

I meni Everst daje vece rezultate, cca +100 MB/s:

Sandra: 7080 MB/s
Everest: 7188 MB/s
 
Nazad
Vrh Dno