[Rive]

Huh...

Tehát, a szoftvergyártó részérõl a következõ esetek lehetségesek:

1.) Nem optimalizál.

2.) Korrektül optimalizál SSE, SSE2-re

3.) Optimalizál, de trükközik: pl. K7 esetén 3DNow-ra optimalizál SSE helyett, meg ilyenek...


A szoftver erre többféleképpen reagálhat:

a.) memória-késleltetés által korlátozott a futása: ezek általában az elsõ ponthoz tartoznak, a magam részérõl konzervatív programoknak hívom õket.

b.) Az adott architektúrán VE korlátozott a futása: ez ma csak jó minõségû SSE vagy SSE2 optimalizációval érhetõ el - DivX, rendering, stb.

c.) Memória-sávszélesség által korlátozott a futása: néha elõfordul ilyen optimalizálatlan programokkal is - pl. ha valaki belegárgyult a string-utasításokba, vagy nem hajlandó használni a DMA-t - de az ilyenek döntõ többsége valamilyen szintû SSE vagy SSE2 timalizációval bír.

d.) Az optimalizálás nem igazán sikerült, és a program úgy fut, ahogy 'kedve tartja'.

A képet bonyolítja, hogy a cache mérete mind kód, mind adat-oldalon képes beleszólni a mérhetõ teljesítménybe.

Szóval, nagyjából ezekbe a kategóriákba kellene belegyömöszölni a tesztelt programok egyes részeit, majd a processzorok órajele, memória-alrendszere alapján valószínû kiegyenesednének a dolgok.

Sajnos pillanatnyilag megfelelõ eszközök hiányában általában visszafelé, az eredményektõl a programok tulajdonságai felé vezet a következtetési út.

[Fiery]

Sajnos most atmenetileg nem tudok teszteredmenyeket kuldeni, amig nem lesz normalis RAM a gepemben (jelenleg egy 512M PC2100 figyel az alaplapban).

De egy kis erdekesseg azert igy is akad:

Q3, 640x480 16-bit Fastest (Parhelia)

DDR266 CL2.5: 240.5 FPS

DDR400 CL3.0: 266.2 FPS


Fiery

[ 2003. október 08.: Fiery szerkesztette a hozzászólást ]

[hvuk]

idézet:

---

Ezt írta Rive:
Huh...

Tehát, a szoftvergyártó részérõl a következõ esetek lehetségesek:

1.) Nem optimalizál.

2.) Korrektül optimalizál SSE, SSE2-re

3.) Optimalizál, de trükközik: pl. K7 esetén 3DNow-ra optimalizál SSE helyett, meg ilyenek...[/quote]

A 2-es és a 3-as pont esetén én némi malíciát vélek felfedezni. Én nem érzem úgy, hogy e két pont között különbség lenne, te viszont kiemeled az SSE/SSE2-õt, mint az egyedüli üdvözítõ megoldást, ellentétbe állítva a 3DNow-val, mint barkácsmegoldással. Pedig egyszerûen arról van szó, hogy a 2-es esetben csak a processzorok bizonyos részére optimalizál a programozó, míg a 3-as esetben megpróbál minden processzorhoz külön kódot létrehozni.

A másik meg, hogy nekem ez a konzervatív vs. nem konverzatív (az vajon milyen lehet? liberális? ) között minõségbeli különbséget vélek felfedezni az általad írtakban. Pedig sok esetben csak arról van szó, hogy az adott algoritmus hatékonyan nem "streamesíthetõ". Szerintem ez igaz lehet a játékokra is, mégpedig a következõk miatt:
- eddig még nem láttunk olyan játékot, ami P4-en lényegesen jobban futna, mint Athlon64-en, miközben a fordítottjára rengeteg példa van.
- A P4 lényegesen jobban teljesít a stream jellegû SSE/SSE2 programok esetén, mint az A64.
- Az SSE/SSE2 már évek óta létezik, így feltehetõleg a játékszoftverekben is megjelent a hatékony implementációjuk.

