+ (#1146) akosf

Nos, a #1143-as tekintetében igazam volt, mert 4 -> 3 az tényleg csak 20%-os csökkenés, és a 3 -> 2 az meg 33%-os. A 2 -> 1 meg 50%-os.

Abban viszont tényleg tévedtem, hogy csökkenés != gyorsulás.

Tehát, 4 -> 3, ez valóban 25%-os gyorsulást hoz.

Közben a #1134 alapján látom, hogy a #1143-ban a %-ok nem a csökkenésre, hanem a gyorsulásra vonatkoznak. Legközelebb jobban figyelek.

[link] Nem a legkényelmesebb megoldás, de hirtelen csak ez akadt.

Kezelési útmutató és elmélet: jobb oldali kezelőpanelen FILE gombra kattintva bejön egy File Open... ablak, a beolvasás után felette a TIME label mellé kiírja a szükséges órajelet és - a gyorsabb összehasonlíthatóság végett - az időt, millisec-ben. Az SSE2, SSE és MMX váltják az utasításkészleteket, ha az MMX be van jelölve, akkor is megfelel az x87-nek, itt nincs tisztán MMX-kód. MMX-nek viszont be kell jelölve lennie, hogy lehessen SSE-t választani. A FAST és SLOW gombokra kattintva fut le a kiválasztott kód, az ARC egyelőre nem azt csinálja, amit majd fog.

A beolvasás 4 szálon történik:
- egy szál a Huffman-decode-ot és IDCT-t végzi, illetve leosztja a blokkokat az MCU-leírásoknak megfelelően, az eredmény 4xFP32 formájú CIE/YUV (nem tudom hirtelen, melyik a hivatalos megnevezés) színek.
- a második szál a konvertálásért felel, 4 db 4 MB-os előre lefoglalt pufferen és event-eken keresztül tartja a kapcsolatot a dekódoló szállal, 32 bites RGB-színekkel tölti meg a célképet.
- a harmadik szál az előnézet elkészítéséért felel, ez forrásként a célképről dolgozik, a konvertáló jegyzi, hanyadik sornál tart, csak akkor van szükség event-re, ha esetleg utolérné azt.
- a negyedik szálon csak a progress bar van, ki kell tenni egy külön szálra, hogy a timer-e a beolvasás közben is üssön.

Az preview azért akkora, amekkora, mert még időben eszembe jutott, hogy a teljes munkaterület nagysága a felbontástól függ, úgy nem összehasonlíthatóak az eredmények a nagyítás/kicsinyítés mértéke miatt. Így maradtam a 800*600 felbontásnak megfelelő nagyítási célterületnél, hogy laptopon se legyen gond. A teljes méret és az előnézet között a preview/actual size kapcsolókkal lehet váltani, utóbbiban látszik ezután az 'állatorvosi ló' eredménye. Ez 6 különböző implementációt takar (FAST/SLOW, mindkettőn külön SSE2/SSE/MMX-x87). Az algoritmus lényege: szükség volt múlt héten egy megadható 3x3 mátrix-szal dolgozó általános képmanipulációs (simító, élkiemelő) algoritmusra, amely 32 bites RGB formában kapja és adja vissza a képet, ez elkészült mindhárom utasításkészletre, viszont az optimalizációs lépések között meglepő különbségek adódtak. A kód egy 3 soros pufferben tartja azt a három sort 4xFP32/pixel formában, amivel dolgozik éppen, ciklusonként egy - a 'következő' - sort kell lekonvertálnia 4x8 bitből 4xFP32-be (az kép első két sorát előre legyártja), a pufferre mutató 3 pointer-t cserélgeti (ami most 'következő' sor, az a következő ciklusban 'aktuális' sor lesz, majd 'előző'), mindig a mostani 'előző' sor helyére konvertálja a következő körben az új sort, majd kiszámítás visszaírja a képre az eredményt 4x8 bitben. Így adott a lehetőség a helyben számolásra, és több, mint 4000 pixel széles képig egy 256 KB L2 cache elég (3x16*4000+2*4*4000=224000 byte + a 48 byte-os mátrix + a stack teteje). A mátrix maga 4*3 FP32 értéket tartalmaz, mindegyik sor végén egy nullát, a könnyebb kezelhetőség kedvéért:
(1/9,1/9,1/9,0.0, 1/9,1/9,1/9,0.0, 1/9,1/9,1/9,0.0), tehát jelen esetben sima átlagolás (a lefutási idő teljesen független a mátrixtól és a kép tartalmától).

A hat megvalósítás (mindegyik egy szálas):

- Fast SSE2: 32 bit RGB -> 4xFP32 konverzió SSE2, a mátrix 9 (12) elemét 3 XMM-registerben tartja, innen 9 shuffle adja a pixelenkénti 4 csatornára a szorzókat, 9 szorzás, 8 összeadás egyetlen összeadóba, majd egy SSE2-es 4xFP32->32 bit RGB konverzió.

- Fast SSE: csak a konverziókban (128 bites SSE2 helyett 2x64 bites MMX+SSE utasítások) különbözik az SSE2-től, a ciklusmag teljesen azonos.

- Fast x87: konverziók FILD-FSTP párokkal, számítás 3*3*3 szorzással, a csatornánkénti (3*3) részeredményeket 3 számlálóban adja össze, a függőségek csökkentése miatt. Mivel ehhez csak 4 FPU-register kell, a mátrix 12 értékéből négyet register-ben tart (12 szorzásnak van így register-operandusa).

- Slow SSE2: a nevével ellentétben egy kicsit gyorsabb. Mivel jelen esetben a 9 shuffle eredménye ugyanaz, mint a mátrix 3 sora, így ezek kimaradtak, amúgy teljesen megegyezik a Fast SSE2 eljárással (még az 1-1 mátrixsor-értékek szétosztása 3 registerbe is megvan, csak hogy a függőségek száma ne csökkenjen), a ciklusmag 42 helyett 33 SSE-utasítást tartalmaz.

- Slow SSE: annyiban különbözik a Fast x87-megoldástól, hogy a belső ciklusmag annak mintájára, csak skalár SSE utasításokkal dolgozik (a konverziók ugyanúgy FILD-FSTP párok, 4 mátrix-értéket tart register-ben, 3 számláló az összeadáshoz, csak itt egy SSE-utasítás + 1 int. store konvertál 4xFP32-ből 8 bitre, word-os FISTP helyett).

- Slow x87: ugyanaz, mint a Fast x87, egyetlen különbség, hogy itt nem tartom a 4 mátrixértéket register-ben, azaz mind a 27 szorzás memória-operandusú.


A test.jpg-t kell megnyitni, a másik két file a két forrás, de azokra is lefut. A program elméletileg elboldogul bármely 3 komponenses baseline, interleaved, non-progressive JPEG-gel, de csak ezekkel. Progressive vagy non-interleaved esetekben futási hibát adhat, hierarchical esetén pedig nem a megfelelő frame-et jeleníti meg. A lossless eset készülget lassan.


Lefutási eredmények egy 2266 MHz 256 L2 Celeron-D esetében:
- Fast SSE2: 839 654 505 = 359 ms
- Fast SSE: 984 295 019 = 438 ms
- Fast x87: 1 308 742 099 = 578 ms
- Slow SSE2: 730 949 926 = 312 ms
- Slow SSE: 1 356 757 836 = 594 ms
- Slow x87: 1 571 330 782 = 687 ms
Ami látszik: Fast esetben szépen skálázódik a 3 eredmény, az SSE2 és SSE esetek eredményei teljesen a konverziók közti különbségeket mutatják, itt gyaníthatóan az 1x128 és 2x64 bites micro-opok számának eltérése lehet a különbség oka; Ha nincs suffle, nem sokat számít (Fast SSE2 - Slow SSE2 különbség); x87 és skalár SSE műveleteket ugyanolyan gyorsan futtat, nincs értékelhető eltérés, csak pár százalék (Fast x87 - Slow SSE). Ellenben, amikor a Fast x87 ciklusmagjában kb. 80 FPU-utasításból - a 27 FLD és a 15 FMUL mellett - még 12 FMUL memória-opendust kapott register helyett, akkor igencsak megugrott a lefutás ideje (1571330782/1308742099=1,20064).




Lefutási eredmények 4x1890 MHz 1MB L2 K8-on:
- kép megnyitás: 989 983 542 = 516 ms (4 magon engedélyezve), 1 130 271 713 = 594 ms (2 magon engedélyezve)
- Fast SSE2: 1 026 093 879 = 531 ms
- Fast SSE: 1 017 255 213 = 531 ms
- Fast x87: 768 750 806 = 406 ms
- Slow SSE2: 737 091 686 = 391 ms
- Slow SSE: 965 759 031 = 515 ms
- Slow x87: 778 704 548 = 406 ms
Erre mit lehet mondani? Mindkét x87 magasan a leggyorsabb; Fast SSE2 és Slow SSE2 között a 42 SSE-utasításból kivettem a 9 shuffle-t (33/42=0,78), lett 737091686/1026093879=0,7183... (a 'vártnál' is nagyobb gyorsulás valószínűleg a decode-oldalnak köszönhető, a SHUFPS VectorPath is egyben, ez retirement-en nem változtatna).
Még észrevehető, hogy Fast SSE2 és Fast SSE között nincs különbség, mivel előbbiek már decode-szinten két 64 bites műveletre fordulnak, illetve, hogy meg sem érzi a Fast és Slow x87 közötti különbségeket a cache-olvasások számában.
Slow SSE (skalárSSE) esetben pedig kiderül a tény, hog a MOVSS reg,mem (load single scalar from memory) igencsak Double-utas utasítás, bármennyire is szép és kényelmes is az a flat XMM-register file...


Egyelőre a harmadik kód kimaradt, de hamarosan pótlom.

[Szerkesztve]

Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

Egyelőre a mérési eredmények:

E4300 ( Core2Duo ) 9x255=2295 MHz, DDR RAM 204 MHz-en

slow MMX: 939.479.670 ; 406 ms
fast MMX: 890.069.670 ; 375 ms
slow SSE: 869.471.010 ; 375 ms
fast SSE2: 527.742.153 ; 218 ms
fast SSE: 508.244.211 ; 218 ms
slow SSE2: 404.421.048 ; 171 ms

C2D / K8 teljesímény arány, órajelre vetíteve a fenti adatokból )
( K8futásidő #1154 / C2Dfutásidő #1155 * K8órajel / C2D órajel )

Fast SSE2 : 531 / 218 * 1890 / 2295 = 2,0059
Fast SSE : 531 / 218 * 1890 / 2295 = 2,0059
Fast x87 : 406 / 375 * 1890 / 2295 = 0,8916
Slow SSE2 : 391 / 171 * 1890 / 2295 = 1,8830
Slow SSE : 515 / 375 * 1890 / 2295 = 1,1310
Slow x87 : 406 / 406 * 1890 / 2295 = 0,8235

1. Nahh, a K10 nem menekülhet majd a teszjeink elől!
2. Hát ez jó, hogy a K8 x87-ben gyorsabb, mint SSE/SSE2-ben.

Nem egészen értem a következőket:
3. Ha x87, akkor miért ''MMX''?
4. Mi van, ha semmi sincs bejelölve?
5. Miért kell az elsőnek bejelölve lennie az SSE-khez?
6. Bug, hogy ki lehet kapcsolni úgy az MMX-et, hogy az SSE2 bejelölve marad?

7. Úgy látom, ezek a ''Fast'' és ''Slow'' elnevezések nem a legszerencsésebb. Tekintve, hogy ''Slow'' SSE2 nagyrészt ugyanaz, mint a ''Fast'' SSE2, csak ugye még ki is marad 1-2 dolog. (Miért ''Slow'', ha kevesebb eleve művelet?) A Fast és Slow SSE meg két eléggé különböző rutinok.

Szóval, ha nem haragszol, ezeket a jelöléseket és elnevezéseket lehetne intuitívebbre is venni. Persze ez a program nem egy tesztprogramnak készült, így nem ez volt az elsődleges szempont. Ha ha van kedved, átalakíthatnád esetleg egy kicsit a GUI-t. Pl. lehetne 6db radiobutton, melyek közül csak egyet lehet választani, majd benyomni a ''Run'' gombot, vagy ilyesmi. A radiobuttonok mellett meg ott lenne egy rövid felsorolás, hogy milyen utasításokat használ. Na, mit szólsz?

PD930 (3Ghz) WXP32bit:

Fast_SSE2__:___690 409 545 = 219 ms
Fast_SSE___:___934 399 785 = 312 ms
Fast_x87___:_1 247 955 570 = 406 ms
Slow_SSE2__:___591 240 315 = 187 ms
Slow_SSE___:_1 295 072 460 = 412 ms
Slow_x87___:_1 506 025 343 = 500 ms


Sajnos a K7-es gepemben bedoglott a trafo (leglabbis remelem hogy csak az)

Privat velemeny - keretik nem megkovezni...

Nocsak, nocsak, nocsak... Nem is olyan nagyon gyors fp-ben ez a Core(2). Hiszen legjobb esetben is csak 2x gyorsabb, mint a K8, más esetekben még annyival sem. (x87 kódban még lassabb is.) Csakhogy, mint láttuk, a K8 kifejezetten lassú SSEx-ben... Minden valószínűség szerint jóval a 2x64->1x128 bit jelentette alap ~2x-es gyorsulás felett fog gyorsulni a K10 a K8-hoz képest, így szépen beelőzheti a Core(2)-t... Mondjuk a teljes képhez hiányzik még a PM/Core(1) teszt. (Meg persze ehhez a Penrynnek és az SSE4-nek is lesz 1-2 szava.)

És akkor egy K8 vs. Netburst összehasonlítás, csak úgy poénból:
Fast SSE2: 531 / 219 * 1890 / 3000 = 1,52
Fast SSE::: 531 / 312 * 1890 / 3000 = 1,07
Fast x87::::: 406 / 406 * 1890 / 3000 = 0,63
Slow SSE2: 391 / 187 * 1890 / 3000 = 1,31
Slow SSE::: 515 / 412 * 1890 / 3000 = 0,78
Slow x87::::: 406 / 500 * 1890 / 3000 = 0,51
Namost, pl. a 3D renderer szoftverek x87-ben vannak, hát nem csoda, hogy inkább K8-ból építettek renderfarmokat korábban.

PD820 (2.8Ghz) WXP32bit

Fast_SSE2__:___688 552 900 = 250 ms
Fast_SSE___:___933 372 482 = 328 ms
Fast_x87___:_1 248 248 456 = 453 ms
Slow_SSE2__:___590 881 676 = 203 ms
Slow_SSE___:_1 293 765 578 = 453 ms
Slow_x87___:_1 505 491 414 = 531 ms

Privat velemeny - keretik nem megkovezni...

Unatkozol?

Szerintem az intel processzorokat a FILD (FIST) utasítások fogják vissza ennyire.
Különben nem lenne ilyen szignifikáns a különbség az x87 kódban.

Sőt, SSEx esetén egy reg -> xmm konverziónál az intelek a gyorsabbak.
( Ez pedig alkalmas a FILD kiküszöbölésére... )

PM750 (1.86Ghz) WXP32bit

Fast_SSE2__:_1 004 705 672 = 594 ms
Fast_SSE___:___984 297 701 = 625 ms
Fast_x87___:___998 029 496 = 625 ms
Slow_SSE2__:___797 694 562 = 469 ms
Slow_SSE___:_1 328 507 256 = 797 ms
Slow_x87___:_1 013 922 365 = 625 ms


Hogy oszinte legyek ezekben az eredmenyekben nem nagyon bizom. Ugyanazon teszt tobbszori egymasutani lefuttatasa tul nagy kulonbsegeket adott (pl. 697 ms v. 860 ms). Eleg sok minden fut a gepen. Kivalasztottam a leheto leggyakrabban felbukkano legjobb eredmenyt.

Privat velemeny - keretik nem megkovezni...

Akkor egy PM vs. C2D:

Fast SSE2: 594 / 218 * 1860 / 2295 = 2,21
Fast SSE::: 625 / 218 * 1860 / 2295 = 2,32
Fast x87:::: 625 / 375 * 1860 / 2295 = 1,35
Slow SSE2: 469 / 171 * 1860 / 2295 = 2,22
Slow SSE:: 797 / 375 * 1860 / 2295 = 1,72
Slow x87:::: 625 / 406 * 1860 / 2295 = 1,24

Lehetséges, hogy a háttérben futó dolgok 20-30%-ot rontottak a PM teljesítményén, azt hozzászámolva 6-ból 5 esetben pont egyszeres és kétszeres eredmény jönne ki.

(#1162) akosf: Ki kellene próbálni...

[Szerkesztve]

T2080 (1.73Ghz) WXP32bit

Fast_SSE2__:_1 119 298 427 = 656 ms
Fast_SSE___:_1 133 661 451 = 656 ms
Fast_x87___:_1 189 157 762 = 672 ms
Slow_SSE2__:___944 186 594 = 547 ms
Slow_SSE___:_1 164 346 222 = 672 ms
Slow_x87___:_1 165 944 767 = 672 ms


A gepen gyakorlatilag csak a Win, meghajtok es az AVG fut.

Privat velemeny - keretik nem megkovezni...

K10 felülről
[link]

éas még több [link]

[Szerkesztve]

Úgy tudom szeptember 10-én lesz a nagy nap... [link]

a születés napom elött egy nappal
és a desktop részlegről mit lehet tudni meg esetleg kósza árszegmens pletykák se keringenek valahol

illetve az AM2+-os lapokról(tudod nem ide tartozik, csak ha már itt vannak olyanok akik elégé benne vannak ) illetve az RD7xx-as chip családról némi hasonló info morzsa?

"Már a kép is kimeríti a cserbenhagyásos nemi izgatást. " by tomcsi23

Szerintem a karácsonyi szezonban már lehet kapni a desktop procikat és a hozzá passzoló lapokat is. Az egyszerűen akkora üzlet hogy nem engedhetik meg maguknak hogy lemaradjanak róla...

nagoyn jó lenne főleg ha az intel mindenkori procijaivla az árversenyt is tudná tartani (remélem a teljesítményre nem lesz panasz!!?)

de persze tudom azt is hogy most a szerver az elsődleges szempont.


amennyiben ki jönnek az AM2+ lapok és veszek egyet valami közép kategoriás ATI-re gondolok(asszem RD780) meg hozzá 2-1giga 1066-os ramot és amég nem lesz K10 addig valami olcsó K9, ez mennyire jó ötlet illetve amik most jönnek ki phomonok azok am2->am2+->am3-ban mint menni fognak

"Már a kép is kimeríti a cserbenhagyásos nemi izgatást. " by tomcsi23

Jelenleg a K8 magos processzorok vannak piacon. K9-es nem lesz.

A Phenom-ok közt pedig lesz olyan amelyik AM2 és AM2+ lapokban fut, illetve olyan is amelyik AM2+ és AM3-as lapokban. Olyan nem amelyik mindháromban. Tehát mindegy milyen lapot veszel, elvileg lesz hozzá K10 magos processzor.

Én valahol azt olvastam hogy az AM3-as procik menni fognak AM2 és AM2+ lapokban is.

[link] Nem pont itt, de erről szó esik itt is.

"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

Valóban ezt írják több helyen is. Egyébként logikusan hangzik hogy az AM3-as processzorok támogassák az AM2-őt is, hiszen csak a támogatott HyperTransport verzióban van különbség. Vagyis AM2-es és AM2+os lapokba mindegyik új processzort bele lehet majd pakolni.

Más.

Hallottátok hogy az OCZ kijött egy speciálisan AM2-es AMD processzorokhoz tervezett memóriával? [link] Gondolom méregdrága lehet ha 4GB-osnál kisebb kiszerelésben nem lehet hozzájutni. Azonban ez ''csak'' egy DDR2-667-es RAM, 5-5-5-15 késleltetéssel. Ez mitől érheti meg az árát?

AMD Preps Partners for ''Barcelona'' Launch:
[link]

Az orajelek es fogyasztasi adatok eleg lahangoloak.

Privat velemeny - keretik nem megkovezni...

Hallottátok hogy az OCZ kijött egy speciálisan AM2-es AMD processzorokhoz tervezett memóriával? [link] Gondolom méregdrága lehet ha 4GB-osnál kisebb kiszerelésben nem lehet hozzájutni. Azonban ez ''csak'' egy DDR2-667-es RAM, 5-5-5-15 késleltetéssel. Ez mitől érheti meg az árát?
Szerintem nem éri meg az árát. SZVSZ max. annyi változás várható tőle, mint anno az FPM -> EDO kapcsán. Azaz memóriasebességben - nem gép-sebességben! - 3-5%.

/// Nekünk nem Mohács, de Hofi kell! /// Szíriusziak menjetek haza!!!

Az Intel-hez képest biztos. Kár hogy az Intel nem a maximális fogyasztást hirdeti TDP gyanánt.

"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

Ez a ''speciális'' memória baromság. Marketing. Volt már nvidia-hoz meg ati-hoz való memória is. Be ne dőlj neki!

''Öregember nem gyorsvonat!''

Nem az Intelhez kepest. Magaban eleg szomoruak.

Privat velemeny - keretik nem megkovezni...

Szerintem nem.

"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

Akkor most felejtsd el az Intel-t (en eredetileg sem hoztam fel), nezd meg a szamokat meg egyszer es mond meg mi a pozitiv bennuk. Mitol nem szomoruak.

Privat velemeny - keretik nem megkovezni...

Q6600: [link] Thermal Design Power: 105W

1358 SE 2.4 GHz 4x512KB 2MB 120W

Ha figyelembe vesszük az Intel féle TDP számítást, akkor a két CPU kb. ugyanannyit fogyaszt.

Tehát szerintem a fogyasztási adatok rendben vannak, azt ne felejtsük el hogy ez még csak 65 nm.

[Szerkesztve]

"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

Ahogy mondtam, felejtsd el az Intel-t. Egyebkent az uj (G0) stepping-es Q6600 mar 95W.

Privat velemeny - keretik nem megkovezni...

Jó, én az Intel-hez viszonyítok mert egyrészt most ugye az az etalon, illetve más x86-os 4 magos procit hirtelen nem tudok felhozni.

Az a 95W akkor mondjuk 110W maximális fogyasztást jelent Intel módival kalkulálva. Az AMD is fog majd újabb steppingeket kiadni, már valahol írtak is róla. Tehát szerintem kezdésnek nem rosszak ezek az értékek.

"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

Lehet hülye kérdés, de csak 4 vagy több magos Phemonok lesznek?

''Nem kell hajó, nem kell repülőgép, | Van mit ennem, van hol aludnom még!'' Tankcsapda

A GeIL-nek pedig MAC edition memóriája volt, szép fehér dobozban, piros bársonyhatású műanyag formában, fehér hűtőbordával. És persze PC-ben is ugyanúgy működött, volt nálam is ilyen.

#tarcsad

Elvileg 45nm-en lesz. Amolyan X2 módon majd egymás mellé raknak 2x4 magot. Viszont ez még nagyon a jövő zenéje. 2008 vége, de szerintem inkább 2009 eleje.

"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

hasonlítsd pl az eredeti AMD tervekhez. A proci ami majd odaver conroe de még penrynnek is így vártuk. Evvel szemben az órajel sokkal alacsonyabb a fogyasztás meg sokkal magasabb, ez a proci biza nem egy prescot A64 helyzetet teremt. Elkeserítő.

don't look up, don't look up, don't look up, don't look up, don't look up, don't look up, don't look up...

A teljesítményéről nincs info, tehát hogy minek ver oda azt még nem tudhatjuk. Viszont ha neked már van valami a tarsolyodban, akkor plz ne habozz és oszd meg velük.

Sajnálom hogy most emiatt szomorú lettél...

"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

Azt hiszem félreértettél... Arra voltak kíváncsi, hogy 2, esetleg 1 magos verzió lesz-e?
Más:
A kompatibilitásra visszatérve: Az AM3 tudtommal már DDR3-as alaplapokon lesz. Tehát a prociban DDR3-as memóriavezérlőnek kell lennie. Az AM2 meg DDR2-es. Akkor hogy lesz kompatibilis? Integrálnak bele DDR2-es memóriavezérlőt is? (el vagyok egy kicsit maradva...)

''Nem kell hajó, nem kell repülőgép, | Van mit ennem, van hol aludnom még!'' Tankcsapda

Ja, bocs. Igen, lesz 2 és 1 magos is, de először a 4 magos X4 fog jönni.

Jelen állás szerintem az AM2+ és AM3 procik is kompatibilisek lesznek lefele. Tehát ha minden igaz akkor egy AM3 proci menni fog egy jelenlegi AM2-es lapban, megfelelő BIOS frissítés után. Pontosan úgy ahogy írtad, az AM3-as proci IMC-je képes lesz a DDR2 és DDR3 memóriák kezelésére is.

"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

Az AM2+ és az AM3-as procik között az a legnagyobb különbség, hogy az utóbbi támogatja a DDR3-at is. De kompatibilis a DDR2-vel is. (Azt nem tudom, készíthető-e DDR2 foglalatos AM3-as alaplap.)

Némi újabb AM2+, AM3 infó: [link]
''65nm, 45nm CPUs to fit into every AM2 motherboard''
Jóvá akarják tenni a 939-es fiaskót.

Szerintem a DDR2 foglalatos AM3-as alaplap az az AM2+ alaplap.

"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."

Elvileg karácsonyra kijön a 2-magos is. (Viszont 1-magosok egyelőre nem lesznek.)

#1194: hát, lehet... Bár voltak hírek újabb fogyasztást csökkentő megoldásokról, pl. esetleg magonként eltérő tápfesz.

Hequila: a DDR2 és DDR3 eléggé hasonlít egymásra, elvileg ugyanazok a vezérlőjelek, csak magasabb frekin, és alacsonyabb feszültségen.

Raymond: állítólag a 2-magosok kapásból mennek majd 2.8 GHz-ig, és később feljebb is.
Amúgy jelen állás szerint már az is jó hír, hogy még idén kihozzák a 2.5 GHz-eseket is. Szerver vonalon már az is eléggé versenyképes. Asztalon már inkább csak bizonyos alkalmazásokban.

[Szerkesztve]

Az AMD honlapján már hónapok óta fent van K10h opti manual. [link]
Az Intel Core2 opti manualja is elérhető: [link]
Egy összefoglaló referenciatáblázat: [link]

Ezekből már lehet következtetni a teljesítményre. Méghozzá elég jól. Tkp. azok dolgoznak ezekkel a doksikkal akik szeretnének rendes teljesítményt kicsikarni a processzoraikból.

A mostani kétmagos négyjegyű Opteronok (F2, F3) területén az SE-k 119W, a HE-k 68W, a többi 95W TDP-vel rendelkeznek. Miért olyan lehangoló kisebb csíkszélesség, +2 mag, +2 MB L3 és ''megkétszerezett'' méretű FPU-unitok mellett konzekvensen ugyanez az adat (jelenlegi legutolsó kétmagos versus következő első (+ második?) négymagos revision)?

[mod]: Más. K10 esetén ismert már, hogy mennyi lesz a Vcore, illetve, hogy mennyi lesz a HE változatok magfeszültsége?

[Szerkesztve]

Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

''Amúgy jelen állás szerint már az is jó hír, hogy még idén kihozzák a 2.5 GHz-eseket is. Szerver vonalon már az is eléggé versenyképes. Asztalon már inkább csak bizonyos alkalmazásokban.''

A 2 GHz alatti/körüli Core2-k mennyire versenyképesek manapság asztalon a(z 'előző generációt' képviselő) 3 GHZ feletti Pentium-D-kkel?

[Szerkesztve]

Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙

A ket adat (orajel es TDP) egyutt lehangolo. Nem arrol van szo hogy mennyit fogyaszt magaban vagy hogy mennyit fogyaszt az Intel-hez kepest hanem hogy mit lehet kiolvasni a lekozolt modellek parametereibol.

1) A launch modelleknel max 2Ghz-es jon ki az is kis mennyisegben.
2) A 2.5Ghz-s aminel az adatok szerint nem is lesz gyorsabb mostantol szamolva majd egy evig (Q2 2008) csak a fesz emelessel erheto el. Sot mar a 2.4Ghz-nek is kell a fesz emeles. Ezert az ugras a 2.3->2.4 TDP-je kozt
3) A kilatasok Q2 2008-ra sem tanuskodnak valami vilagrengeto gyartasi ujitastol. A 2.4-es lemegy a 95W kategoriaba, de a 2.6-os meg mindig a 120W marad. Egy komolyabb tweak-nel nem 100Mhz kene hogy legyen a gyorsulas.

Mar regebben kitargyaltuk itt hogy az altalanos alkalmazasokban az IPC javulas nem lesz szamottevo az SSE2 128bit fogja hozni a leglatvanyosabb gyorsulast. Meg ha a K8-hoz kepest javitanak is az altalanos sebessegen a piac ma mar mashol tart. Ezert szomoruak a szamok.

Privat velemeny - keretik nem megkovezni...