DeanXP je napisao(la):
Integrisani mem. ctrl. ga je do sada vadio. K8L ce morati na druge stvari da se oslanja. K8 ima ogromnu brute force snagu sa 3 AGU + 44-entry L/S unit + dual-port L1 + int. mem. ctrl., ali ih ne koristi ni blizu pametno kao Conroe svoje relativno skromne load AGU + store AGU + ext. mem. ctrl.
O prefetcher-ima malo govore i AMD i Intel, ali su oni itekako bitni u celoj memorijskoj prici. AMD je izgleda zaostao i u ovom pogledu. To bi objasnilo K8-icinu zavisnost od latency-a. Testovi overklokovanog FX-62 sa DDR2-1066 memrorijom to donekle potvrdjuju. S druge strane Conreo najverovatnije ima znacajna unapredjenja prefetchera o kojima Intel mudro cuti (slicno kao sto su cutali o P6->Banias unapredjenjima). K8L ce svakako morati da se znacajno popravi u ovim poljima ako zeli da konkurise Conroe-u u integer kodu.
Slozio bih se sa tobom. Egzekucioni resursi K8-mice su dosta veliki, a K8L ima jos vece egzekucione resurse. To je verovatno i razlog zasto AMD polaze tolike nade u njihovu arhitekturu. S' druge strane, zaista je trebalo napraviti integrisani memorijski kontroler. Mislim da to nije bio lak posao. Sad je dosao red na prefetcher.
DeanXP je napisao(la):
Kako stoji K8, ni nemaju razumnog nacina da ga prosiruju preko 3-way, mada to ne mora biti negativno. Kad se radi o executionu, K8 i Conroe su izjednaceni. Oba izvrsavaju 3ALU + mem. Tako se Conroe-ova 4-way prednost svodi na decode bandwidth, za sta bi K8L-ova 4 decodera mogla da nadoknade. S tim da sem bandwidtha pri 128-bit SSE instrukcijana, mogu da pomognu i pri integer kodu sa puno grananja. Ako se tome pridoda i novi indirect branch predictor, mogla bi se videti pristojna ubrzanja, mada nije zagarantovano. Kao sto kazes jos uvek je malo poznato o K8L.
Jedino mi se cini da je FPU ocigledna prednost.
Upravo tako. Intel je NGMA nazvao 4-way zbog mogucnosti dekodiranja 4 x86 instrukcije u ciklusu i njihovog ubacivanja u pipeline. Ono sto ne znamo jos sigurno, je to da li ce K8L imati cetvrti dekoder ili je u pitanju samo jos jedan mikrokod rom, kako kažu sa Chip-Architecta.
K8L ce imati 2x2 64-bitne SSE vektorske FPU jedinice i prakticno 2 FADD, 2 FMUL i 2 FSTORE - misc, 3 ALU i AGU jedinice. Svakako da ce dekoding bandwidth morati da bude povecan, da bi se "nahranio" toliki exec. engine. Do sada decoding engine K8 procesora je mogao da teoretski dekodira jednu i po 128-bitnu SSE instrukciju, a da bi sada mogao da dekodira 2 128-bitne instrukcije, potreban je veci trougput, bar za jos jednu decoding jedinicu. AMD nije nista naveo po tom pitanju.
Conroe pak ima 3 vektorske SSE FPU jedinice, od kojih su bar dve 128-bitne, pa je moguce izvrsavanje do 2 128-bitne FPU instrukcije, sto je max. za decoding bandwidth, pa se cela prica svodi na isto, kao kod K8L. Pri koriscenju double precision FP instrukcija peformanse ce im biti vrlo slicne, a u tradicionalnom x87 legacy kodu ce ga K8L kidati.
S' druge strane K8 ima 3 FPU jedinice, od kojih je jedna FMUL, druga FADD, a treca FSTORE. Na prve dve moze se izvrsavati i SSE SIMD u 64-bitnoj preciznosti. U 128-bitnoj preciznosti radi se split instrukcije na 2x64bit.
Ono sto je veliko pitanje je latency ovih instrukcija.
Hehe, to se pitanje vrti vec nekoliko godina. Kad ce se dostici granica ILP-a? Uvek se tvrdi da je taj i taj procesor dostigao zid ILP-a, ali se isto tako uvek pojavi procesor koji pokaze da to nije tako (bas kao Conroe). Cinjenica je da inzinjeri jos uvek nije ponestalo ideja i da ce uspeti da jos malo paralelizma izvuku hardverski. Kao sto sam gore napisao, o prefetcherima se ne prica puno ali tu ima dosta mesta za unapredjivanje. Po intelovim podacima, indirect branch prediction je na 75% tacnosti - i tu moze bolje. Takodje su zanimljivi AMD-ovi patenti za L0 instruction cache i "go both ways before deciding" branch prediction. Dobro znaju Intelovi i AMD-ovi inzinjeri gde su uska grla i sta jos treba popraviti.
Sto mislis da ne moze da se poveca ILP. Evo, primera radi Alpha EV8 8-wide issue wide sa svojih 8 integer jedinica i 4 floating point. Pored toga je 4 SMT ! To je zaista impresivan procesor. Sto ne bi mogao da se prosiri i x86 egzekucioni core ? Ostaje pitanje samo, na koliko bi Mhz mogao da radi takav CPU i ono najvaznije, koliko bi to trosilo !
🙂
Jednostavno ne zavise sve performanse od prefetchera i rada sa memorijom. Mnogo toga zavisi i od sirove snage. K8L ce biti verovatno, mnogo veca "sirovina" nego sto je to K8, ali da bi to sve "pilo vodu", mora se poboljsati i front end procesora, cache, prefetcheri, BPU itd...
Prefetcher, koliko mi se cini nisu prakticno menjali jos od Palomino CPU-a, osim dodavanja nesto TLB-ova. Prve K7 verzije nisu ni imale hardverski prefetcher, a ovaj koji poseduje K8 je verovatno, rudimentaran!
BPU, je takodje vrlo slican i rudimentaran kao kod K7, a i K6, s' tom razlikom sto je branch history table povecan na 16K. Reverse Branch Prediction zvuci vrlo zanimljivo, ali za sada jako malo podataka ima o tome.
Sto se tice povecanog decoding bandwidth-a, mislim da bi on uticao pozitivno i na integer performanse.
Pricu oko shareovanog L0 cachea, dvostrukog pipeline-a itd... sam citao davno, jos pre izlaska K8 procesora, negde jos 2002.