Ebbõl szerintem következik, hogy a játékok döntõen nem írhatóak át stream jellegûvé, mivel már átírták volna õket, ha az lehetséges lett volna.

Ps. Mitõl van az, hogy az A64 a skalár SSE/SSE2-ben gyorsabb, mint a P4?

[Benoke]

idézet:

---

Ezt írta Fiery:
Sajnos most atmenetileg nem tudok teszteredmenyeket kuldeni, amig nem lesz normalis RAM a gepemben (jelenleg egy 512M PC2100 figyel az alaplapban).

De egy kis erdekesseg azert igy is akad:

Q3, 640x480 16-bit Fastest (Parhelia)

DDR266 CL2.5: 240.5 FPS

DDR400 CL3.0: 266.2 FPS


Fiery

[ 2003. október 08.: Fiery szerkesztette a hozzászólást ][/quote]

A setis tesztet már várom.

[Rive]

idézet:

---

Ezt írta hvuk:
A 2-es és a 3-as pont esetén én némi malíciát vélek felfedezni. Én nem érzem úgy, hogy e két pont között különbség lenne, te viszont kiemeled az SSE/SSE2-õt, mint az egyedüli üdvözítõ megoldást, ellentétbe állítva a 3DNow-val, mint barkácsmegoldással. Pedig egyszerûen arról van szó, hogy a 2-es esetben csak a processzorok bizonyos részére optimalizál a programozó, míg a 3-as esetben megpróbál minden processzorhoz külön kódot létrehozni.[/quote]

Sajnos a 3DNow a mai gépeken az elérhetõ teljesítmény tekintetében nem méltó versenytársa az SSE-nek: aki ma a 3DNow-t állítja középpontba, az azért teszi, mert nem szándéka, hogy az adott program K7/K8 alapú gépen is rendesen menjen.
Olvass vissza az elõzõ kötetbe, ha jól emlékszem T2k részletezte a Q3 grafikus motorjának optimalizációját.

idézet:

---

A másik meg, hogy nekem ez a konzervatív vs. nem konverzatív (az vajon milyen lehet? liberális? ) között minõségbeli különbséget vélek felfedezni az általad írtakban.[/quote]

???

idézet:

---

Pedig sok esetben csak arról van szó, hogy az adott algoritmus hatékonyan nem "streamesíthetõ". Szerintem ez igaz lehet a játékokra is, mégpedig a következõk miatt:
- eddig még nem láttunk olyan játékot, ami P4-en lényegesen jobban futna, mint Athlon64-en, miközben a fordítottjára rengeteg példa van.
- A P4 lényegesen jobban teljesít a stream jellegû SSE/SSE2 programok esetén, mint az A64.
- Az SSE/SSE2 már évek óta létezik, így feltehetõleg a játékszoftverekben is megjelent a hatékony implementációjuk.[/quote]

Összekevered a következtetési lánc két végét, vagy nem értem, mit szeretnél mondani.
Olvass vissza az elõzõ kötetben mit írt T2k az egyes grafikus motorok optimalizációiról!
Pillanatnyilag nincs hatékony, mindenre kiterjedõ optimalizáció ezen a téren, a fõbb játékok régebbi motorok tupírozott változatait használják.

idézet:

---

Ebbõl szerintem következik, hogy a játékok döntõen nem írhatóak át stream jellegûvé, mivel már átírták volna õket, ha az lehetséges lett volna.[/quote]

Ezt a hülyeséget hadd ne kommentáljam.
Vagy, mégis: ha kerekeim lennének, bizonyára bevásárlókocsi lennék :o
Ezt a fajta érvelést már nagyon-nagyon sokszor láttam már tudománytörténeti mûvekben...

idézet:

---

Ps. Mitõl van az, hogy az A64 a skalár SSE/SSE2-ben gyorsabb, mint a P4?[/quote]

