Koliko mi je poznato formalni argument je sledeci:
IPC je tesko dostizan i nepredvidljiv. Posle odredjene granice za ulozene tranzistore se dobija neproporcijalno mali dobitak IPC-a. Zbog toga je bolje ostaviti IPC na razumnom nivou gde se svi ulozeni tranzistori isplate, a ukupne performanse procesora podizati radnim taktom. Sam radni takt bi se mogao lakse regulisati nego IPC i to produbljivanjem pipeline-a i usavrsavanjem prizvodnog proseca.
To uopste nema veze sa zivotom. Opsta ideologija Netbursta nije samo dizanje takta niti produzavanje pipeline-a. Osnovni koncept te arhitekture je
efikasan streaming (podataka) i paralelna obrada preko SIMD-a. To je nazalost jako kasno pocelo da se koristi u softveru, tako da je Netburst ni kriv ni duzan okarakterisan kao izuzetno neefikasna arhitektura, a kao glavni krivac za to "novinari" (inace "strucnjaci" za tu temu) su navodili to o cemu ti pricas -- takt i dugacak pipeline.
Druga stvar koja je iskakala iz cele price je bio trace cache koji je bio prilicno inovativan koncept u 2000-toj godini i pokazao se vrlo sposobnim da odrzi visok instruction decoding throughput. Treca stvar je implementacija HTT preko uop tagging-a (jedan decoder i front end koji taguje instrukcije za core0/core1), a cetvrta replay, ali ne onakav kako ga ti zamisljas.
Da, ideja je da dva ALU-a na dva puta vecem taktu efektivno izgledaju kao 4 ALU-a za ostatak procesora.
Ne, ideja je bila da pola takta kasnije mozes zapoceti drugu polovinu neke operacije (npr drugih 16 bita od 32-bitnog mnozenja ili drugih 32-bita od 64-bitnog ADD/SUB) pa je na taj nacin ALU izgledao 2x siri, a ne 2x brojniji.
Veci deo kapaciteta Double Pumped ALU-a odlazi na lanac replay instrukcija, pa kad se sve sabere i oduzme one se ne ponasaju mnogo bolje od obicnih ALU-a.
Ovde vec pocinjes da diskutujes o stvarima o kojima ja znam mnogo vise. Ne znam gde si to procitao, ali ja iz prakse mogu da tvrdim da to nije tako kod optimizovanog softvera.
Samo je arhitektonski register file bio dupliran. Njega cine nespekulativna stanja arhitektonskih registara. Mnogo veci renamed register file koji cine spekulativna stanja registara je deljen.
Naravno, zato sam i rekao da bi 5% ostalo 5% i pored smanjenja proisteklog iz procesa jer je i RAT (Register Alias Table se zove to sto pominjes, a ne renamed register file) verovatno adekvatno uvecan na C2D.
Ukoliko procesor ima bar jednu fazu pipeline-a izmedju schedule i execute on mora da ima replay mehanizam inace procesor uopste ne moze da funkcionise.
To nije replay kakav je imao Netburst.
Video sam to jako davno i poslao im email u kome sam tvrdio da nije tacno da se replay ne pominje u dokumentaciji i trazio da to isprave u tekstu. Naravno, nisu mi nikad odgovorili. Ceo tekst je senzacionalisticki i u fazonu "Sta X ne zeli da znate o Y".
Prvo, nigde nisu navedeni nikakvi konkretni podaci o uticaju replay-a na performanse (na primer izmeren procenat CPU taktova potrosen na Replay uz pomoc performance countera), samo spekulacije.
Drugo, evo ti primer lose osmisljenog testa:
http://www.xbitlabs.com/articles/cpu/display/replay_15.html#sect0
Razlog zasto jedan thread usporava nije replay uopsteno, vec Load Replay. Ukoliko se citanje ponavlja u brzoj petlji koja nema dovoljno koda sa vecom latencijom da pokrije to citanje pre nastupanje sledece iteracije petlje (kao na primer kada testiras sinhronizacionu varijablu), procesor (bejavsi deep-out-of-order-execution engine) spekulativno salje na izvrsavanje nekoliko narednih load instrukcija iz nekoliko buducih iteracija petlje.
Posto je ovde u pitanju random citanje iz memorije veliko je opterecenje na AGU (Address Generation Unit), hardverski prefetcher koji pomaze kod linearnog pristupa memoriji je beskoristan pa cak i stetan samim tim cache miss je neizbezan, a kao kombinovana posledica svega toga javlja se Load Replay pa performanse padaju u drugom threadu. Samo jedna pause instrukcija pre citanja iz memorije bi verovatno bila dovoljna da se skoro u potpunosti eliminise taj penal.
A upravo DP ALU-i amortizuju ovaj „unjustified waste of resources and significant performance drops”.
To oni tek treba da dokazu real-world testom, umesto lose osmisljenom sintetikom, a ti bi morao biti malo vise analitican i sumnjicav kad se vec upustas u sve to.
Na osnovu mog iskustva, Netburst (pa cak i Prescott) je bio izuzetno efikasna arhitektura kad je u pitanju streaming i SIMD. Kod koji sam optimizovao za njih radio je u nekim slucajevima cak i do 20% brze, a nikad sporije nego na uporedivim AMD procesorima. Kad kazem uporedivim, mislim na recimo AMD64 2800+ i Prescott 2.8GHz oba na default taktu onako kako ih ozbiljni klijenti koriste.
Da ne idemo vise u off, cela ta prica oko neefikasnosti Netbursta je prenaduvana, a lansirali su je aljkavi developeri da bi imali pokrice za svoj bedan legacy kod.
