AMD Piledriver a.k.a. Vishera, official thread

[hexenbiest]

Pa to se zna već dugo vremena. x86 i njegove 64-bitne reinkarnacije su long-term kaput.

Nema više spoektakularnih ubrzanja i nema više rešavanja svakog problema "carpet-bombingom" u stilu "ako ti se nešto ne dopada, baci na to šleper tranzistora pa će da radi".

Naravno da nema, zato što je povećanje IPC-a za 20% u odnosu na K10 jezgro potrebno 100% više tranzistora u tom istom jezgru. Tu se javlja problem optimizacije, istraživanja i razvoja itd... za šta treba mnogo love. Zbog toga je AMD išao na veći broj jezgara, koje bi kasnije unapredio i dogurao do nivoa sadašnjih Phenom II K10 jezgara uz po koju optimizaciju. Dakle, poenta priče je bila izbegavanje FAT core-ova.

Bulldozer je AMDov korak povlačenja i regrupisanja. Napravili su platformu koja možda i nema top-class IPC ( ali nije daleko ) ali je zato vrlo štedljiva u pogledu toga šta postiže za svaki J energije, a može da radi na vrlo visokim frekvencijama.

Za prvo se slažem (low IPC), ali za drugo (disipacija energije) smatram da nisi u pravu, a ovo treće je razlog zašto je IPC nizak. BD ne bi bio loš da mu TDP nije toliko visok, a najveći problemi se javljaju kada hoćeš da overklokuješ na ploči koja ne košta barem 150 € i koja nema barem 10+2 naponski VRM.

Sadašnji BD troši relativno malo na niskim naponima, ali kako se podiže napon tako disipacija eksponencijalno raste. Ovo sam testirao i vrlo dobro znam o čemu pričam.
Primera radi, na 1.22V je temperatura prilikom Prime95 stress testa nekih 40 stepeni, dok na 1.29V raste na 60. Da ne pričam šta se dešava na 1.4V, koji su ti neophodni za 4.5-4.6 GHz.

Tako postaje moguće tweakanje iste platforme za dva različita segmenta:

- kod servera je performans na Ws=J bog i batina.
- kod Workstationa i sotalih mašina moguće je iskoristiti frkvencijski headrom i dići frekvenciju za isti krajnji efekat.

Na serveru će TDP biti relativno nizak zbog relativno niskih frekvencija i radnih napona, mada tu stvar nije baš tako prosta. Određene serije procesora mogu da disipiraju manje i da imaju manji leakage, ali i nižu frekvenciju i overklok marginu, a opet druge mogu biti sa većim leakageom i većom OC. marginom, ali i većom disipacijom, naročito na većim radnim naponima.

Meni se koncept deljenja FPUa ALU-a u jednom modulu među dve jeztgre dopada. Bilo bi fino videti da li mogu da ga u Steamrolleru rastegnu preko dva modula, pa da dobiješ četiri "corea" sa resursima dva modula.

Teško da ćeš gledati taj "film". Kako misliš jedan FPU da "rastegneš" na dva modula, a da nemaš penal u vidu ogromne latencije FPU instrukcija, što je već problem kod BD-a? Da se razumemo, latencije instrukcija su veće kod BD-a nego kod K10 zbog dužeg pipelinea, veće latencije L1 cache-a itd... kao i zbog deljenja resursa. No to nije problem ukoliko nemaš puno grananja u kodu, zato što kada instrukcija uđe u pipeline, ušla je dok se ne izvrši i tako za redom ulazi ceo niz koda, a isto tako biva i izvršen, ako ne dođe do greške u predviđanju grananja što uzrokuje pražnjenjem pipelinea.

Bilo bi fino i da svaki core dobije po tri decoding unita za ALU ad da FPU unit ima svoje dekodere, koji ne opterećuju main unit. Tako te tight-loopovi SSE ibntrukcija u dekodelru ne bi koštali ništa.