Pontosan milyen skalár SSE-rõl beszélsz? Milyen programról van szó?

[ 2003. október 08.: Rive szerkesztette a hozzászólást ]

[hvuk]

idézet:

---

Ezt írta Rive:
Sajnos a 3DNow a mai gépeken az elérhetõ teljesítmény tekintetében nem méltó versenytársa az SSE-nek: aki ma a 3DNow-t állítja középpontba, az azért teszi, mert nem szándéka, hogy az adott program K7/K8 alapú gépen is rendesen menjen. [/quote]

Tetszik ez a hozzáállás. Akinek régi gépe van, az dögöljön meg, arra már nem is kell optimalizálni. Tehát továbbra is az állításom: felesleges különválasztani az SSE/SSE2-õt a 3DNow-tól, mert mindegyik csak egy speciális utasításkészlet és vannak processzorok, amelyek az egyiket és vannak amelyek a másikat támogatják. Eredetileg különben ezt írtad: "Optimalizál, de trükközik: pl. K7 esetén 3DNow-ra optimalizál SSE helyett, meg ilyenek...", azaz te is úûgy gondoltad, hogy nem csak 3DNow-ra, hanem arra is optimalizál a 3. esetben.

idézet:

---

Ezt írta Rive:
???[/quote]

Pedig a szóhasználat és a szöveg erre utal. Ha nem így gondoltad, akkor ok.

idézet:

---

Ezt írta Rive:
Összekevered a következtetési lánc két végét, vagy nem értem, mit szeretnél mondani.
Olvass vissza az elõzõ kötetben mit írt T2k az egyes grafikus motorok optimalizációiról!
Pillanatnyilag nincs hatékony, mindenre kiterjedõ optimalizáció ezen a téren, a fõbb játékok régebbi motorok tupírozott változatait használják. [/quote]

Olvastam amit T2K írt. De õ csak a grafikus motorról írt. És az a játékprogramnak csak egy része. Ettõl függetlenül lehet, hogy nincs igazam, ez az elkövetkezõ fél évben ki fog derülni. Az SSE amúgy hány éves technológia? 4? Az SSE2 is már van vagy 2-3 éves. A játékok a grafikus kártyák területén max. 1 év késéssel követik a fejlesztéseket, ugyanez processzortechnológiák esetén meg bõ 4 év lenne? Kötve hiszem! Szerintem a következtetésem helyes.

A következtetési lánc két végét nem kevertem össze. Abból indultam ki, hogy a programozóknak lett volna 4 évük, hogy komoly SSE optimalizációt építsenek a kódjukba (és kb. 3 évük az SSE2-re), ezt vélhetõleg meg is tették ennyi idõ alatt, igazi eredménye viszont nem látszik. Logikus a következtetés, hogy akkor az SSE/SSE2 optimalizáció nem dob annyit a játékokon, mint amennyit az a "streamesítés"-bõl következne. Ergo nem streamesítették eddig a játékokat, amibõl következik, hogy ez nagyon nehéz lehet (így nem éri meg) vagy pedig nem is lehetséges.

idézet:

---

Ezt írta Rive:
Pontosan milyen skalár SSE-rõl beszélsz? Milyen programról van szó?[/quote]

