audiofreak je napisao(la):
Pusti ga illidane vidis da je beyond help.
Imas tri odgovora na pitanje:
1. Netburst je doneo najbolji branch predictor, odlican cache i prefetch mehanizme, i sjajne SSE2 instrukcije. Pokazao je da se i sa izuzetno dugackim pajplajnom moze napraviti tako komplikovan superskalaran OOO procesor. Ti bi stvarno mogao malo dublje da zagrebes od one praistorijske 5 stage RISC arhitekture koju si ucio na faxu pa bi ti neke stvari u vezi arhitekture procesora bile daleko jasnije.
2. Netburst je zbog SIMD koncepta naterao (pametne) programere i softverske firme da promene nacin rada i da optimizaciju koda i algoritama shvate onako kako treba -- ozbiljno. Zbog toga smo dobili mnogo brzi Photoshop, Lightwave, SoundForge, Sonar, Cubase, 7-Zip, WinRAR, you name it, a ne zbog K8.
3. Netburst je, hteo to ti da priznas ili ne doneo multithreading na desktop, a ne tamo neki K8.
Sve je to lepa priča, ali nije baš tako.
1. Šta ste se uvatili predikcije grananja kao da je ona sve i svja. Nije Intel prvi koji je otkrio čari pumpanja takta rastezanjem pipelinea, DEC je bio prvi u tome sa Alphom (malecan direktno mapiran instrukcijski keš, in order izvršavanje i eto 300 i 500 MHz, jedino što onda procesor na 2x nižem taktu i 2x manjim teorijskim performansama bude brži u SPEC benchmarcima). Sve te razne napredne tehnike što spominješ su samo u službi bržeg čitanja i dekodiranja instrukcija koje se iovako posle izvršavaju na RISColikom jezgru.
Što je pipeline duži to je veća latencija instrukcija, a da bi se sakrila ta latencija treba da imaš što više nezavisnih instrukcija koje nisu međuzavisne po podacima, odakle sledi da ti treba puno puno registara. x86 je tu uvek bio na začelju. Takođe, integer programi imaju neuporedivo manji stepen paralelizma od fp programa pa su razne tehnike tipa loop unrolling daleko manje uspešne, ali da ne zalaizim previše u domen kompajlera.
Ti bi inače mogao da malo bolje prostudiraš tu
organizaciju procesora i da naučiš da razlikuješ organizaciju od arhitekture.
Sjajne SSE2 instrukcije su daleko od sjajnih. Jedan od većih gafova: svega 8 registara. Zatim, tvrdoglavo insistiranje na 2 adresnom formatu. Zatim mali broj elemnata u registru, za double brojeve svega 2. Sa SSE instrukcijama više je stvar da se ne koristi retardirani FPU sa stekom i tim divotama koji jednostavno nije pravljen za brzo izvršavanje instrukcija i koji je bio sve osim pogodan za primenu tehnika za optimizaciju petlji. Sem toga, meni na pamet ne pada nijedan razlog zašto praktično samo x86 procesori nisu mogli da urade fp add ili fp mul u 3-4 ciklusa sa repeat rateom 1. Svi RISC procesori su to savladali pre više od 10 godina (MIPS, PA-RISC, POWER, Alpha).
2. Slavne optimizacije koje spominju uglavnom ljudi koji nisu programeri i koji nemaju nikakvo iskustvo sa Intelovim C i Fortran kompajlerima. Vektorizacija koda je bajata stvar, a Intel je pametno kupio firmu KAI koja je imala neke od najboljih optimizujućih i vektorizujućih kompajlera (između ostalog pravili ih i za razne Cray mašine gde bez vektorizacije ne može ni u WC da se ode
😀 ). KAI inače znači Kuck and Asociates Inc, a dotični Kuck je pre 30 i kusur godina radio na vetorizaciji koda i imao verovatno najbolji tim na svetu; ovo čisto za one koji nisu čuli za tu firmu pa da se ne pitaju koji su ti levaci. ,) Svaki kod koji je pristojno pisan i poseduje paralelizam može se relativno lako vektorizovati. Ako paralelizma nema, ništa od bilo kakvih SIMD instrukcija, a često ništa ni od korišćenja paralelizma od superskalara. Plus standardne biblioteke kao što su BLAS 1/2/3, LAPACK, ATLAS i Intelove tipa IPP i MKL. Inaše dotična MKL biblioteka sadrži optimizovan BLAS i LAPACK za sve Intelove procesore i pri tome košta nešto smešno malo. Primer iz prakse: program pisan u čistom i standardnom Cu, samo preveden za SSE (čak ne ni SSE2) pri čemu je ograničen uglavnom brzinom memorije radio je 10-15% brže od ne-SSE verzije.
Inače, Netburst nije produkt marketinga, već činjenice da se performanse procesora mogu poboljšati na 2 načina: povećavanjem broja instrukcija izvršenih u ciklusu i dizanjem takta. Intel se odlučio na ovo drugo jer se lakše može proceniti dokle će to stići što se tiče takta. Sa druge strane, dizanje broja instrukcija po taktu zahteva daleko veće resurse i usporava takt, a koliko če biti ukupno ubrzanje (više instrukcija po ciklusu, a sporiji takt) je teško proceniti dok procesor nije dobrim delom urađen (da su probali tako i zeznuli se mogli bi da bace 1-2 godine rada gomile inženjera). A svo vreme kamn o vratu je x86, a najveći od svih mali broj registara i FPU stek.