Prvo, na FAT jezgru sa visokim IPC-om kakvo je Ivy Bridge, IPC u praksi retko kad prelazi 2 zbog prirode koda, t.j. TLP-a (thread level paralelism). Potreba za više od 4 dekodera po modulu je vrlo diskutabilna. Problem sa BD-ovim front-endom nije u dekoderima. Problem je u "fetch bandwidth-u". Naime, BD koristi dva 16-bajtna instrukcijsa prozora koja služe da dovlače kod iz L1 instrukcijskog keša. Ovo znači da po threadu ALU i FPU blok ZAJEDNO dobijaju najviše 16 bajtova instrukcija. E sad, instrukcije, t.j. opkodovi su obično različite dužine. Tipična x86 instrukcija sa 32-bitnim operandom je obično 5 bajta dugačka, što je dovoljno za pakovanje 3 instrukcije. Međutim ako imaš neki robustan SIMD kod koji se često pojavljuje kod renderinga tu može da dođe do problema. Npr:

-prefiks instrukcije može imati od 0-4 bajtova
-opkod od 1-2 bajta
-ModR/M 1 bajt
-SIB 1 bajt
-Displacement 1 bajt
-Immediate 1 bajt

Npr. SIMD instrukcija poput AVX ili nedaj Bože FMA4 može imati 8-12 bajtova čime si zakrčio fetch bandwidth. Još jedan problem je neporavnat pristup L1 instrukcijskom kešu. Npr. učitao je u bafer jednu instrukciju od 8 bajtova i jednu od 5 i ne ostaje dovoljno mesta za još jednu od 5.
Kako se većina računski zahtevnih operacija obavlja u "tight loop-ovima" t.j. u petljama, ako se "iza" dekodera upakuje jedan trace cache za dekodirane operacije ovime bi se povećale performanse i smanjio pritisak na dekodere i na fetch iz L1 instrukcijskog keša. Dakle, nema potrebe za milion dekodera koji realno troše ogromnu količinu prostora i energije. Druga stvar, ILP (instruction level paralelism), je osobina programskog koda da se paralelno izvršava u Out Of Order arhitekturi. Da bi se ILP povećao potrebno je izuzetno pametno pisati softver, sa što manje zavisnih promenljivih. Mahom sami kompajleri ovo ispravljaju, ali ne u potpunosti. Osim ovoga tu postoje uska grla kao npr. pristup memoriji i kešu višeg nivoa zbog čega IPC nikada nije 4.

Što se FPU-a tiče pristup deljenja istog je veoma pametan. FPU je često neiskorišćen od strane jednog threada-ALU bloka. Zbog toga BD odlično skalira sa 2 threada u modulu.

[kosta10]

Wow, svaka čast na analizi, hexenbiest. Pa kako se onda, po nekom tvom predviđanju, može obezbediti da Vishera bude čak 20 % brži od Bulldozera, a već se otprilike sigurno zna da će biti tih 20 %. Gde su dobili toliko ubrzanje, jer po ovome što ti napisa ispada da nema previše prostora za unapređenje, ili te ja nisam dobro ukapirao. Ako te ne mrzi daj neka objašnjenja. Hvala.

[magny_cours]

Mislim da je hteo da kaze kako je vrlo tesko bilo unaprediti IPC za nekih 20% prostim dodavanjem tranzistora a na postojecoj K10 arhitekturi i da je to upravo i jedan od razloga zasto je cela prica krenula u CMT pravcu. 20% u odnosu na K10 je tesko dostizno u jednom "potezu" ali Vishera nece doneti tih 20% u odnosu na K10 nego u odnosu na BD, a koji opet ima nizi IPC u odnosu na K10, pa otprilike taman za toliko(mada bih ja rekao da je ipak nesto manje, nekih 15% ako napravimo prosek svega)

A kako je moguce povecati IPC za 20% na PDu u odnosu na BD? Mislim da ce se najveci deo dobiti kroz dupliranje L1 DTLB-a i sredjivanje katastrofalnih latencija. To dvoje moze u teoriji doneti nekih 10% veci IPC. Jos par procenata ce se ostvariti kroz razna tvikovanja, a razlika do 20% vecih performansi u odnosu na BD bice pokrivena kroz visi klok i RCM, tako ja to vidim. Ne bi trebalo da bude iznenadjenja, za ocekivati je napredak od 20% ali da sacekamo.

[PCBeast]

