[bogdan]

erdekes lehet vegiggondolni azt, hogy ha az AMD akar ma is bevezethetne a 65 nanos gyartast (kedvencem a felteteles univerzumok tipusu gondolkodas ), akkor milyen uzletpolitikat folytatna.

szamomra egyertelmu, hogy holnap meg ekkor sem jonnenek a 65 nanos processzorok, hiszen a biztos de stabil novekedes sok szempontbol jobb, raadasul MA hatarozottan jobb meg mindig az AMD, meg a 65 nanos p4 verziokkal szemben is. hova kapkodjon? oszre, ha jon a Conroe-Woodcrest mar el lehet gondolkodni, hogy akkor porgessek-e meg 65 nanon a frekvenciat, vagy inkabb varjanak egy kicsit (mondvan fel ev nem nagy ido, inkabb dobbantsunk nagyobbat) a quad core -ig.

az mindenkeppen latszik, hogy az AMD nagyon ugyes politizalassal tompitja az Intel eredmenyeit: 2.6GHz az IDF napjara, AM2 es DDR2 a kovetkezo generacios processzorokkal szemben.. nem nagyokat lep elore, de mint technologiai folenyben levo ezeket jol es jokor teszi.

[special]

Idézet: Asker - Dátum: 2006. márc. 8., szerda - 15:20

Akkor csak jól sejtettem vmit. 

ha megnézed a pentium m-teszteket, akkor láthatod, hogy az fp-teljesítmény nem korrelál valami jól, mondhatni sehogysem a játékokkal mért benchmarkokkal. magyarán lehet a játék kódjának túlnyomó többsége lebegõpöttyös, valami miatt az erõsebb architektúra nem tudja kifutni magát. én elsõsorban alacsony ILP-re tippelnék, azaz a végrehajtóegységek kihasználtsága botrányos.

[Asker]

Idézet: Asker - Dátum: 2006. Mar. 8., Wednesday - 10:51

hmm, nekem egy kicsit zavaros ez.
a conroe elpicsázza a "teszt" szerint az X2est 2,66 GHzen.

Nos itt meg 3ghzes woodcrest van 2,4 es opteron ellen és up to 33 percentet mondanak.
Ha 3 ghzre számoljuk az opteront és hozzáveszszük a AM2õt akkor ????

ez csak nekem tûnt fel?

[Zollka]

Idézet: Laa-Yosh - Dátum: 2006. márc. 8., szerda - 15:01

Khm, a játékokban maga a game kód, tehát a feltételvizsgálatos-elágazásos rész az integer. A számítások 90%-a viszont lebegõpontos, akárcsak a 3D grafikában manapság gyakorlatilag már minden.
Az egy más kérdés, hogy egyre kevesebb számítást bíznak a játékokban a procira, a GPU shaderek fejlõdésének köszönhetõen, de azért ütközéstesztek, fizikai szimulációk, AI raycasting (Halo esetében az AI számítások kb. 80%-a) meg egyebek igenis FP-igényes CPU feladatok...

Ami leginkább fp az a MI és ilyesmik nem? Namost ettõl nem lesz több frame/sec egy játék....Nomeg szerintem semmiféle 3D-s cucc nincs már a procik hátán mert szinte mindent a VGA csinál ,szal még mindig kell a böszme fp ahhoz ,hogy sok frame/sec legyen egy játék? Én azt gondoltam ,hogy az általad is írt integer rész az ami korlátoz...Akkor viszont a K8L nagyot üthet desktopon is...

[special]

Idézet: Zollka - Dátum: 2006. márc. 8., szerda - 14:07

..A másik dolog pedig ,hogy igazából szerintem nem lesz képes a Conroe akkora órajelet elérni mint az A64...

Meglepõdnék. A Conroe és barátai életútjuk elején járnak, ráadásul viszonylag új gyártási eljáráson. A tanulási görbe itt is mûködik: az idõ haladtával, fõleg a tömegtermelés beindulását követõen halmozódó tapasztalatok, finomhangolás révén gyorsabb változatok piacra dobását is lehetõvé teszik majd. Ezt látjuk hiszen a  90 nm K8 chipek esetében is. A Core-ok hosszabb, több fokozatû futószalagjai pedig arra utalnak, hogy magasabb órajeltartományt is képes produkálni a logika, mint a K8, bár kétségtelenül agresszívabb ütemezést alkalmaz.

