Stoji da radni takt nece biti moguce povecati nesto preterano - uostalom nije bez veze Intel obecao "novu arhitekturu" na svake 2 godine. Jasno je da su u ovoj fazi izabrali povecanje IPC-ja umesto radnog takta, sto naravno ne znaci da u buducnosti, kada zastane proizvodni proces (ili se bar uspori), necemo videti reinkaranciju arhitketure slicne NetBurst-u. NetBurst je imao taj problem da inzenjeri koji su ga projektovali nisu mogli predvideti da ce zakazati proizvodni proces i da ce se problemi ispoljiti vec kod prve znacajne revizije NetBurst-a. Jedno je simulacija u idealnim uslovima, a drugo je ono sto su litografske masine u toj fazi mogle da pljusnu na wafer u zadovoljavajucim kolicinama. Sada npr. Pentium 4 ide i na 5-6 giga (Spacemaster je npr. imao neki suludi skor sa Cedar Mill-om), ali nikoga vise nije briga za to...
Potpuno se slazem sto se ovoga tice. Ipak, najbolja kombinacija bi bila, visok radni takt + visok IPC.
K10, po svemu sto se do sada zna, moze biti znatno brzi od K8, ali bas kao sto ni Penryn nece biti mnogo brzi od Core 2 tako ni K10 ne moze biti preterano brzi, ako i bude brzi, od Core 2 procesora (Penryn/Kentsfield). Jednostavno, nije moguce u tolikoj meri uticati realno na povecanje IPC broja ili preciznije: jos je teze da ce aplikacije (bas kao sto si naveo - nikada se ne koristi teroijski maximum po pitanju IPC-ja) iskoriste potencijal povecanog broja dekodera i izvrsnih jedinica koje determinisu teorijski IPC broj. Kao sto si i sam rekao IPC u praksi uvek ima nizu vrednosto d terijske, jer zavisi od dodatnih faktora kao sto je npr. brzina kojom su dekoderi punjeni podacima ili latencijom memorije itd...
Pre bih rekao, da IPC broj ima veze sa velicinom instrukcija, njenim troughput-om i latencijom. Naime za svaku instrukciju koja ulazi u pipeline je potrebno od jednog do nekoliko ciklusa da bi ona vratila vrednost. Sto je instrukcija veca i sto je unutrasnja procesorska magistrala (dekoderi, medjuveze i izvrsne jedinice) manja, to je troughput manji, a latencija veca.
Sto se tice numericke snage, K10 ce imati vece performanse od Penryn-a i od Core 2, teorijski gledano. A za to postoji vise faktora. Ipak, ja ne ocekujem da ce to biti mnogo vece. Zahvaljujuci poboljsanoj arhitekturi one ce biti i u realnosti nesto vece, za integer kod i podatke, klok za klok od 0-20%, a mozda ce negde biti i sporiji. Ono gde je K8 bio ogranicen, je ispravljeno kod K10. Npr. stack hardware, bolji branch predictor - reverzibilni, pametnija i brza kesh arhitektura, L1 prefetch, OoO load execution. Nema razloga za sumnju da ce K10 biti zver.
Floating point engine je uradjen bolje nego kod Conroe-a, ortogonalnost je daleko bolje uradjena, slicno kao sto ce biti i na Penryn-u, pored toga, drasticno poboljsan IMC moze doneti 10% ubrzanja i u FP i u Integer-u u odnosu na K8, uopste IMC donosi poboljsanje u performansama. 32 byte prefetch donosi kompletno ubrzanje i povecanje IPC broja.
AMD ima prednost sto se tice iskoriscenja potencijalnog IPC broja i zato sto ce memorija biti u manjoj meri usko grlo, ali mislim isto tako da deljeni L2 kes ostaje jaka strana Core 2 arhitekture. Opet, AMD ima i Crossbar switch...
Deljeni L2 kes koliko ima dobrih toliko ima i losih strana. Ako je u pitanju deljenje podataka/instrukcija na threadove, onda jeste prednost. Ako je u pitanju iskoriscenje kompletnog kesa u single thread operacijama, onda opet svakako jeste prednost. Ipak ako je u pitanju rad sa razlicitim stvarima u isto vreme, onda je problem cache trashing, koji ume da donese usporenje.
Iskreno, mnogo mi se vise svidja ideja o deljenom L3 kesu.
U svetlu toga se odnosi moja opaska da sintetika nece registrovati prednosti Phenom-a, ali ce realne aplikacije (mada ne postoje nerealne
) usled npr. prisustva famoznog integrisanog memorijskog kontrolera i sl. mozda dati prednost Phenom-u.
Diskutabilno je sta ce dati prednost Phenom-u, ako su u pitanju renderi, onda to moze da bude bolja ili losija FPU/SSE jedinica. Ako je u pitanju rad sa bazama podataka to moze da bude bolje resena sekcija za adresnu aritmetiku + mem controler + stack engine.
Ako je u pitanju igranje, onda opet mem kontroler stupa na scenu, poboljsanja kesh arhitekture, poboljsan SSE engine itd.... samo je pitanje koliko.
Pitanje je i koliko samo 512K L2 kesa utice na performanse. Pitanje je i koliko dodatni L3 utice na performanse. Papiroloski gledano, Phenom bi morao da bude brz ko munja, skoro u svemu.
Takodje, jos jedna stvar koju ce umeti da cene realne aplikacije, a sintetika nece registrovati, svakako je i implementacije poboljsanog crossbar switch mehanizma komunikacije jezgara mimo L3 kesha. Kod Core 2 arhitekture ta veza je drugacija i delom se i dalje odvija preko FSB-a, a delom preko L2 kesha. Jasno je da jos nije napisana sintetika koja ce znati da u pravoj meri izmeri brzinu komunikacije medju jezgrima i npr. sve to upotpuni zavisnoscu krajnjeg skora od komunikacije sa memorijom (mada teorijski tako nesto nije tesko napisati - padaju mi napamet 2-3 scenarija u realnom radu koja bi mogla da to iskoriste), pa ce zato Phenom mozda razocarati u sintetickim testovima, posebno ako se ima u vidu da radi na nizem taktu od Intel-ovih procesora. Isto tako, komplexnija arhitketura K10-tke dodato otezava postizanje vishih radnih taktova, poskupljuje proizvodnju itd...
Dakle, ne vidim razloga zasto Phenom ne bi i u sintetickim testovima bio rame uz rame sa Core 2, osim nesto nizeg radnog takta. Jedina realna prednost Core2 uarhitekture je postojanje tzv. macro fusion-a, koji inace ne radi u 64-bitnom modu, sto opet ne utice drasticno na performanse. Ne moze se reci da C2D u 64-bitnom modu radi mnogo sporije sa 32-bitnim softverom, nego sto to radi u 32-bitnom modu. Mozda je to slucaj u nekim situacijama, prilicno retkim.
PS: Bilo bi zanimljivo napraviti indexe efikasnosti arhitekture: koliko u realnosti odredjena arhitektura postize od teorijski maximalnog IPC-ja. Naravno, tu se opet sve svodi na pravilan izbor test programa i ponderisanje rezultata, ali bi u svetlu price da je IPC, na ne radni takt kljucan za povecanje performansi, takav benchmark program bio mnogo zanimljiviji kao neki sintetizovani pokazatelj efikasnosti cele arhitekture (umesto pateticnih testova tipa SPECinit2000 i sl.)
Ja sam vec radio slicne testove, a i postoje benchmark programi koji to rade i lako je moguce za bilo koju aplikaciju izmeriti IPC broj, kao i to koje se instrukcije koriste
Npr. IPC broj drasticno opada kada procesor ima veliki broj cache miss-ova i kada cesto poseze u memoriju za podacima. Primera radi, 128-bit SSE2 na K8 uarhitekturi moze da realno izvuce maksimum oko 0.6 IPC-a, iako je decode bandwidth maximum 1 IPC . Ovo se odnosi na datasetove do 64K koji staju u L1. Za L2 efikasnost opada na 0.3 IPC, a za memoriju ide na 0.2-0.1. Da ne pricamo koliko se latencija ovih SSE instrukcija povecava pri tzv. double dispatch i izvrsavanju preko fastpath-a.
Ipak, nije sve tako strasno, 128-bit vector SSE odradi veliki broj izracunavanja u tih 0.6 ciklusa.
Decoding bandwidth je inace limitiran na 1 IPC zbog 16 byte prefetch-a, max bi bio 1.5 IPC zbog tri dekodera. Ipak izvrsni resursi ne dozvoljavaju izvrsavanje vise od 1 IPC za 128-bit SSE.
Kod core2 je situacija nesto drugacija. Hardver omogucava max 2x128-bit SSE, ali u praxi to nije moguce. C2 moze da dovuce najvise jednu 128-bit sse i da je izvrsi. Kod skalarnog koda, moguce je dovuci 2x64-bit SSE, dekodirati ih i izvrsiti. Prakticno IPC broj kod Core 2 za 128-bit SSE je negde oko 1, prema nekih 0.6 kod AMD K8, sto odgovara realnoj razlici od 40-tak % u vektorskim izracunavanjima. Dodatnu prednost donose simple dekoderi pri izvrsavaju instrukcijskog miksa.
Kod K10 je situacija nesto povoljnija nego kod ova dva prethodna. K10 ima tri FP izvrsne jedinice i 32-byte prefetch i tri kompleksna dekodera. To mu umogucava da dekodira max 2x128 bit i da ih izvrsi, sto je veliki napredak. Ipak, to u praksi ne verujem da ce biti slucaj. Moze da se dogodi da K10 moze da izvrsi do jednu skalarnu i jednu 128-bitnu SSE operaciju.
To dozvoljava i fetch bandwidth i sirina izvrsnih jedinica. S' obzirom na to da je broj izvrsnih jedinica ostao isti, maksimalni broj skalarnih operacija ce ostati isti, bas kao sto je opisano u optimization manualu.
Sve u svemu, morali bi nesto gadno da zeznu da bi ovaj procesor bio jedva brzi od K8 i nekompetentan u odnosu na Core 2.
