Prescott: a következő generációs Pentium 4
Jelentkezz be a hozzászóláshoz.
"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....
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....
#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 ( 😄 ), 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!
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 ( 😄 ), 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!
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!
"Ui.: Hi, Supergamer (a valódi), nagyon beindultunk 😉"
😊 Ez van, jolesik hozzaertokkel beszelgetni.
😊 Ez van, jolesik hozzaertokkel beszelgetni.
#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 😉
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 😉
"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.
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.
#16
NASAtm, ide is beírhatnád...
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.
#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...
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...
#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...
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...
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.
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.
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.
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.
"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.
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.