Negde sam primetio da se provlaci prica da ce nadolazeci PD parirati Intel SB sto mi je za nepoverovati iz razloga jer oni prvo moraju
da podignu nivo performansi da bi se izjednacili sa Deneb/Thuban generacijom a realno gledano
u odredjenim testovima gubitak je i preko 20% sto implicira da u najboljem slucaju + tweakovanje mogu dostici samo performanse Thuban generacije procesora,mozda i nesto malo preko.
Mislim da su brzine SB-a jos uvek nedostizne..

P.S.Gde nestade ijekavski?
There Can Be Only One !

[RecklessLife]

Meni samo nisu jasne neke stvari, ili mozda nisam sve lepo procitao...

1. Ako je ovaj FM2 u stvari Piledriver a.k.a Vishera bez L3 kesa - koji je 15% brzi od Bulldozera, zasto se onda i dalje pravi pitanje da li ce Vishera biti brza od Bulldozera tih 20%?

2. Otkad je to Thuban jaci procesor od nekog, AMD-FX8120/8150? Posto vidim da se ovde pominje kako je Thuban bog i batina medj' AMD procesore... Je l' to svaki ciga svog konja hvali, ili ima neki argument?

Posto me bas zanima, da li bi zaista neko od vas koji tvrdi da je x6 Thuban bolji CPU od FX-8120 uzeo Thubana over FX-8120, ili 8150?

Cinjenica je da je FX-4200 tu negde, izmedju, Fenom II Deneba i Athlon II Propusa, tj., da je FX-6200 tu negde sa Deneb/Thuban AM3 procesorima - ali, nisam jos nigde video da je Thuban najjaci AMD-ov CPU?

Pogotovo, da je on jaci i na difoltu, od FX-a na 4GHz? Hm..

[Brane213]

Za prvo se slažem (low IPC), ali za drugo (disipacija energije) smatram da nisi u pravu, a ovo treće je razlog zašto je IPC nizak. BD ne bi bio loš da mu TDP nije toliko visok, a najveći problemi se javljaju kada hoćeš da overklokuješ na ploči koja ne košta barem 150 € i koja nema barem 10+2 naponski VRM.

Ne vidim više upotrabljivost OC-a bilo gde. Čipovi su prilično dobro testirani i proizvođači sve tačnije znaju da odrede gornu granicu čipa. Mnogo puta mi se desilo da prilikom OC-a naletim na skrivene felere i vrlo netipične sledove instrukcija na kojima takav CPU pada iako je pre toga prošao kroz sve "diagnostičke" programe, memtest masiranja itd itd.

Pored toga, tada potrošnja energije strmo raste a efekt je vrlo ograničen. U praksi mi se tu uvek daleko više isplatilo masiranje i optimizovanje koda. Između ostalog i zbog toga što takav kod daje rezultate i na svim ostalim a navijanje samo na jednoj mašini.

Teško da ćeš gledati taj "film". Kako misliš jedan FPU da "rastegneš" na dva modula, a da nemaš penal u vidu ogromne latencije FPU instrukcija, što je već problem kod BD-a? Da se razumemo, latencije instrukcija su veće kod BD-a nego kod K10 zbog dužeg pipelinea, veće latencije L1 cache-a itd... kao i zbog deljenja resursa. No to nije problem ukoliko nemaš puno grananja u kodu, zato što kada instrukcija uđe u pipeline, ušla je dok se ne izvrši i tako za redom ulazi ceo niz koda, a isto tako biva i izvršen, ako ne dođe do greške u predviđanju grananja što uzrokuje pražnjenjem pipelinea.

Pa da je jednostavno, to bi radila moja baba. Inače, sam dekoderski blok i broj ekekucijskih jedinica ne bi trebalo da previše ( ako išta) utiče na dužinu pipelinea. BD je duži, pošto je svesno rađen u tom smeru- optimizovan je ka všim taktovima. Na kraju krajeva, ceo njegov modul je tamo negde oko starog corea ( pa i AMD kaže da ga modul košta 11% više površine od starog K10 corea IIRC). A i ta površina nije bogzna šta. Daleko najveći deo površine BD odnose razni keševi a ne logika.