Arról sem kellene megfeledkezni, hogy a normál Conroe TDP-je csak 65 watt, ami kb. 75-80 watt "AMD-snek" felel meg . Ha kard-ki-kardot  akar játszani az Intel, akkor bevezethet egy jobban eleresztett sorozatot, mondjuk 10-20 százalékkal magasabb órajelen. Errõl van is pletyka, valami Conroe XE néven fut, 3 GHz-es órajellel. Kezdetben. Ehhez vedd hozzá, hogy azonos órajelen sokmindenben verni fogja a K8-akat, az F-revíziót is.

Mondjuk a csúcsváltozatokról beszélünk, a piacot azonban inkább az alsó- és középmezõny mozgatja.

[special]

Idézet: Zollka - Dátum: 2006. márc. 8., szerda - 16:52

Akkor viszont a K8L nagyot üthet desktopon is...

mert, mi a K8L? ha tudja valaki, árulja már el. szerintem ez a mobilverzió lesz. vagy így jelölik gyûjtõnéven a különféle reveket?

mindegy. a nagy lebegõpontos kapacitás nem igazán fordítódik játék alatt teljesítménnyé, legalábbis a tesztek ezt mutatják.

[bogdan]

Idézet: special - Dátum: 2006. márc. 8., szerda - 18:16

A Conroe és barátai életútjuk elején járnak, ráadásul viszonylag új gyártási eljáráson.

igaz, de azonos gyartasi modszereken az AMD/IBM eloljar es elol fog jarni az Intelhez kepest. igy mar valoban lehet feltetelezni, hogy esetleg jobban tud skalazodni. (persze ertelmes korulmenyek kozott, akkor ertelmezve, amikor mindket process es architektura piacon van.) tehat 65 nanon ertelmezve Zollka allitasat nem is annyira keptelen. (bar en sem ertenek vele mindenben egyet.)

Idézet

Arról sem kellene megfeledkezni, hogy a normál Conroe TDP-je csak 65 watt, ami kb. 75-80 watt "AMD-snek" felel meg .

eddig inkabb az latszott, hogy a konverzio inkabb egy 1.4x szorzonak felel meg, azaz ez inkabb 90W. ami az AMD 95W-hoz kepest meresi hiba. (plane, ha az IMC-t is belevesszuk a kepbe..)

Idézet

Ha kard-ki-kardot  akar játszani az Intel, akkor bevezethet egy jobban eleresztett sorozatot, mondjuk 10-20 százalékkal magasabb órajelen. Errõl van is pletyka, valami Conroe XE néven fut, 3 GHz-es órajellel. Kezdetben.

amihez "ma" az AMD 2.8-as DC-t rak, az ev vegere meg 3.0-t? (110-120W TDP-vel ovkorz..)

[bogdan]

Idézet: special - Dátum: 2006. márc. 8., szerda - 18:18

mert, mi a K8L? ha tudja valaki, árulja már el.

hogyne, az a Messias! 2-3 ezer eve meg Konyvet irtak a hasonlokrol!

[special]

Idézet: bogdan - Dátum: 2006. márc. 8., szerda - 17:38

eddig inkabb az latszott, hogy a konverzio inkabb egy 1.4x szorzonak felel meg, azaz ez inkabb 90W. ami az AMD 95W-hoz kepest meresi hiba. (plane, ha az IMC-t is belevesszuk a kepbe..)

ezt az 1,4-es szorzót erõs túlzásnak érzem. chiprõl chipre változik az elektronikai peak, és az empirikus közti arány, de jellemzõen 15-30 százalék között mozog az általam eddig látott adatok alapján.

Idézet

amihez "ma" az AMD 2.8-as DC-t rak, az ev vegere meg 3.0-t? (110-120W TDP-vel ovkorz..)

és clock-to-clock szépen kikap mindenben az eddigiek alapján.

[Asker]

Szvsz elég erõs bennem az az érzés hogy leginkább az 1 ciklusos throughput SSE miatt hasít így a Conroe. ami eddig 2 ciklusnyi volt és így effektíve megduplázódótt.

Szerkesztette: Asker 2006. 03. 08. 18:32 -kor

[Laa-Yosh]

Sztem meg az, hogy a kiemelkedõen magas FP teljesítmény nem jelent elõnyt, még nem egyenlõ azzal, hogy nincs rá szükség. Elég összetett rendszerek ezek, valszleg a cache/FSB körül van egypár különbözõ kaliberû szûk keresztmetszet; de igenis kell FP kód a játékokhoz és igenis marha sok mindent még mindig a CPU csinál...

