Šta je novo?

AMD Phenom

Status
Zatvorena za pisanje odgovora.
Audio peva staru pesmu o grožđu koje je kiselo, a photo ilustracija je veoma duhovita!
 
10 Septembra ili tacno za 24 dana izlaze prvi native Quad-Core procesori na svetu
Opteron 2340 i 2350. Prvi na 1.0 GHz a drugi na 2.0 GHz ce se prodavati na velikom trzistu po cenama od 320 odnosno 390 Americkih dolara. U oktobru se ocekuju brze verzije na taktovima od 2,1 do 2,4 sa oznakama 2352,2354,2356,2358 a cenovno ce kostati izmedju 450 i 1180 $. Modeli sa vecim taktovima bi trebali da imaju TDP od 120W dok bi disipacija slabijih varijanti bila 95W.
 
Poslednja izmena:
Na TDA,rekli su "record yields for Barcelona" i pokazali grafikon sa uporednim prikazom yield-a za Brisbane i K10 koji su bili u skoro pa u dlaku isti(sa malom prednoscu za K10).

Prikazana je gustina defekata koja bi i trebala biti ista. Velicina jezgra ce doprineti manjem konacnom yield-u. Mada je u svakom slucaju gustina defekata ispod 0.5cm^2 za pohvalu.
 
10 Septembra ili tacno za 24 dana izlaze prvi native Quad-Core procesori na svetu
Opteron 2340 i 2350. Prvi na 1.0 GHz a drugi na 2.0 GHz ce se prodavati na velikom trzistu po cenama od 320 odnosno 390 Americkih dolara. U oktobru se ocekuju brze verzije na taktovima od 2,1 do 2,4 sa oznakama 2352,2354,2356,2358 a cenovno ce kostati izmedju 450 i 1180 $. Modeli sa vecim taktovima bi trebali da imaju TDP od 120W dok bi disipacija slabijih varijanti bila 95W.

Nadam se da je ovo 1.0 GHz za 320$ greska :d
 
VT napredovanje zvuci lepo; bash me zanima koliko (u prevodu ZA STA) znace nested page tables.
Ima neko jedan na probu?:) Necu nikome da kazhem :D
 
Nested page tables help reduce compile time of applications
U detaljima :):
2007New for “Barcelona” -Nested Paging
Maps a page in the virtual address space to a page in the physical address space
Hardware provides for two levels of address translation
1.Map guest virtual address to guest physical address
2.Map guest physical address to host physical address
Most recently used translations –guest virtual to host physical –are cached in the TLB

Hypervisor assigns a unique ASID for each guest to enable co-existence of entries in TLB

Significant performance improvement over shadow page tables
Eliminates hypervisor cycles managing shadow pages
Eliminates page fault world switches

Nadam se da je jasnije :).

Izvor:AMD,“Barcelona” Update First Quarter, 2007,pdf fajl.
 
Poslednja izmena:
Ukratko:

- Core ima bolji instruction fetch zbog bafera i optimizacije za petlje
- Branch prediction "prema nekim podacima u nekim slucajevima moze biti losiji nego kod Intela"
- Dekoder je nesto poboljsan ali throughput je 3 µop-a po ciklusu (Core i nadolazeci Penryn 4) sa tim sto K10 moze ubacivati "prazne" µop-ove ako ne moze da ih upari tako da je pitanje da li ce dostici i ta 3 µop-a po ciklusu.
- Samo 72 µop-a "in flight" (isto kao kod K8, Core ima 96)
- out-of-order read i write (imao jos Netburst)
- i dalje ne moze speculative read pre write kao Core (memory disambiguation)
- brzi integer divide (koga briga kad se retko koristi)
- SSE load ne ide preko FSTORE (to je bolje)
- moguc je unaligned load-execute, zahteva rekompajliranje koda i nije u skladu sa Intel SSE specifikacijom (specifikacija zahteva da se generise exception)
- 1x 128-bit write ili 2x 128-bit read ili 1x 128-bit read i 1x64-bit write (read bus prosiren na 128 bita, write ostao 64 bita)
- L1 cache i dalje 2-way i iste velicine (bezveze)
- L2 i dalje exclusive 16-way 512KB per core
- Shared L3 (bolje ali po meni losije od shared L2 jer je "dalje" od jezgara koja preko njega komuniciraju)
- 32+16 L1 ITLB, 48 L1 DTLB entry-ja (128 i 256 kod Core respektivno)
- Poboljsan prefetch (ali ne bolji od Core, a mozda ne i od Netbursta)
- Virtualizacija poboljsana navodno za 40%
 