Prvo, na FAT jezgru sa visokim IPC-om kakvo je Ivy Bridge, IPC u praksi retko kad prelazi 2 zbog prirode koda, t.j. TLP-a (thread level paralelism). Potreba za više od 4 dekodera po modulu je vrlo diskutabilna.

Šta ti znači "retko kad" ? U smislu "na malo mesta u programu" ili u smislu "mali procenat vremena" ? Prvo mi se ne čini relevantno. Kod je puno puta optimizovan na onim mestima gde se daleko najčešće izvršava. Pogledaj recimo kod u linux jezgri za izračunavanje sindroma paritete RAID-6. Stvar prži sa gasom do daske. Radi se o malj petlji ali ona odlučuje o RAID-6 performansama.
Da CPU ima neki slot više u SSE jedinici, stvar bi ga koristila i to b se jasno videlo u performansama. Da SSE unit ume da piči samostalno, stvar bi radila kalkulacije kako u klasičnom CPU-u tako i u SSE delu.

I BTW ta mantra 2-3 instrukcije paralelizma ne važi tamo gde se snaga novih CPUa najviše reklamira - SSE/AVX jedinice. Te praktički uvek masiraju podatke u prilično tight loopovima a onda se rezultati koriste dalje. Već par puta sam gnjavio AMD zašto ne izvedu eksekuciju tih jedinica samostalno tako da:

- naredbe za njih ne guše zajednički instrukcijski dekoder
- da stvar ima mali bafer sa predekodiranim instrukcijama
- ima uslovne instrukcije.
- ima neki mali fleg registar ( "počni", "gotov sam" itd) za brzu komunikaciju sa CPU


Kod SSE/AVX te načelno ne zanima baš tačno šta se u jedinic dešava iz takta u takt. To je više teška artiljerija za carpet bombing nego precizan instrument. Kada bi mgao da startuješ "loop execute mode", ti bi mogao da radiš svoje dok SSE gruva i da svake toliko proveriš je li završila. Na žalost još nije tako ali sve upućuje na to, da če u sledećim generacijama APU pixel shaderi igrati baš tu ulogu.

Problem sa BD-ovim front-endom nije u dekoderima. Problem je u "fetch bandwidth-u". Naime, BD koristi dva 16-bajtna instrukcijsa prozora koja služe da dovlače kod iz L1 instrukcijskog keša. Ovo znači da po threadu ALU i FPU blok ZAJEDNO dobijaju najviše 16 bajtova instrukcija. E sad, instrukcije, t.j. opkodovi su obično različite dužine. Tipična x86 instrukcija sa 32-bitnim operandom je obično 5 bajta dugačka, što je dovoljno za pakovanje 3 instrukcije. Međutim ako imaš neki robustan SIMD kod koji se često pojavljuje kod renderinga tu može da dođe do problema. Npr:

Pa dobro, sad ti ako želš da ideš u ekstreme, možeš praktično svaku instrukciju da razvučeš na do 15 bajtova prefixima itd. U nekom solidnom optimizovanom kodu možeš da upenališ stvari tako, da koristiš kratke instrukcije. Tada bi ti mogućnost jačeg dekodera vrlo dobro došla. A još ako ne bi bio "zakrčen" SSE instrukcijama, toliko bolje.

Kako se većina računski zahtevnih operacija obavlja u "tight loop-ovima" t.j. u petljama, ako se "iza" dekodera upakuje jedan trace cache za dekodirane operacije ovime bi se povećale performanse i smanjio pritisak na dekodere i na fetch iz L1 instrukcijskog keša. Dakle, nema potrebe za milion dekodera koji realno troše ogromnu količinu prostora i energije.

Pa to je već korišteno na P4 AFAIK. Ali kako izgleda, nije bez mana. Meni je svejedno - dekoderi, keširanje predekodiranog koda ili nešto treće, samo da dekoding ne bude usko grlo.

Druga stvar, ILP (instruction level paralelism), je osobina programskog koda da se paralelno izvršava u Out Of Order arhitekturi. Da bi se ILP povećao potrebno je izuzetno pametno pisati softver, sa što manje zavisnih promenljivih. Mahom sami kompajleri ovo ispravljaju, ali ne u potpunosti. Osim ovoga tu postoje uska grla kao npr. pristup memoriji i kešu višeg nivoa zbog čega IPC nikada nije 4.