Az A64 tesztekben volt. Például [url="http://"http://aceshardware.com/read.jsp?id=60000258"]itt[/url].

[Fiery]

idézet:

---

Ezt írta hvuk:
Tetszik ez a hozzáállás. Akinek régi gépe van, az dögöljön meg, arra már nem is kell optimalizálni. Tehát továbbra is az állításom: felesleges különválasztani az SSE/SSE2-õt a 3DNow-tól, mert mindegyik csak egy speciális utasításkészlet és vannak processzorok, amelyek az egyiket és vannak amelyek a másikat támogatják. Eredetileg különben ezt írtad: "Optimalizál, de trükközik: pl. K7 esetén 3DNow-ra optimalizál SSE helyett, meg ilyenek...", azaz te is úûgy gondoltad, hogy nem csak 3DNow-ra, hanem arra is optimalizál a 3. esetben.[/quote]

No azert alljunk meg egy szora. Kepzeld magad a szoftver fejlesztok helyebe, es azonnal megerted, miert nincs ertelme 3DNow!-ra optimalizalni manapsag mar...

Leforditom: a piac 80 %-at (ha nem tobbet) uralja az Intel, aminek minden processzoraban van SSE vagy SSE2, es nincs 3DNow!; mig a kisebbsegben senyvedo AMD (kevesebb mint 20 %-os piaci reszesedes) processzorainak utolso 3 generacioja (Palomino/Tbred, Barton, K8) kepes SSE utasitasok vegrehajtasara, az utolso generacio (K8) pedig SSE2-re is.

Egyszeruen nem eri meg 3DNow!-val tokolni, nem vezet sehova. Talan a K6-2 idejeben me'g arra jo volt, hogy kicsit ellensulyozza a K6 szeria bendzsa FPU-jat, de mar az elso Athlonok idejeben sem nagyon foglalkoztak a fejlesztok a 3DNow!-val.

A regi gepeket pedig mindenki lesz*rja, es ha faj is beismerni, ez igy van rendjen, es Te is ezt csinalnad, ha komoly penzeid lennenek a fejlesztesben.


Fiery

[ 2003. október 08.: Fiery szerkesztette a hozzászólást ]

[Benoke]

idézet:

---

Ezt írta Fiery:


No azert alljunk meg egy szora. Kepzeld magad a szoftver fejlesztok helyebe, es azonnal megerted, miert nincs ertelme 3DNow!-ra optimalizalni manapsag mar...

Leforditom: a piac 80 %-at (ha nem tobbet) uralja az Intel, aminek minden processzoraban van SSE vagy SSE2, es nincs 3DNow!; mig a kisebbsegben senyvedo AMD (kevesebb mint 20 %-os piaci reszesedes) processzorainak utolso 3 generacioja (Palomino/Tbred, Barton, K8) kepes SSE utasitasok vegrehajtasara, az utolso generacio (K8) pedig SSE2-re is.

Egyszeruen nem eri meg 3DNow!-val tokolni, nem vezet sehova. Talan a K6-2 idejeben me'g arra jo volt, hogy kicsit ellensulyozza a K6 szeria bendzsa FPU-jat, de mar az elso Athlonok idejeben sem nagyon foglalkoztak a fejlesztok a 3DNow!-val.

A regi gepeket pedig mindenki lesz*rja, es ha faj is beismerni, ez igy van rendjen, es Te is ezt csinalnad, ha komoly penzeid lennenek a fejlesztesben.


Fiery

[ 2003. október 08.: Fiery szerkesztette a hozzászólást ][/quote]

Ettõl fügetlenül nekem úgy tünik mintha a K7 3DNow! -val gyorsabb lenne mint SSE -vel.
K8 nál forditva van.

[Rive]

idézet:

---

Ezt írta hvuk:
Tetszik ez a hozzáállás. Akinek régi gépe van, az dögöljön meg, arra már nem is kell optimalizálni. Tehát továbbra is az állításom: felesleges különválasztani az SSE/SSE2-õt a 3DNow-tól, mert mindegyik csak egy speciális utasításkészlet és vannak processzorok, amelyek az egyiket és vannak amelyek a másikat támogatják. Eredetileg különben ezt írtad: "Optimalizál, de trükközik: pl. K7 esetén 3DNow-ra optimalizál SSE helyett, meg ilyenek...", azaz te is úûgy gondoltad, hogy nem csak 3DNow-ra, hanem arra is optimalizál a 3. esetben.[/quote]

Kifejezetten megkérnélek, hogy olvasd el a korábbi dolgokat, különös tekintettel a Q3 és a 3DNow kapcsolatára - a trükközik kifejezetten arra vonatkozott az idézett mondatomban, hogy a program fejlesztõjének esetlegesen nem áll szándékában teljes mértékben kihasználni a rendelkezésére álló lehetõségeket egyes architektúrák esetén.

A 3DNow utasításkészlet felépítésébõl adódóan kisebb teljesítményre képes, mint az SSE: mai processzorok esetén használata hátsó szándékokat feltételez.

Modern, nagy erõforrásigényû programok esetén a régebbi architektúrákra optimalizálni felesleges: szívesen megnézném a D3-at egy P1-en, akármilyen VGA-val.
Ha az architektúra képtelen elérni a minimálisan szükséges teljesítményt, akkor felesleges rá optimalizálni.

idézet:

---

Ezt írta hvuk:
Olvastam amit T2K írt. De õ csak a grafikus motorról írt. És az a játékprogramnak csak egy része. Ettõl függetlenül lehet, hogy nincs igazam, ez az elkövetkezõ fél évben ki fog derülni. Az SSE amúgy hány éves technológia? 4? Az SSE2 is már van vagy 2-3 éves. A játékok a grafikus kártyák területén max. 1 év késéssel követik a fejlesztéseket, ugyanez processzortechnológiák esetén meg bõ 4 év lenne? Kötve hiszem! Szerintem a következtetésem helyes.[/quote]

Szerintem meg olvasd el, amit Elric írt néhány topikkal odébb: [url="http://"https://www.hwsw.hu/perl/ultimatebb.cgi?ubb=get_topic&f=5&t=000202&p=6"]https://www.hwsw.hu/...=5&t=000202&p=6[/url]

A VGA-kártyákkal kapcsolatban kérdezd meg T2k-t, a többire vonatkozóan pedig elég jól körüljártuk a témát korábban, annyi eredménnyel, hogy a D3 és a HL2 megfelelõ tesztjeiig egyikünknek se áll módjában többet mondani - a pillanatnyilag futó játékok pedig a régi motorokra épülnek, így ebben a kérdéskörben nem döntõ jelentõségûek.

idézet:

---

Ezt írta hvuk:
Az A64 tesztekben volt. Például itt.[/quote]

Ezeket átnézem holnap, de a skalár és az SSE egymás mellé helyezése az írásodban bizony nagyon komoly dolgokra enged következtetni.

Bye: Rive -> offline ... ... ...

[ 2003. október 08.: Rive szerkesztette a hozzászólást ]

[FCs]

fiery, divx?

[Fiery]

idézet:

---

Ezt írta FCs:
fiery, divx? [/quote]

Csak PC2100 memcsim van jelenleg, ezzel nincs sok ertelme tesztelni. Most vadaszok PC3700/PC4000-et, nincs valami tippetek, hol lehet ilyesmit kapni raktarrol? (**stral kivetelevel )


Fiery

[Fiery]

Athlon 64 3200+ @ 2.00 GHz, Single DDR266 CL3.0, Memspeed 1.00:

kód:

---

Memory starting address:   100000 hex...

CPU clocked at:    2000071 kHz...

Using Time Stamp Counter...

Using MMX routine where available...

Detecting caches...

----------------------------------------------------------------------<1.00>-

|64k: |Code: 2 way-set |Data: 2 way-set |

|1M:  |Code: 16way-set |Data: 16way-set |

----------------------------------------------------------------------<1.00>-



Measuring memory speed with every bytes accessed...

|Block|| Fetch code || Read data  || Write data || Move data  ||  Full load |

----------------------------------------------------------------------<1.00>-

|512: ||    26697.9 ||    24415.2 ||    15259.6 ||     8720.2 ||    40690.1 |

|1k:  ||    28484.8 ||    19871.6 ||    13560.3 ||    10053.1 ||    42196.5 |

|2k:  ||    29466.1 ||    21981.5 ||    14422.2 ||    10549.1 ||    43543.9 |

|4k:  ||    29973.4 ||    23094.5 ||    14796.7 ||    10817.3 ||    40690.1 |

|8k:  ||    30248.2 ||    23752.3 ||    15036.4 ||    10955.6 ||    40674.6 |

|16k: ||    30375.3 ||    24071.0 ||    15141.2 ||    11026.1 ||    40690.1 |

|32k: ||    30449.8 ||    24241.3 ||    15198.9 ||    11061.7 ||    40677.7 |

|64k: ||    30484.5 ||    24327.4 ||    15229.2 ||    11079.1 ||    40693.2 |

|128k:||     6274.6 ||     9194.7 ||     7622.0 ||     3839.5 ||    52018.8 |

|256k:||     6256.4 ||     8973.1 ||     7566.3 ||     3771.8 ||     9598.9 |

|512k:||     6254.0 ||     8976.7 ||     7568.5 ||     3735.2 ||     9578.3 |

|1M:  ||     6254.0 ||     8974.3 ||     7569.7 ||     3735.8 ||     9590.7 |

|2M:  ||     1301.5 ||     2002.8 ||      823.2 ||      822.5 ||     1235.6 |

|4M:  ||     1298.0 ||     1941.6 ||      824.0 ||      821.1 ||     1235.8 |

|8M:  ||     1296.2 ||     1925.0 ||      823.7 ||      819.7 ||     1225.2 |

|16M: ||     1295.5 ||     1913.7 ||      823.8 ||      820.0 ||     1222.5 |

|32M: ||     1295.4 ||     1910.2 ||      824.9 ||      819.6 ||     1220.6 |

|64M: ||     1294.7 ||     1909.1 ||      824.8 ||      819.8 ||     1219.2 |

----------------------------------------------------------------------<1.00>-

[Bytes]|  [MB/sec]  ||  [MB/sec]  ||  [MB/sec]  ||  [MB/sec]  ||  [MB/sec]  |



Measuring cacheline loading latencies/throughput...

|Block||TransferRate||    Cacheline latency     || Throughput | Granularity

----------------------------------------------------------------------<1.00>-

|512: ||   500006.8 ||        4.0 ||        2.0 ||    10172.3 |         4

|1k:  ||   499906.9 ||        4.0 ||        2.0 ||    11097.8 |         4

|2k:  ||   500006.8 ||        4.0 ||        2.0 ||    11622.2 |         4

|4k:  ||   500031.7 ||        4.0 ||        2.0 ||    11910.4 |         4

|8k:  ||   500031.7 ||        4.0 ||        2.0 ||    12056.1 |         4

|16k: ||   500006.8 ||        4.0 ||        2.0 ||    12131.8 |         4

|32k: ||   499906.9 ||        4.0 ||        2.0 ||    12169.5 |         4

|64k: ||   499881.9 ||        4.0 ||        2.0 ||    12184.1 |         4

|128k:||   111113.8 ||       18.0 ||        9.0 ||    10299.2 |        64

|256k:||   111113.8 ||       18.0 ||        9.0 ||    10301.3 |        64

|512k:||   111113.8 ||       18.0 ||        9.0 ||    10312.4 |        64

|1M:  ||   111084.2 ||       18.0 ||        9.0 ||    10295.8 |        64

|2M:  ||    16403.7 ||      121.9 ||       61.0 ||     3983.7 |       128

|4M:  ||    16369.3 ||      122.2 ||       61.1 ||     3847.4 |       128

|8M:  ||    16354.8 ||      122.3 ||       61.1 ||     3833.1 |       128

|16M: ||    16345.4 ||      122.4 ||       61.2 ||     3818.0 |       128

|32M: ||    16343.7 ||      122.4 ||       61.2 ||     3808.1 |       128

----------------------------------------------------------------------<1.00>-

[Bytes]| [kTrs/sec] || [CPU Clock]||  [nanosec] ||   [MB/sec] |   [Bytes]



Measuring latency vs. address distances (in-page vs over-page access)...

|Dist.||TransferRate||    Cacheline latency     |   Streams

----------------------------------------------------------------------<1.00>-

|128: ||    16348.8 ||      122.3 ||       61.2 |    Single

|256: ||    16030.4 ||      124.8 ||       62.4 |      Many

|512: ||    15445.4 ||      129.5 ||       64.7 |      Many

|1k:  ||    14428.7 ||      138.6 ||       69.3 |      Many

|2k:  ||    12702.5 ||      157.5 ||       78.7 |      Many

|4k:  ||    11042.7 ||      181.1 ||       90.6 |      Many

|8k:  ||    11043.5 ||      181.1 ||       90.6 |      Many

|16k: ||    11056.4 ||      180.9 ||       90.4 |      Many

|32k: ||     9366.2 ||      213.5 ||      106.8 |      Many

|64k: ||     9425.2 ||      212.2 ||      106.1 |      Many

|128k:||     9427.5 ||      212.2 ||      106.1 |       256

|256k:||     9438.3 ||      211.9 ||      106.0 |       128

|512k:||     9473.5 ||      211.1 ||      105.6 |        64

|1M:  ||     8921.4 ||      224.2 ||      112.1 |        32

|2M:  ||     8989.1 ||      222.5 ||      111.2 |        16

|4M:  ||     9138.0 ||      218.9 ||      109.4 |         8

|8M:  ||     9458.9 ||      211.4 ||      105.7 |         4

|16M: ||    10171.2 ||      196.6 ||       98.3 |         2

----------------------------------------------------------------------<1.00>-

[Bytes]| [kTrs/sec] || [CPU Clock]||  [nanosec] | StrNumber

[/code]





Fiery
						
						

						
					

[hvuk]

idézet:

---

Ezt írta Rive:
Kifejezetten megkérnélek, hogy olvasd el a korábbi dolgokat, különös tekintettel a Q3 és a 3DNow kapcsolatára - a trükközik kifejezetten arra vonatkozott az idézett mondatomban, hogy a program fejlesztõjének esetlegesen nem áll szándékában teljes mértékben kihasználni a rendelkezésére álló lehetõségeket egyes architektúrák esetén.[/quote]

õszintén a fene sem gondolta, hogy a 3. pont alatt szimplán csalásokat értesz. Ez valahogy nem derült ki. Én amúgy két pontra redukálnám a felsorolásodat: az elsõt meghagynám, a 2. pont pedig "SSE/SSE2, 3DNow" lenne, a harmadikat meg elhagynám, mert nincs igazán köze a témához.

A 3DNow-ra ma egy nagy teljesítményû játék esetén valóban nincs értelme optimalizálni, de mondjuk egy szerepjáték vagy egy stratégiai játék esetén még igenis lehet értelme (pl. HoMM).

idézet:

---

Ezt írta Rive:
A VGA-kártyákkal kapcsolatban kérdezd meg T2k-t, a többire vonatkozóan pedig elég jól körüljártuk a témát korábban, annyi eredménnyel, hogy a D3 és a HL2 megfelelõ tesztjeiig egyikünknek se áll módjában többet mondani - a pillanatnyilag futó játékok pedig a régi motorokra épülnek, így ebben a kérdéskörben nem döntõ jelentõségûek. [/quote]

A jelenlegi játékok közül nem mindegyik épül annyira régi motorra, hogy ne legyen benne erõteljes SSE vagy SSE2 optimalizáció. A jelenlegi játékok alatt tettem a fenti megállapításomat, amit jelenleg igaznak érzek. Aztán persze lehet, hogy a fenti két játék megjelenésekor borulni fog minden és egy 3.2-es P4 extreme-en a D3 40%-al gyorsabban fog futni, mint egy FX 51-esen, de õszintén szólva kötve hiszem.

T2K meg azt is írta (bár nem itt, hanem a graf. kártyás topicokban), hogy a jelenlegi Q3 motoros játékok erõteljesen átdolgozott és továbbfejlesztett verziói a Q3-nak! Ettõl persze még nem biztos, hogy nincs bennük SSE2 optimalizáció, de azért erõsen meglepõdnék, ha nem így lenne.

[Stingerdf]

idézet:

---

Ezt írta Fiery:


Csak PC2100 memcsim van jelenleg, ezzel nincs sok ertelme tesztelni. Most vadaszok PC3700/PC4000-et, nincs valami tippetek, hol lehet ilyesmit kapni raktarrol? (**stral kivetelevel )


Fiery[/quote]

Varazspalca Bt? TwinMOS DDR466 powa

[FCs]

idézet:

---

Ezt írta Fiery:


Csak PC2100 memcsim van jelenleg, ezzel nincs sok ertelme tesztelni. Most vadaszok PC3700/PC4000-et, nincs valami tippetek, hol lehet ilyesmit kapni raktarrol? (**stral kivetelevel )


Fiery[/quote]

a dem*studi*-ban lehet kapni twinmos modulokat

[hvuk]

Ja igen, és még egy dolog. A még meg nem jelent Unreal II demója is 16%-al gyorsabban futott az FX-51-en, mint a 3.2-es P4 EE-n. És az elég nehezen feltehetõ, hogy ez a játék ne lenne keményen P4-re (értsd SSE/SSE2-re) optimalizálva.

Amúgy milyen forrásból gondolod, hogy a HL2 stream jellegû lesz, azaz VE korlátozott lesz? Mert azt tudni lehet, hogy DX9-et erõsen kihasználó játék lesz (az elsõ ilyen), de a fenti infót én még sehol sem olvastam. Ugyanez igaz a D3-ra. Leszámítva persze az "erõsen DX9-et".

[ 2003. október 08.: hvuk szerkesztette a hozzászólást ]

[special]

Az Athlon 64 erõs szereplését játékok alatt a rendkívül alacsony késleltetésû memória-elérésnek tudnám be.

[hvuk]

idézet:

---

Ezt írta special:
Az Athlon 64 erõs szereplését játékok alatt a rendkívül alacsony késleltetésû memória-elérésnek tudnám be.[/quote]

Ez jól hangzik és valószínûleg van is benne igazság, de az XP-knek magas a memória latency-je és mégis elég jól szerepelnek a játékok alatt. Amúgy tényle meglehetõsen misztikus az, ahogy a különbözõ (de azonos jellegû) programok milyen szórással futnak az egyes architektúrákon.

[Vulpes]

idézet:

---

Ezt írta Fiery:


Csak PC2100 memcsim van jelenleg, ezzel nincs sok ertelme tesztelni. Most vadaszok PC3700/PC4000-et, nincs valami tippetek, hol lehet ilyesmit kapni raktarrol? (**stral kivetelevel )


Fiery[/quote]

[url="http://"http://www.e-connect.hu"]E-connect[/url]

Van TwinMos, Corsair és Kingston is, utóbbi kettõbõl 4000-is, elsõ kettõre 3 gar, utóbbira élettartam!

Ha nagyker, akkor [url="http://"http://www.interboard.hu"]InterBoard[/url]! Kingston forgalmazó!

Update: Az InterBoard-ban per pillanat a 3200-as HyperX a top az árlistában...

[ 2003. október 08.: Vulpes szerkesztette a hozzászólást ]

[Fiery]

idézet:

---

Ezt írta Stingerdf:


Varazspalca Bt? TwinMOS DDR466 powa [/quote]

Raktaron is? "Erdekes" cegnek tunik igy a honlap alapjan, olyan garazsceg feeling Remelem, tevedek


Fiery