Poslednja izmena:
U detaljima :):
Nadam se da je jasnije :).
Nimalo - znam vec te detalje od prvih specs, ali jedno je reci Nested>Shadow 40% - koliko je to za konkretne primene (recimo web server, file server, prosecan MM_in_VM, FSD testing etc.).
Stvari tipa obicna kalkulacija, Cinebench recimo, rade isto u VM-u kao van njega. Tu Nested page tables znaci 0. Kapiras sta pitam ustvari? Lepo sve gore pishe u teoriji - kako to stoji i gde u praksi.
 
- L1 cache i dalje 2-way i iste velicine (bezveze)
- L2 i dalje exclusive 16-way 512KB per core
- Shared L3 (bolje ali po meni losije od shared L2 jer je "dalje" od jezgara koja preko njega komuniciraju)
Verovatno su isprobali kako radi shared L2, veci L2, itd. pa su videli da je bolje ovako. Nema sanse da su samo na papir stavili i rekli ovako cemo.
 
Ukratko:

- Core ima bolji instruction fetch zbog bafera i optimizacije za petlje

Mozda, kada bi asemblerski programi bili potpuno u petljama koje su do 18 instrukcija dugacke ukupno 64B dugacke i imale max. 4 uslovna grananja. Ipak u svim ostalim uslovima K10 ima bezuslovnu sposobnost da dovlaci 32B-ne blokove iz memorije, a Core 2 samo 16B-ne.
 
Mozda, kada bi asemblerski programi bili potpuno u petljama koje su do 18 instrukcija dugacke ukupno 64B dugacke i imale max. 4 uslovna grananja. Ipak u svim ostalim uslovima K10 ima bezuslovnu sposobnost da dovlaci 32B-ne blokove iz memorije, a Core 2 samo 16B-ne.

Pa vecina petlji i jeste jednostavna, a slozenije petlje bolji kompajler moze razbiti na dve proste.

K10 moze dovuci 32 bajta i to moze biti prednost pri dekodiranju dugackih slozenih instrukcija, pogotovo u 64-bitnom modu, medjutim i dalje ima samo 3 µop-a po taktu a od ta tri moze se desiti da jedan ili dva budu "empty" ako ne moze da nadje odgovarajuci da upari.
 
- Core ima bolji instruction fetch zbog bafera i optimizacije za petlje

Core ima 64 byte buffer za predecode instrukcije, sto je uz loop predictor odlicno za kratke petlje sa srednjm brojem iteracija. Ali ne doprinosi mnogo obicnom fetch-u. (Pre)Decode je jedna od najslabijih tacaka Core-a i sigurno glavni kandidat za unapredjenje kod Nehalema (pogotovo ako ce imati SMT).

S druge strane K8/K10 cuvaju predecode bitove ne samo u malom bufferu, nego i u L1/L2/(L3) kesu. Tako eliminise predecode kao usko grlo, a cak i omogucava da drugo jezgo dobije vec pedekodirane instrukcije iz deljenog kesa.

- Branch prediction "prema nekim podacima u nekim slucajevima moze biti losiji nego kod Intela"

Da, Core jos uvek ima napredniji branch predictor.

- Dekoder je nesto poboljsan ali throughput je 3 µop-a po ciklusu (Core i nadolazeci Penryn 4) sa tim sto K10 moze ubacivati "prazne" µop-ove ako ne moze da ih upari tako da je pitanje da li ce dostici i ta 3 µop-a po ciklusu.

O kakvom to uparivanju pricas?

- Samo 72 µop-a "in flight" (isto kao kod K8, Core ima 96)

Sama in-flight brojka nije toliko vazna koliko Reservation Station, jer scheduler moze da vrsi reordering samo onoga sto je u RS-u. K10 ima 24 (3x8 tacnije) RS mesta za integer pa je tu u zaostatku, posto Core ima RS sa 32 mesta.
K10 FP scheduler je ostao na istih 36 mesta kao i K8, medjutim 128-bitne SSE instrukcije vise ne zauzimaju 2 mesta nego jedno, sto prakticno povecava raspolozivo mesto. Jos je malo poboljsan tako da ne pravi gluposti kao na K8.