Ti problemi mene lično ne pogađaju i ne zanimaju. Radim sa otvorenim kodom između ostalog i iz tog razloga. Ako mi se nešto ne sviđa, otvorim source, pogledam i promenim. Keš može da bude problem ali ako može da opsluži SSE stream, trebalo bi da može i CPU jedinicu.

[Brane213]

Meni samo nisu jasne neke stvari, ili mozda nisam sve lepo procitao...

1. Ako je ovaj FM2 u stvari Piledriver a.k.a Vishera bez L3 kesa - koji je 15% brzi od Bulldozera, zasto se onda i dalje pravi pitanje da li ce Vishera biti brza od Bulldozera tih 20%?

2. Otkad je to Thuban jaci procesor od nekog, AMD-FX8120/8150? Posto vidim da se ovde pominje kako je Thuban bog i batina medj' AMD procesore... Je l' to svaki ciga svog konja hvali, ili ima neki argument?

Posto me bas zanima, da li bi zaista neko od vas koji tvrdi da je x6 Thuban bolji CPU od FX-8120 uzeo Thubana over FX-8120, ili 8150?

Cinjenica je da je FX-4200 tu negde, izmedju, Fenom II Deneba i Athlon II Propusa, tj., da je FX-6200 tu negde sa Deneb/Thuban AM3 procesorima - ali, nisam jos nigde video da je Thuban najjaci AMD-ov CPU?

Pogotovo, da je on jaci i na difoltu, od FX-a na 4GHz? Hm..

Sve to nema veze sa životom. Neka BD-2 bude i 30% brži od starog BD, pa šta ? Šta ti to 30% brži CPUomogućuje, što ti je bilo nemoguće sa BD pa sad opravdava upgrade ?

Proizvođači prave puno buke oko ničega, da bi se eto nešto dešavalo i da se piše o njima. Ja recimo imam Phenom II x4 955 BE i ne pada mi na pamet upgrade pre Steamrollera osim ako mi nešto ne crkne.

A i tada će glavni deo promene biti u promeni strukture mog celokupnog computinga a ne jednostavnoj zameni procesora.

[Wild Boy]

Sta ti omogucuje? Bolji odziv na timeline-u, bolji gameplay (pre svega bolji min fps), bolji rad virtuelnih masina itd. A da se dize preterana buka oko novih procesora to je tacno, svi aktuelni desktop procesori su dovoljno jaki da zavrse veliku vecinu poslova jednog prosecnog korisnika, vrlo retko rade po vise sati na preko 90% opterecenja, i korisnici uopste nisu toliko zavisni od svakog procenta performansi koliko misle da jesu. Na svakoj masini cete osetiti prisustvo SSD-a, a promenom procesora cete skok u performansama osetiti dosta teze i samo u specificnim situacijama, recimo ovim sa pocetka posta. Dobar procesor vas nece uciniti boljim dizajnerom, fotografom, administratorom ili programerom, ali vam moze olaksati posao.

[magny_cours]

Meni samo nisu jasne neke stvari, ili mozda nisam sve lepo procitao...

1. Ako je ovaj FM2 u stvari Piledriver a.k.a Vishera bez L3 kesa - koji je 15% brzi od Bulldozera, zasto se onda i dalje pravi pitanje da li ce Vishera biti brza od Bulldozera tih 20%?

2. Otkad je to Thuban jaci procesor od nekog, AMD-FX8120/8150? Posto vidim da se ovde pominje kako je Thuban bog i batina medj' AMD procesore... Je l' to svaki ciga svog konja hvali, ili ima neki argument?

Posto me bas zanima, da li bi zaista neko od vas koji tvrdi da je x6 Thuban bolji CPU od FX-8120 uzeo Thubana over FX-8120, ili 8150?

Cinjenica je da je FX-4200 tu negde, izmedju, Fenom II Deneba i Athlon II Propusa, tj., da je FX-6200 tu negde sa Deneb/Thuban AM3 procesorima - ali, nisam jos nigde video da je Thuban najjaci AMD-ov CPU?

Pogotovo, da je on jaci i na difoltu, od FX-a na 4GHz? Hm..

