27
-
Supergamer_real #27 "Az EV8 8 utas processzor lett volna és hasított volna rendesen. Az Intel nemhiába vette meg, hisz a McKinley/Madison-t
lenyomta volna."
Az EV8 4 utas - lasd a tavalyi Mikroprocessor forum anyagat vagy a compaq weboldalat - lett voltna es szinten SMT-t alkalmaztak volna benne.A 4utas termeszetesen az SMTre vonatkozik, azt hittem ez nyilvanvalo.... -
Rive #25 Hm... Hihi... Mégis mindenki a Cl2-t választja, ha teheti ;)
A várakozási ídő megfelelő dimenzióba helyezéséhez pedig képzeljünk el egy rosszul optimalizált ciklust, ami egy DivX film minden egyes pixelére vár 100 utasításnyi fölösleget ;)
Egyébként, a viccet félretéve, valóban nem túl egyszerű a dolog.
A sávszélesség növekedése ellenére a processzornak minden cache-miss esetén meg kell várnia, amíg a memória feltölti a teljes cacheline-t.
Mért adatok: http://www.hwsw.hu/perl/ultimatebb.cgi?ubb=get_topic&f=1&t=002202
Azaz, Tbird, 64Byte cacheline, DDR, a latency 150 órajel, ca. 200 utasítás...
P4: 350 órajel, ca. 400 utasítás, bár ez SD-RAM :(
Ha átlag 10-es szorzót veszünk ( :D ), akkor a chipset-latency kiiktatásával a TBird ca. 20 utasítást spórol. Ahhoz, hogy ezt FSB emeléssel be lehessen hozni, a 266 helyett 300 kellene... A Hammer valószínűleg eleve a 333-as ramokat támogat majd...
Vigyázat! Ez azért nem ennyire egyszerű. Elég sok helyen bele lehet kötni (jogosan), de a tendenciát jól mutatja... Kéretik az egészet tájékoztató jellegűnek tekinteni! -
Supergamer_real #24 Ez a kerdes ennel joval osszetettebb.Most sajnos nincs idom megmagyarazni miert... kesobb (de talan Rivenak van egy kis "szabad ideje". -
#22
enyhén misztikussá vált Yamhill technológiát is beveti majd a Prescott esetében. Amennyiben egyébként erre ténylegesen sor kerül majd, a processzormag mérete mindössze 2 százalékkal fog növekedni - A Yamhill az intel szónok szerint nem 32/64es proci, hanem más gyártástechnológia - és én ebből is ezt olvasom ki! -
Supergamer_real #20 "Ui.: Hi, Supergamer (a valódi), nagyon beindultunk ;)"
:) Ez van, jolesik hozzaertokkel beszelgetni. -
Rive #19 >> negyutas processor eseteben a 0.8-2.3 orajelet tudunk atlagosan elerni.
Hozzá kell tenni, hogy a második érték az leginkább a kézzel optimalizált programokra vonatkozik, a standard C fordítók átlag 1.5 körüli értékeket produkálnak.
Ez azért is érdekes, mert ugye átlagosan a programok minden ötödik utasítása elágazás. A branch-predict ezek jelentős részét megjósolja, de pl. a P4 90%-os eredményességénél minden 33. órajel egy pipeline-ürítést hoz... Ugyanakkor a pipe hossza >20, legalább 30 utasítás megy a szemétbe...
Alighogy teleszalad utasításokkal, már lehet is kidobni az egészet...
Az Athlon sorozatban az eredményesség valahol 95%-nál jár, a pipe tfh. 10 lépcső: minden 60 órajel hoz pipe ürítést, aholis 'csak' 15 utasítást kell 'dobni'...
A pontos adatokat mindenki helyettesítse be magának, csak a trendekre szerettem volna rávilágítani ;)
Ui.: Hi, Supergamer (a valódi), nagyon beindultunk ;) -
Supergamer_real #17 "alatt a CPU nem csak egy utasítást hajtana végre"
Ehhez egy kis adalek.Bar kisse meglepo elofordulhat (es elo is fodul), hogy akar egy olyan "egyszeru" kalkulaciot mint a 2*2 sem kepes a processor egyetlen orajel alatt elvegezni.Hozza kell tennem ez sok minden mason is mulik.
Az intel eseteben (HT) 2utas megoldasrol beszelhetunk.Mai processoroknal negyutas processor eseteben a 0.8-2.3 orajelet tudunk atlagosan elerni.Ez egy atlagos processorra igaz.A fennmarado 3.2-1.7 utasitas horizontalis veszteseg.Ezeket illetve a vertikalis vesztesegeket lehet kikuszobolni a kulonbozo multi-threading eljarasokkal.
Az intelfanoknak - akiket altalaban eddig nem erdekelnek a reszletek , tisztelet a kivetelnek - mindenkeppen emlitesre melto, hogy a iNTEL processora az elso (inkabb az egyik elso) a szimultan tobbszalas megoldasok kozul.Ez a multithreading talan legnehezebben megvalosithato valtozata (idaig) . A compaq leallt a 4 utas (! - mind az intele es a Sun-e 2 utas) EV821464 alpha fejlesztesevel.A Sun mar publikalta a dokumentaciojat a sajat megoldasanak igy hamaroosan ez a processor is "elerheto" lesz.
-
Rive #16 NASAtm, ide is beírhatnád... -
Supergamer-real #15 Nagyon jó irányban halad az Intel csak gratulálni tudok hozzá. Azért jó lenne ha már az 1E-11111... mikronnál járnának ezek az okos gyerekek, hogy végre tényleg lenyomják az amd-t. -
Rive #14 Továbbiak.
A mai rendszer-tervezés során a kritikus kérdés a processzorok ellátása megfelelő mennyiségű adattal. Ebbe csak besegít a cache, de nem képes megoldani a problémákat: jelenleg az a max. 2-3 megabyte, amit a cache kezelni képes, csak a legfontosabb adatok (a kód is adat) elérését képes meggyorsítani. Ennél egy egyszerű program is nagyságrendekkel nagyobb memóriát igényelhet...
A gondok hatványozottan jelentkeznek akkor, ha a fizikai memória nem csak egy processzort szolgál ki. Ekkor ugyanis a maximális sávszélesség töredéke jut az egyes processzorokra, behatárolva ezzel az elérhető teljesítményt.
Hasonló gondokat okoz a memória késleltetése is. Gondoljunk bele: a memória sebessége (DDR) 200MHz, a processzoré 2GHz. Amíg a memóriából megérkezik az adat, addigra 8-9 FSB órajelis eltelhet: ez 80-90 CPU órajelet jelent, és tekintve, hogy egy órajel alatt a CPU nem csak egy utasítást hajtana végre, a fizikai memória elérése minden további nélkül okozhat 100-150 utasításnyi késleltetést.
Ennek a lecsökkentésére szolgál a prefetch: ez azonban csak néhány CPU-órajelnyi időt nyer, hiszen a jóslás már csak az utasítás végrehajtásának megkezdése után történhet meg.
Megoldás lehet a többszálúság bevezetése, hiszen ekkor a külső adatra várakozó szál helyett egy olyan fog futni, amelyiknek minden adat a rendelkezésére áll. Ennek a módszernek az alkalmazása megkívánja a cache méretének növelését, tehát drága... Ugyanakkor, pont azokon a helyeken mond totális csődöt, ahol az extra teljesítményre szükség lenne: azokat a rutinokat, amelyeknek _igazán_ gyorsan kell lefutniuk, ma is kézzel optimalizálják, és bizony ügyelnek mind a futószalag maximális kitöltöttségére, mind a SW prefetchre...
A harmadik lehetőség a memória késleltetésének csökkentése: ha a chipset késleltetése kimarad, máris nyertünk 20-30 utasításnyi időt...
Az Intel az első két megoldást preferálja, az AMD az elsőt és az utolsót: verseny végére, ahogy Supergamer mondta, valóban nem érdemes tippelni, nagyon kétesélyes, és nem csak a memóriával kapcsolatos ügyek miatt... -
Rive #13 Néhány adalék.
A nagy cache nem olcsó mulatság. Egyrészt a gyors statikus RAM cellák is sok tranzisztort igényelnek -> zabálják a helyet a magon. Másrészt, a memória csak a dolgok egyszerűbb része.
A processzornak számon kell tartania, hogy a cache a fizikai memóriának melyik részeit tárolja, és az adatbetöltés során _nagyon_ gyorsan meg kell találnia, hogy melyik cache-beli területről kell olvasnia az adatot- ha egyáltalán a cache-ban megtalálható a kért információ...
Erre a feladatra un. asszociatív tárakat használnak: ezeknek a lényege az, hogy egy bejövő adatot (tárcím) egyidőben összehasonlít a tárolt adatok mindegyikével. Ha egyezést talál, akkor cache-hit van, a cache-beli cím rendelkezésre áll.
Egy ilyen asszociatív tár gyakorlatilag n darab teljes komparátorból áll, nagyon komoly a tranzisztor-igénye. Emiatt az L1 cache számára csinálnak csak gyors címvizsgálatot, az L2 kénytelen beérni többlépcsős, lassabb megoldásokkal. Ezekhez járul még a cache tartalmának validálásához, és a használat gyakoriságának nyilvántartásához szükséges logika...
Emiatt az L1, L2 (L3) cache méretét financiális és teljesítménybeli szempontok együttese határozza meg: a kész megoldás általában egy 'megfelelő' kompromisszum a sebesség és az ár között.
A nagméretű cache valamelyest tehermentesíti az FSB-t, így nyílt lehetőség a HW-prefetch megvalósítására. Ez a feldolgozás alatt levő utasítássor alapján próbálja megjósolni a szükséges adatokat, és azokat betölti a cache-be. Megjegyzendő, hogy ennek a technikának a SW változata már viszonylag régóta létezik az X86-os processzorok között, csak általában nem fordítanak rá elegendő figyelmet, pedig...
-
Supergamer_real #12 Na tehat.Az L1 cache novelese nem egyertelmuen es kizarolag az oka az Athlon "folenyenek".Az esetek nagyreszeben ugyan igaz, de ha ez olyan nagyon nagy elony lenne a P4nel akkor mar regota nagyobb cache merettel arulna az iNTEL a procijait.
Tobbek kozott a multi-threading (az intel a sajat multi threading eljarasat hivja hyper threadingnek) miatt az intel akozeljovoben "kenytelen lesz" megnovelni az L1es cache meretet processorain mert a szimultan tobbszalas eljarasok egyik hatulutoje, hogy a tobbszalas vegrehajtas miatt megnovekedik az ugraselorejelzo logika terhelese.A gyorsitotartalalatok hianya jelentos rolast okoz(hat) az L1es gyorsitotar eseteben tapasztalatok alapjan - foleg szimulacio - L2 es L3 eseteben ez nem mutathato ki.
Ehhez jon meg a p4 eseteben hosszabb pipeline es a "gyengebb" ugraselorejezlo logika.Mindezek ellenere nem tudom feltunt-e de a iNTEL kezdte el Xeonokba illo L2 cache merettel arulni a procijait.(Legalabbis 512k par evvel ezelott meg csak ott volt divat).
Az iNTEL procik ezenfelul el vannak latva hardveres pre-fetchel is ami a fennmarado FSB-t hasznalja a kovetkezo feltetelezett kert adat megjosolasara.Ezt a logika bekeri az L1es cachebe.Ez meg egy ok amiert az iNTELnek valoban az L1re kellene koncentralnia.Bar az FSB novelesevel elvileg a pre-fetch unit novelhet a processor sebessegen ( megnovekedett FSB miatt valamennyivel tobb jut a PF unitnak).
/Mellekesen megjegyeznem, hogy az L1es cache integralasa messze tobb penzbe kerul mint az L2-e es az iNTEL procikban tobb L2van es kevesebb L1 es megis az AMD az olcsobb/
Arrol azonban, hogy melyik processor lesz a gyorsabb - megbizhato jostehetseg hianyaban - badarsag.A tenyeket le lehet irni/meg lehet vitatni de ennel tovabb menni nem erdemes mert csak AMD, iNTEL SUXolas lesz belole. -
Supergamer_real #11 Na tehat.Az L1 cache novelese nem egyertelmuen es kizarolag az oka az Athlon "folenyenek".Az esetek nagyreszeben ugyan igaz, de ha ez olyan nagyon nagy elony lenne a P4nel akkor mar regota nagyobb cache merettel arulna az iNTEL a procijait.
Tobbek kozott a multi-threading (az intel a sajat multi threading eljarasat hivja hyper threadingnek) miatt az intel akozeljovoben "kenytelen lesz" megnovelni az L1es cache meretet processorain mert a szimultan tobbszalas eljarasok egyik hatulutoje, hogy a tobbszalas vegrehajtas miatt megnovekedik az ugraselorejelzo logika terhelese.A gyorsitotartalalatok hianya jelentos rolast okoz(hat) az L1es gyorsitotar eseteben tapasztalatok alapjan - foleg szimulacio - L2 es L3 eseteben ez nem mutathato ki.
Ehhez jon meg a p4 eseteben hosszabb pipeline es a "gyengebb" ugraselorejezlo logika.Mindezek ellenere nem tudom feltunt-e de a iNTEL kezdte el Xeonokba illo L2 cache merettel arulni a procijait.(Legalabbis 512k par evvel ezelott meg csak ott volt divat).
Az iNTEL procik ezenfelul el vannak latva hardveres pre-fetchel is ami a fennmarado FSB-t hasznalja a kovetkezo feltetelezett kert adat megjosolasara.Ezt a logika bekeri az L1es cachebe.Ez meg egy ok amiert az iNTELnek valoban az L1re kellene koncentralnia.Bar az FSB novelesevel elvileg a pre-fetch unit novelhet a processor sebessegen ( megnovekedett FSB miatt valamennyivel tobb jut a PF unitnak).
/Mellekesen megjegyeznem, hogy az L1es cache integralasa messze tobb penzbe kerul mint az L2-e es az iNTEL procikban tobb L2van es kevesebb L1 es megis az AMD az olcsobb/
Arrol azonban, hogy melyik processor lesz a gyorsabb - megbizhato jostehetseg hianyaban - badarsag.A tenyeket le lehet irni/meg lehet vitatni de ennel tovabb menni nem erdemes mert csak AMD, iNTEL SUXolas lesz belole. -
Supergamer_real #10 "hiszen az AMD processzorok azért gyorsabbak a velük egy órajelen futó Intelektől, mert SOKKAL nagyobb az L1 cache-ük"
Baromsag/feligazsag.A P4nel hosszabb a pipeline.Tobb adatot tudsz ugyan betolteni, - de tobbet is kell varni a betoltes es a valos vegrehajtas kozott -, masfelol az AMD ugraselorejelzese messzemenoleg jobb mint az iNTELE.A cache novelessel sem lehet a vegtelensegig novelni egy processor sebesseget. -
#9
Jaja, én is olyan alapon tartottam "magasabb rendűnek" (pfu) az új P4-et, hogy mire megjelenik a Prescott, hol lesz már addigra a Thoroughbred? :) A telivérek most a Northwood P4-ek ellen állnak fel. A Prescott meg majd valamikor egyidőben jelenik majd meg a Clawhammerökkel, nem? -
#7
Az csak természtes szerintem, hogy ez jobb lesz egy Thoroughbred magos Athlonnál, de a Hammerekkel nagyon meg fog gyűlni a baja az iNTELnek, ha a Prescott magos P4-eket akarja ellenük hadrendbe állítani. -
#4
De mivel a Yamhill 64 bites techje nem kompatibilis az AMD x86-64-ével, ezért rendesen össze-vissza kavarná sztem a piacot, ha kijönne.