- out-of-order read i write (imao jos Netburst)

Imao jos P6 ;)

- SSE load ne ide preko FSTORE (to je bolje)

Ne znam odakle piscu ta ideja. Load-ovi nikad nisu isli preko nijedne FP jedinice. Memorijski zahtev ide preko AGU-a, Load/Store jedinice i onda ga dobija FP regiser file ili ga direktno hvata odgovarajuca FP jedinica preko bypass network-a.
FSTORE je jedina jedinica koja moze da radi store (logicno :) ).

- moguc je unaligned load-execute, zahteva rekompajliranje koda i nije u skladu sa Intel SSE specifikacijom (specifikacija zahteva da se generise exception)

Dok Intel ne uvede slicnu mogucnost, od ovoga nece biti nista.

- Shared L3 (bolje ali po meni losije od shared L2 jer je "dalje" od jezgara koja preko njega komuniciraju)

Nehalem ce isto imati dedicated L2 i shared L3.

- 32+16 L1 ITLB, 48 L1 DTLB entry-ja (128 i 256 kod Core respektivno)

Ne mozes ih direktno porediti posto je na K8/10 L1 TLB fully set associative, dok je Core L1 TLB 4-way. Sem toga K8/10 ima po 512-entry 4-way L2 I/DTLB, dok Core nema L2 TLB.

K8/K10 jos ima i TLB flush filter koji sprecava nepotrebno praznjenje TLB-a.
 
Poslednja izmena:
10 Septembar se primice, neverovatno da nijedan test nije leak-ovao...
 
Sama in-flight brojka nije toliko vazna koliko Reservation Station, jer scheduler moze da vrsi reordering samo onoga sto je u RS-u. K10 ima 24 (3x8 tacnije) RS mesta za integer pa je tu u zaostatku, posto Core ima RS sa 32 mesta.
K10 FP scheduler je ostao na istih 36 mesta kao i K8, medjutim 128-bitne SSE instrukcije vise ne zauzimaju 2 mesta nego jedno, sto prakticno povecava raspolozivo mesto. Jos je malo poboljsan tako da ne pravi gluposti kao na K8.
Ali Core ima deljen RS i za FP i integer, sto nije slucaj kod K8/K10. K8/K10 ima odvojen FP cluster. Pri izvrsavanju cistog integer koda je mozda Core u prednosti.

Ne znam odakle piscu ta ideja. Load-ovi nikad nisu isli preko nijedne FP jedinice. Memorijski zahtev ide preko AGU-a, Load/Store jedinice i onda ga dobija FP regiser file ili ga direktno hvata odgovarajuca FP jedinica preko bypass network-a.
FSTORE je jedina jedinica koja moze da radi store (logicno :) ).
U Software Optimization Guide-u za 10h procesore kazu da je sada moguce izvrsavati operacije na svim FP pipe-ima.
Primera radi kod K10 MOVAPD xmmreg1, xmmreg2 moze da se izvrsi preko svakog FP pipe-a, dok kod K8 je bilo moguce preko FADD/
FMUL. Dakle, FSTORE je uposlen da radi operacije register2register transfera da bi se oslobodili korisni FP resursi.
 
Poslednja izmena:
Da, Core jos uvek ima napredniji branch predictor.

Potekao sa Netbursta :d

O kakvom to uparivanju pricas?

U tekstu pise (ako sam dobro razumeo) da ako K10 ima spremnu instrukciju od 2 µop-a i ne moze da nadje slobodnu/spremnu instrukciju od 1 µop da je izvrsi (posto ima 3 µop-a po ciklusu) ubacice "empty" µop umesto nje.

Sama in-flight brojka nije toliko vazna koliko Reservation Station, jer scheduler moze da vrsi reordering samo onoga sto je u RS-u. K10 ima 24 (3x8 tacnije) RS mesta za integer pa je tu u zaostatku, posto Core ima RS sa 32 mesta.

Vazna je za instruction throughput.

Ne mozes ih direktno porediti posto je na K8/10 L1 TLB fully set associative, dok je Core L1 TLB 4-way. Sem toga K8/10 ima po 512-entry 4-way L2 I/DTLB, dok Core nema L2 TLB.