Zato sto lepo uzmu pa uporede klok za klok Tjubana i FX-8120/50, proberu ciljane aplikacije gde je ta clock per clock razlika velika u korist stare arhitekture i izvedu zakljucak da su Denebi/Thubani brzi 20% od BD-a, stara prica iz stare kuhinje

Prica naravno nema veze s mozgom jer se te arhitekture razlikuju u kloku i za vise od tih 20% kolika je razlika u IPCu(mada nije bas 20 ali ajde) i u setu instrukcija i u jos dosta stvari, uglavnom vec je odavno sve istestirano, preracunato i dokazano, Bulldozeri manjak IPCa u odnosu na prethodnu arhitekturu nadoknadjuju i prestizu kroz daleko visi klok i OC marginu, tako da naravno da nije tacno kako Piledriveri tek treba da dostignu performanse Phenoma. Tacno je da treba da dostignu IPC Phenoma ali performanse su vec predjene.

Situacija ce otprlike biti: IPC PD vs Ph II ~95-100% sto znaci da onoliko koliko PD bude procentualno isao preko 4GHz(sto ne neka prosecna OC margina za Thubane), toliko ce biti i brzi od Thubana u single threadu, u heavy threadovanom softveru ce zbog 8 integer jezgara biti i vise.

[hexenbiest]

Wow, svaka čast na analizi, hexenbiest. Pa kako se onda, po nekom tvom predviđanju, može obezbediti da Vishera bude čak 20 % brži od Bulldozera, a već se otprilike sigurno zna da će biti tih 20 %. Gde su dobili toliko ubrzanje, jer po ovome što ti napisa ispada da nema previše prostora za unapređenje, ili te ja nisam dobro ukapirao. Ako te ne mrzi daj neka objašnjenja. Hvala.

Pa i neće biti IPC nešto epohalno veći. 10-15% i to je to. To su mogli da postignu tako što su doterali keširanje memorije (povećanje TLB-ova), povećali su FPU load buffer (što im omogućuje više FP instrukcija u "letu" za jedan ili oba threada), zatim konačno hardverski IDIV (integer deljenje, koje je postojalo i kod BD, ali je zbog nečega bilo isključeno i mikrokodovano kao kod ranijih generacija), onda mogućnost izvršavanja određenih instrukcija na AGLU0 i AGLU1 jedinicama čime se znatno povećava paralelizam.
Da ne tupim dalje... PD nosi niz sitnih poboljšanja koja u globalu podižu IPC za 10-15%, a tu je još i smanjenje disipacije, curenja elektrona što donosi naravno veću OC. marginu i bolje performanse. Dakle, konceptualno gledano BD je veoma zanimljiv, ali je tu problem realizacije prisutan.

AMD lists the Piledriver enhancements over 1st gen Bulldozer as:
IPC Improvement
leakage reduction
CAC reduction (CAC = Pdynamic / V^2 * f)
frequency uplift

According to the slides, the IPC improvements will come from:
improved branch prediction
improved scheduling (INT & FPU)
larger L1 TLB
improved store-to-load forwarding
improved hardware prefetcher
L2 cache efficiency improvements
page translation reload optimised
faster instruction execution (INT/FPU divide, SYSCALL & SYSRET, etc)
ISA extensions (FMA3, F16C)
larger instruction window and improved locked instruction execution

[kosta10]

A zaboravili ste na one specifične BD instrukcije koje Intel nema, XOP se valjda zovu. Da li se pominje uopšte poboljšanje tih AMD instrukcija ili će se već sa Visherom odustati od njih i preći na FM3 kompletno ??? Brane123, hexenbiest, šta su vaša saznanja, ne bi bilo loše da to malo objasnite.

Ako se dobro sećam te XOP instrukcije bi trebalo da donesu značajno ubrzanje u video enkodingu i 3D modelovanju.

[RecklessLife]

Zato sto lepo uzmu pa uporede klok za klok Tjubana i FX-8120/50, proberu ciljane aplikacije gde je ta clock per clock razlika velika u korist stare arhitekture i izvedu zakljucak da su Denebi/Thubani brzi 20% od BD-a, stara prica iz stare kuhinje