[bogdan]

Idézet: special - Dátum: 2006. márc. 8., szerda - 18:45

ezt az 1,4-es szorzót erõs túlzásnak érzem. chiprõl chipre változik az elektronikai peak, és az empirikus közti arány, de jellemzõen 15-30 százalék között mozog az általam eddig látott adatok alapján.

erdekes.. mik is voltak ezek az adatok??

[d n . r]

Idézet: Asker - Dátum: 2006. márc. 8., szerda - 19:30

Szvsz elég erõs bennem az az érzés hogy leginkább az 1 ciklusos throughput SSE miatt hasít így a Conroe. ami eddig 2 ciklusnyi volt és így effektíve megduplázódótt.

Hát nem tudom... Persze nem biztos, hogy jól gondolom (majd valaki megmondja, aki jobban otthon van mikroarchitekturális szinten), de elvileg az SSE-t (már csak a nevébõl következõen is) a streaming jelelgû adatfeldolgozásra találták ki, azaz amikor egymás után kell X adatot (ahol X az egy jóóó nagy szám ) áthajtani a pipeline-on. Márpedig ilyenkor akárhánylépcsõs a pipeline, ha egyszer feltöltõdött, akkor órajelenként kiköp egy eredményt. Viszont ha X egy jóóó nagy szám, akkor olyan mindegy, hogy a teljes mennyiséget X vagy pedig X+1 clock alatt dolgozta fel...

(vagy ez azt jelentette, hogy régebben _kétszer_ kellett végigmenni az adatnak az SSE pipeline-on? (mert mondjuk az nem volt elég széles, vagy valami egyéb okból) Mert akkor jogos a duplázás)

[bogdan]

inkabb azt, hogy anno 2 ciklusonkent esett ki egy adat a pipeline vegen.

[d n . r]

Idézet: bogdan - Dátum: 2006. márc. 9., csütörtök - 9:13

inkabb azt, hogy anno 2 ciklusonkent esett ki egy adat a pipeline vegen.

Igen, de erre írtam, hogyha X adat jön (és X jó nagy szám), akkor ennek nincs sok jelentõsége

(hiszen a pipeline végén _minden_ clockra kiesik egy adat (épp ez a lényege) hogy 1 vagy 2 clock, ami "utazással" telik, annak csak a feltöltéskor van jeletõsége)

[alvaro]

Idézet: d n . r - Dátum: 2006. márc. 9., csütörtök - 9:28

Igen, de erre írtam, hogyha X adat jön (és X jó nagy szám), akkor ennek nincs sok jelentõsége

(hiszen a pipeline végén _minden_ clockra kiesik egy adat (épp ez a lényege) hogy 1 vagy 2 clock, ami "utazással" telik, annak csak a feltöltéskor van jeletõsége)

Nem-nem, éppen hogy arról van szó, hogy ezzel tényleg minden órajelkor kiesik egy adat a pipeline végén, mert a latencyjük az eddig se meg most se 1 ciklus szerintem.

[d n . r]

Idézet: alvaro - Dátum: 2006. márc. 9., csütörtök - 11:01

Nem-nem, éppen hogy arról van szó, hogy ezzel tényleg minden órajelkor kiesik egy adat a pipeline végén, mert a latencyjük az eddig se meg most se 1 ciklus szerintem.

Csakhogy _streaming_nél nincs latency! Éppen ez a lényege!

[bogdan]

Idézet: d n . r - Dátum: 2006. márc. 9., csütörtök - 10:28

hiszen a pipeline végén _minden_ clockra kiesik egy adat

mondom kettore! ott van, abban, amit ideztel tolem!
(persze boszen kevered a pipeline ciklust es a clock-ot! fel sem merult benned, hogy a ketto nem feltetlenul azonos?)

(latency meg van, ne beszelj butasagokat! pont a pipeline hossza a latency..)

Szerkesztette: bogdan 2006. 03. 09. 10:14 -kor

[d n . r]

Idézet: bogdan - Dátum: 2006. márc. 9., csütörtök - 11:12

(latency meg van, ne beszelj butasagokat! pont a pipeline hossza a latency..)

?

_Folyamatos_ az adatáramlás

(azaz arról beszélek, amikor a pipeline folymatosan mûködik, és ezért fontos, hogy X elég nagy legyen)

[bogdan]

en is. miben mond ez ellent a latency-nek? (a masik problemat sikerult legalabb megertened? )

Szerkesztette: bogdan 2006. 03. 09. 10:19 -kor