Core zato ima unified (L1 i L2) DTLB i L1 ITLB sto je meni logicnije:
Kod:
L1 ITLB 4K page : 128 entries, 4-way set associative
L1 ITLB 4M page : 4 entries, 4-way set associative
Unified DTLB 4K : 256 entries, 4-way set associative
Unified DTLB 4M : 16 entries, 4-way set associative
 
Potekao sa Netbursta
Pa naravno kad su se siroti Intel inzinjeri kojima je pripao zadatak da prave branch-predictor za NetBurst suocili sa verovatno najvecim izazovom u svojoj karijeri da umanje gubitke 20-30-taktnog ultra-pipeline-a! I da bi ispunili zadatak (da NetBurst kako-tako funkcionise pri grananju) morali su da naprave cudo.

I tako, naravno da je branch-predictor koji je relativno uspesno ukrotio NetBurst neverovatno dobar (relativno uspesno u kontekstu NetBurst pipeline-a znaci mega-ultra-giga dobro) i da sa lakocom drzi umereni Core 2 pipeline skoro skroz pun (zajedno za reorderingom instrukcija).

Off: Testovi Penryn-a na sve strane, a od testova Barcelone/Phenoma ni traga ni glasa :(.
 
Poslednja izmena:
Core zato ima unified (L1 i L2) DTLB i L1 ITLB sto je meni logicnije:
Kod:
L1 ITLB 4K page : 128 entries, 4-way set associative
L1 ITLB 4M page : 4 entries, 4-way set associative
Unified DTLB 4K : 256 entries, 4-way set associative
Unified DTLB 4M : 16 entries, 4-way set associative
Logicnije verovatno za inclusive cache arhitekturu.
 
Rahul Sood about Phenom

http://www.rahulsood.com/2007/08/benchmarks-are-wiggedy-wiggedy-whack.html

Covek se raspisao o Phenomu(izgleda da je video rezultate nekih testova :D).
Najzanimljivi citat:
So, AMD decided to unveil Phenom running at 3.0GHz without showing actual benchmarks. What it showed was a game running smoothly with all details enabled, which makes perfect sense to me. And for the record, if you were to benchmark Phenom at 3GHz you would see that it kicks the living crap out of any current AMD or Intel processor—it is a stone cold killer (at 3GHz, now imagine how it would perform if they could squeek some more juice out of it?).

I’m guessing that AMD will be able to launch some parts at higher clocks than it is currently showing in its roadmaps, and if the company can get these chips on shelves in a timely fashion, I think it could be a major coup and could even be the impetus for the turnaround the company so desperately needs. Of course, Intel probably won’t get caught flat-footed, but AMD has to start somewhere.

It’s interesting to note that AMD isn’t showing benchmarks on a part that delivers the goods—perhaps it too is seeing that performance benchmarks are only a small piece of the overall experience puzzle. That said, I suspect there will be some more shaking up at AMD before the sun starts to shine green again.

Stone cold killer je prilicno jak izraz :).Posto znamo koliko je Penryn brzi od Merom-a(5-10%),ako je ovo gore citirano tacno(a covek je ipak malko vise informisan od Fuada Abazovica :) ),onda K10 mozda i ne treba sumanut klok da bi bio konkurentan cip.

A sto se tice cenovne politike u server segmentu ,pogledajmo kako ce se AMD pozicionirati cenovno i prema perf. sa K10 protiv Penryn-a(sto nam moze pomoci da zakljucimo da li je K10 brzi i koliko,bar okvirno ako nista drugo):

http://www.xbitlabs.com/news/cpu/display/20070815102710.html

If we compare these prices with the recently reported pricing of the upcoming AMD Barcelona processors, we can see that AMD estimates the IPC of their upcoming solutions much more optimistically. The direct competitor to the upcoming Opteron 2350 with 1.9GHz clock speed will be the new Xeon E5420 working at 2.5GHz, and Xeon X5460 working at 3.16GHz will compete with Opteron 2358 running at 2.4GHz speed