Prica naravno nema veze s mozgom jer se te arhitekture razlikuju u kloku i za vise od tih 20% kolika je razlika u IPCu(mada nije bas 20 ali ajde) i u setu instrukcija i u jos dosta stvari, uglavnom vec je odavno sve istestirano, preracunato i dokazano, Bulldozeri manjak IPCa u odnosu na prethodnu arhitekturu nadoknadjuju i prestizu kroz daleko visi klok i OC marginu, tako da naravno da nije tacno kako Piledriveri tek treba da dostignu performanse Phenoma. Tacno je da treba da dostignu IPC Phenoma ali performanse su vec predjene.

Situacija ce otprlike biti: IPC PD vs Ph II ~95-100% sto znaci da onoliko koliko PD bude procentualno isao preko 4GHz(sto ne neka prosecna OC margina za Thubane), toliko ce biti i brzi od Thubana u single threadu, u heavy threadovanom softveru ce zbog 8 integer jezgara biti i vise.

Upravo to. To bi bilo isto kao kada bismo poredili, primera radi neki Deneb procesor sa nekim Propus procesorom, s tim da Propus ima po difoltu 500-600MHz visi takt.

Evidentno je da Bulldozer nije savrsen procesor, ali, s obzirom da FX-6200 koliko vidim, kosta 120 evra - ja zaista ne vidim sta fali tome? Sest jezgara koje ce sigurno neko uspeti da uposli, solidne performanse, overklokabilan je..

[PCBeast]

Od "fizike" se ne moze pobeci bilo da je jedna bilo da je neka druga arhitektura.
Razumeo bih kada bi neko rekao ne mogu da se porede Intel i AMD na istom kloku iz razloga jer su tehnologije razlicite ali provlaciti pricu
da je pogresno porediti clock vs clock jedne generacije sa sledecom istog brenda i uvideti jasan napredak ili cak promasaj kao sa BD varijantom stvarno nema smisla.
Jedini ispravan nacin i jeste uporediti "kvalitet" arhitekture poredeci je sa prethodnom generacijom na istim radnim frekvencijama.
Ovde se prica o napretku ali uz daleko vise radne taktove.Mazanje ociju koliko mogu da uvidim.
Kada se bude realno uporedilo tacno ce se doci do srednje vrednosti koliko ce zapravo Vishera doneti napredak i na kom nivou ce PD da bude,ja kazem negde na nivou Thuban CPU,mozda i nesto preko.

To bi isto znacilo kada bi SB vs Ivy poredili na razlicitim klokovima i utvrdili kako je Ivy ne znam koliko brzi a zapravo su razlike minorne clock vs clock!
Dajte malo ozbiljnosti,u svemu trazite opravdanje.
Nesto mora da se zna i neki standard da se postuje kako dolikuje..

Nesto ako je lose nikakva cena ne moze da popravi situaciju osim da za trenutak zamaze oci buducem kupcu ili ti nekom ko je generalno NE upucen!

[Brane213]

Pa kvalitet BD-a je u optimizaciji. Stvar se u osnovi bolje ponaša sa optimizovanim kodom, koji je prirodniji u serverskim okolinama ali isto tako BD pada ko kec na desetku i na workstation mašne sa GPL-x i sličnm kodom.

Ja nemam nikakav problem da iskompajlujem programe, koji mi trebaju baš za moj CPU i BD mi se u ovoj situaciji ( bez poredivog ARM-a ili još bolje MIPS-a) dopada.

Inače, istina je ono što reče AMDov diša - CPU je danas za ono za što se korsti više nego dosta brz i glavnina napora treba da ide na paralelizaciju a ne na 20% viši ili niži per-core performance.

[pcv co.]

Ti Beast stvarno ne razmislis pre nego sto napises nesto. BD je nova arhitektura predvidjena da radi na visokim frekvencijama, i u skladu sa tim napravljena. Znaci da nema veze sa K10 arhitekturom i ne treba je porediti sa njom na istom taktu. Praviti paralelu izmedju BD i K10 sa SB i IB tek nema veze sa mozgom. Pa IB je samo tweak SB, alo, a BD je potpuno nov dizajn.
Obecavam da ti necu vise dozvoliti da me ovako iznerviras.