Ukratko,K10 bi trebalo da je u proseku brzi 31% od Penryna,klok za klok, da bi AMD mogao da ga uopste pozicionira na ovaj nacin(31% deficit u kloku za istu cenu,1.9 vs 2.5Ghz;2.4 vs 3.16Ghz).Posebno imajuci u vidu sto AMD mora da kompenzuje cinjenicu da ce Penryn trositi manje energije od Merom derivata pa u razliku ceni u stvari mora da uracuna jos i to-perf./watt(fakticki bi morao da bude K10 jos brzi jer ce imati nesto veci TDP od Penryn-a,bez obzira na to kako intel racuna TDP ili to sto K10 ima IMC;izvesno je vec da ce intel imati vrlo power friendly quad core procesore sledece godine).
 
Poslednja izmena:
WOW, covek je video da igra sa ___CROSSFIRE___ kartama radi smoothly! LIII, covece, kako mocan procesor!
Znao ne znao, rekao je manje nego FUD. Blago njemu kad je na osnovu igre video da procesor "cepa". (ma koja to igra bila...)
 
WOW, covek je video da igra sa ___CROSSFIRE___ kartama radi smoothly! LIII, covece, kako mocan procesor!
Znao ne znao, rekao je manje nego FUD. Blago njemu kad je na osnovu igre video da procesor "cepa". (ma koja to igra bila...)

Ne nego je covek video rezultate testova Phenom-a(jer je CEO gaming department-a jedne male firme koja se zove HP :) ).
 
Ko zna,verovatno sto se nije proslavio kao chief salesman u kriznoj situaciji :d.Salim se,naravno,mada nije nemoguce da su deonicari trazili neku odgovornost pa su dobili nesrecnog Henry-a koji se najvise isticao u javnosti.
A kao sto sam rekao,sad kad je u AMD prebegao jedan od glavnih intel-ovih PR master-a :D,nije problem naci dobru zamenu za Richards-a.
 
Poslednja izmena:
Ja verujem da ce Phenom biti mocan CPU, ali ne znam koliko. Sasvim sigurno je da ce biti brzi od K8, a verovatno i od Core2 klok za klok, u nekim stvarima vise, a u nekima manje, a u nekima ce mozda biti i sporiji.

Videcemo svakako uskoro koliko je to tacno.

Ko zna,verovatno sto se nije proslavio kao chief salesman u kriznoj situaciji :d.Salim se,naravno,mada nije nemoguce da su deonicari trazili neku odgovornost pa su dobili nesrecnog Henry-a koji se najvise isticao u javnosti.
A kao sto sam rekao,sad kad je u AMD prebegao jedan od glavnih intel-ovih PR master-a :D,nije problem naci dobru zamenu za Richards-a.

Ja upravo obrisao svoj post jer sam video da ima u drugom threadu o ovome. :d
 
Poslednja izmena:
To ne znaci da je u pravu. Covek je video samo jednu igricu, na kratko. Isto kao i HL Lost Coast demo za Penryna.
Posto ti ocigledno znas kako radi fen, najbolje je reci ovo:
"Speak now, or forever hold your peace".
Tj. daj konkretne brojke, ili ne ocekuj poverenje. Bar ne dok ne vidimo brojke.

Ne nego je covek video rezultate testova Phenom-a(jer je CEO gaming department-a jedne male firme koja se zove HP :) ).
 
Nego, ako cemo da se igramo ove igre, ajde onda ovako:
Xeon 5365 (3G) @ 1200USD
Opteron 8222 (3G) @ 1600USD
(najmanje cene u USA za oba)
Znaci za octal core:
Xeon 5365 x2 = 2400USD
Opty 8222 x4 = 6400USD
Za otprilike iste performanse (+/- kako gde, da ne tupimo)
Znaci ovako ce AMD da pozicionira Phenome?:)
A sto se tice cenovne politike u server segmentu ,pogledajmo kako ce se AMD pozicionirati cenovno i prema perf. sa K10 protiv Penryn-a(sto nam moze pomoci da zakljucimo da li je K10 brzi i koliko,bar okvirno ako nista drugo):
http://www.xbitlabs.com/news/cpu/display/20070815102710.html
Ukratko,K10 bi trebalo da je u proseku brzi 31% od Penryna,klok za klok, da bi AMD mogao da ga uopste pozicionira na ovaj nacin
 
Status
Zatvorena za pisanje odgovora.
Nazad
Vrh Dno