Akkor a Phenom X4-ek is jönnek Október-November legroszabb esetben December körűl.

¡GLORIA A LAS PLAGAS!

''#1320: Hát, ebből most nem igazán tudom kibogózni, hogy a válasz igen vagy nem. Vagy néha igen, néha nem?''

Szó szerint, ahogy mondod, néha igen, néha nem. Az Optimization Manual-ok elég szűkszavúan írnak erről, érthetően: az Intel csak az OP reg,reg formájú utasítások időzítéseit teszi közzé, majd hozzáteszi, hogy az OP reg,mem formában az integer esetben +2, FPU-esetben +6 órajellel növekszik; AMD kiírja ugyan részletesen az OP reg,mem és az OP mem,reg formát is, de ő is megjegyzi, hogy az +2 órajelben különbözik a OP reg,reg formáétól. De mindkét esetben ők is egy ideális környezetet feltételeznek, a többivel nem foglalkoznak, mert nem is nagyon lehet. Mi is ez az ideális eset AMD esetében, egy load micro-opnál:
Amikor az ütemező egy címszámítási micro-opot elindít az egyik AGU-ban, akkor egyszerre ezzel elküldi azt a LSU-ba is, egész pontosan az LS1-be. Az AGU 1 (illetve összetett cím esetén 2) órajel alatt kiszámolja a virtuális/effektív címet (utóbbi az effektív cím+szegmens bázis összeg), majd abban az esetben, ha az LS1 üres, akkor közvetlenül a L1 D-Cache-nek továbbítja ezt a virtuálius címet. Azonban az L1 D-Cache tartalmának indexeléséhez szükség van a virtuális mellett a fizikai címre is, ennek meghatározásában segít a kétszintű Translation Lookaside Buffer, az első, gyorsabb hozzáférésű szint az utolsó 40 virtuáliscímhez tartozó fizikai címet tartalmazza. (Itt azt hozzá kell venni, hogy a legszűkebb pipeline+LSU egységen kívül az egész rendszerben, tehát már a TLB-kben és a cache-ekben a memóriahozzáférés adategysége a 64 byte-os határra illesztett 64 összefüggő byte). Ha L1 TLB-ben megtalálja a szükséges fizikai címet, akkor ezzel a két értékkel ''megnyitja'' az L1 D-Cache megfelelő két (2-way set-associative) vonalát és összehasonlításra kerül a két cím az ott lévőkkel; itt derül ki, hogy a keresett adatot tartalmazza-e az L1 D-Cache (hit/miss). Találat esetén ez a megnyitás azt is jelenti, hogy a következő órajelben a kért adatot a cache közvetlenül az pipeline-ba, a megfelelő result-busra juttatja, az LS1-beli bejegyzés pedig törlődik.
A load-ok D-Cache-hez való hozzáféréssel párhuzamosan ellenőrzik az LS1 és LS2 tartalmát, hogy van-e olyan függőben levő megfelelő méretű tárolás(i szándék) a kért címre. Ha van, akkor a cache hit/miss eredménytől függetlenül továbbítják az adatot a result-busra (ha az még nem ismert, csak a cím, akkor egy függőségi bejegyzést jelölnek be, hogy az adat megérkezésekor azonnal továbbíthassák). Ez a Store(-to-Load) Forwading.
A normál store és load-store eset annyiban különbözik, hogy az LS1 bejegyzés nem törlődik, hanem átkerül az LS2-be, és ott várja meg a címhez tartozó tárolandó adatot. A cache-probe ugyanúgy megtörténik, a tényleges írás viszont nem, majd csak a retirement során, programsorrendben. A Non-Temporal Store-ok ezt az egész hierarchiát kikerülik, közvetlenül néhány 64 byte-os buffer-be írják adatukat, az AGU-k közvetlenül ezen buffer-controller-be továbbítják a címet, és az egységek az adatot (illetve a pipeline ezenkívül közvetlenül kommunikál vele, mert meghatározott szabályai vannak annak, hogy bizonyos adott körülmények között le kell zárni ezeket a buffer-eket, és tartalmukat ki kell írni a rendszermemóriába).

Ez az ideális eset, ebben az esetben az AGU-k közvetlenül LSU-hoz (Store Forwarding céljából), a L1 TLB-khez + L1 D-Cache-hez szólnak, közvetlenül továbbítják az adatot a result-busra, tehát így a pipeline meghosszabbításának tekinthető (mint korábban, a K7-es leírásban jelen is vannak, mint stage-ek). A legfontosabb nem ideális esetek:
- az LS1 nem üres: három AGU órajelenként akár három címet számíthat ki, viszont az L1 D-Cache csak két porttal rendelkezik. Ezután az LS1 mindig a ''legöregebb'' két hozzáférést továbbítja az L1 D-Cache felé, a többit átmenetileg tárolja.
- a keresett cím nem található meg a 40 elemű L1 TLB-ben. Ekkor a lassabb, de 512 elemű L2 TLB-hez kell fordulni, ha ott találat van, akkor adatcsere szükséges a két TLB-szint között. Ha a L2 TLB-ben sincs meg, akkor kezdődik a lényegesen hosszabb négyszintű virtuális->fizikai cím fordítás (table-walking, esetlegesen rendszermemória-hozzáférés lehet szükséges már ehhez is).
- ha a Store Forwarding nem jár sikerrel, valamint az L1 D-Cache-ben sincs meg a keresett vonal, akkor memory hierarchy mélyebb szintjeihez kell fordulni, ez L2 probe, adatcsere az L1-L2 között, esetleges rendszermemória-hozzáférés, legrosszabb esetben egy page miss, tehát a lapozófile-hoz kell fordulni.
Utóbbi két esetben, illetve store-ok esetében kerül a bejegyzés át LS1-ból LS2-be.

Ha ez még nem lenne elég, tovább bonyolítja a helyzetet, hogy az összes exclusive cache-nek értesülnie kell minden kell minden cache-hozzáféréshez systemwide, és megfelelően kezelnie kell a helyzetet (összes exclusive cache: ez magonként 3 AMD esetében, legutóbbi Intel-ek esetében natív 2-magonként 1-et vagy hármat? De úgy tudom, az I-Cache-ek sem exclusive-ek, mint ahogy a L1 D-Cache-ek sem), a MOESI protocol szerinti jelöléseket fenn kell tartani, self-modifying code-okat kezelni kell, illetve adott esetben továbbítani kell a kért adatvonalat egy másik cache-be. Mivel egy adott cache csak bizonyos számú hozzáférést tud kezelni egyszerre, ezért emiatt is esetlegesen várnia kell egy request-nek. Non-Temporal Store esetben semmi nem tartja fenn ezt a rendszerszintű koherenciát, ez kizárólag a programozó felelőssége.

A fentiek valamelyikének felmerülésekor (tehát az ideális eset kivételével) a memóriahozzáférések nem tekinthetőek a pipeline részének, programozói szempontból csak annyi látszik, hogy
- load esetben a cím kiszámolásra került az AGU által, eddig kezelhető/optimalizálható a kód, ezután várunk a kért adatra. Az adatok megfelelő elrendezése nagymértékben csökkentheti ezt a bizonytalanságot.
- store esetben a címet az AGU, az adatot valamely egység adta, innen a művelet befejezettnek tekinthető.
Tehát, hogy politikailag korrektek legyünk, minden memóriahozzáférést valamely AGU kezdeményezi (a cím kiszámításával), vele párhuzamosan az LSU felkészül, és nem ideális körülmények között vagy tárolás esetén átveszi.

''ps. előnyösebb lenne nem keverni egy válaszban jelzés nélkül mások szövegeit a címzettével.''
Egy hsz-t néztem, és válaszoltam az ottaniakra, függetlenül, hogy idézet vagy válasz volt.


[Szerkesztve]

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

Épp ma kezdtem el irogatni egy kis programocskát amivel letesztelhető pár utasítás latency értéke. Ugyanis készülök a K10/Penryn megjelenésre.

Na, de visszatérve az FPU esetében említett +6 órajeles késleltetésre, azt kell mondjam hogy az meglehetősen jól el van rejtve, ugyanis a cím az integer regiszterekből generálódik, a CPU meg elég jól képes előre látni. Ezért a tényleges futásidő szempontjából ez már nevezhető ideális esetnek. Egyébként van valami információd arra vonatkozóan hogy kb.milyen gyakran fordulnak elő a nem idális esetek? Ráadásul ezen eseteknél sem mindig a +6 órajel késleltetés érzékelhető.

hi..
elérkeztünk a kérdéses dátumhoz...ha megtalálod a demózott cikket gondolom linkeled azonnal...már várom mit és mennyit láthatunk belőle..
na jóéjszakát

Ha x tart végtelenbe, akkor a prímek reciprok szorzatának negáltja 0-hoz tart...

Kösz a kimerítő leírást. De még nem derültek ki a következők:
1. Pl. az ADDPD xmmreg1, xmmreg2 (mem) utasításban mi a ''(mem)''?
- Ha ez memória-hozzáférést takar (ami persze jobb esetben valamelyik cache-ben végződik), akkor AGU-s indítás ide vagy oda, az LSU is meg van dolgoztatva, tehát egy macro-op-ból megvan az egész! (Így tehát egy Inteles micro-op inkább egy AMD-s micro-opra hajaz, semmint egy egész AMD-s macro-opra - tehát a ''3 vs. 4 szélesség'' helytelen, és ez inkább 6 vs. 5 szélesség!)
2. Ha az FPU-s memória-műveletet is az AGU és az LSU végzi el, mit csinál az FSTORE? (Nyilván mást, mert láthatóan nem utasítható egy macro-op load/store/load-store micro-opjával, külön macro-opot igényel, ha más FPU-beli alegységgel is van ''dolgunk'' egy utasításban.)

Andre1234: Milyen dátumról van szó? A japán demózásról? Az előző sem volt túl informatív, csak egy screenshot jött ki, ami igazolta a 3 GHz-t, meg hogy szépen futott pár játék, fps nélkül.

[Szerkesztve]

Itt az első cikk a vasárnapi AMD bemutatóról: [link]

Talán a legérdekesebb az egészben az ''Athlon 64 X2 6400+ Black Edition''. Amely nem más mint egy gyárilag fekete dobozba csomagolt X2-es.

Áhhh, beelőztél!

Nnna itt egy másik ''cikk'':
AMD Akiba Event showcases Phenom 3GHz processor and roadmap - [link]

Szöveg nem sok van, csak egy halom (elmosodott) telefonos fotó.
Mondjuk az a Buldozer mag érdekesn hangzik a roadmapon.

"Figyelj arra, aki keresi az igazságot és őrizkedj attól, aki hirdeti: megtalálta." - (André Gide)

Hát a sok ferdeszemün kívül nem sok mindent lehet látni.

ASUS Prime A320I-K,AMD Ryzen3 2200G ,2x8GB 3000MHz DDR4 Corsair ,240 GB Kingston HyperX Savage SSD,LG 27MP59G,SilverStone Raven Z RVZ02,Bequiet Shadow RockLP(Gyári AMD hűtő hely hiány miatt),Huawei Nova 5T, XBOX ONE X,MSI GS63 7RF Stealth

Nagy a titkolózás, csak azt nem tudom, ha lennének teszteredmények, akkor pár nap alatt tudna válaszolni az Intel ? Mert ugye ezért nem szivárognak ki eredmények, hogy a konkurencia ne legyen ''informálva''.

"Ismerősöm szerint az ő Logitech Z-623-as rendszere (bizonyos esetekben) jobban szól, mert felére feltekerve is adja a mélyet, szétveri a házat a gettób@szó számokban !" by Rasiel :DDD

''Mert ugye ezért nem szivárognak ki eredmények, hogy a konkurencia ne legyen ''informálva''.''
Lehet azert mert megint csak gyenge lett mint a 2900 es inkabb nem mondanak semmit

Meg ha véletlen kiderül hogy mégsem olyan jó egyből zuhan pár 10%-ot az Amd részvények árfolyama. Az R600-zal is ezt csinálták....
Remélem nem jön be ez az elégé pesszimista jövőképem
Ribi: egyre gondoltunk Jobb lenne ja nem tökölnének annyit és mutatnának végre valamit. Bár ha jó lesz a cucc akkor meg az ára lesz az egekben egy darabbig Amd fan-ként ennek azért jobban örülnék.



[Szerkesztve]

Egyre biztosabbra veszem hogy számítási teljesítményben a K10 nem fogja megverni a Penryn magos processzorokat, azonban az olyan szerver alkalmazásokban ahol a lényeg sokkal inkább a memóriaműveleteken van ott minden bizonnyal újra az Opteronok kerülnek fölénybe.

Instruction latency meresre az EVEREST nem jo? (Jobbclick alul a statusz soron --> CPU Debug --> Instruction Latency Dump). Nez egy par spec. esetet is, es viszonylag pontosnak is. Ez itt pl. egy Yonah:

Ui: hoppa, ez igy eleg csunyan nez ki, inkabb kiveszem, de az EVEREST-ben megtekintheto


[Szerkesztve]

AIDA64.com

Én is ettől tartok, hogy nem veszei fel a versenyt, ha még teljesítményben fel is veszi, árban már nembiztos, bár kár még találgatni. Bezzeg a Core2-nél már hónapokkal a megjelenés előtt lehetett tudni, hogy azonos órajelen 20-30%-al gyorsabb lesz. Érdekes...

"Ismerősöm szerint az ő Logitech Z-623-as rendszere (bizonyos esetekben) jobban szól, mert felére feltekerve is adja a mélyet, szétveri a házat a gettób@szó számokban !" by Rasiel :DDD

Nem ismerem az Everest-nek ezt a funkcióját, de tényleg jónak tűnik!
Azonban hiányolok belőle jó pár utasítást...

Felraktam ide [link] par proci dumpjat. Ezekben mar tobb utasitas szerepel, mint az eddigi EVEREST-ekben. Konkretan mi hianyzik?

[Szerkesztve]

AIDA64.com

THX....

Ha x tart végtelenbe, akkor a prímek reciprok szorzatának negáltja 0-hoz tart...

Szuper vagy! Köszönöm.

Épp pár órája ütöttem le egy Dothan-t meg egy Yonah-ot az ebay-en hogy majd letesztelhessem, de úgy látom felesleges volt.

Hogy konkrétan mi hiányzik? Hm... csak párat mondanék ami hirtelen eszembe jutott, de ha kell később összeírom egy privát üzenetben.

XCHG reg,reg
XCHG reg,mem // ez különösen érdekes eredményt tud adni
PUSH/POP reg/mem
PUSHFD/POPFD
JMP short/near // ez különösen fontos
Jcc shot/near // ez még a JMP-nál is fontosabb
SHRD/SHLD reg,reg/mem,i
BT/BTS/BTR/BTC reg/mem,reg/i // a BTC-t különösen fontosnak tartom
INC/DEC reg/mem // bocsánat most látom K8-nál már van regiszteres!
AAA/AAD/AAM/AAD/DAA/DAS/XLAT
CBW/CWD/CDQ
CLD/STD // meglepő eredményt adhat az STD!
CLC/STC/CMC/SETcc
LOOP short/near // mondjuk ezt ritkán fordítják a fordítók
(REP) LODS/STOS/MOVS/SCAS/CMPS(B/W/D) // ezt viszont sokat
LEAVE/ENTER // a legtöbb fordító a LEAVE-t használja...

FLD/FST(P) reg/mem // mondjuk ezt nem egyszerű tesztelni
FILD/FIST(P)/FRNDINT // FRNDINT különösen fontos, mert ugyan FILD+FISTP pár gyorsabb lenne a fordítók mégis ezt használják
FLDZ/FLPI/FLD1/FLDxx
FNSTSW/FNSTCW/FLDCW // szinte az összes FPU komparálásnál és truncate-nél használják
FIADD/FIMUL
FABS
FPREM/FPREM1 // maradék képzés! milyen jó is forgásszögeknél...
FSIN/FCOS/FSINCOS // ha már a szögeknél tartunk
FPTAN/FPATAN // ezt se egyszerű tesztelni...
FSCALE/F2XM1/FYL2X/FYL2XP1 // mert hatványozni néha kell és csak ez van rá...

Az SSE,MMX,3DNow! -ra nem térnék ki most, de ott is hiányzik pár dolog.

Bár most hogy közben több eredményt is megnéztem úgy tűnik az SIMD bővült.
Pl. bekerült a SHUFPS, amit pár órája még hiányoltam a letöltött EVEREST-ből.

Bingó: [link]

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

Gondolom mindenki olvasta :

[link]
[link]

"Ismerősöm szerint az ő Logitech Z-623-as rendszere (bizonyos esetekben) jobban szól, mert felére feltekerve is adja a mélyet, szétveri a házat a gettób@szó számokban !" by Rasiel :DDD

[link]

Ezek szerint csak az 1.9GHz-es Barcelona lesz elérhető szeptember 10-től.

Kiszivárogtak tesztek (ftc linkelte) most megismétlem :

[link] ahol is egy 1,6GHz-es Barcelona és egy 2,4GHz Xeon-t mértek össze Cinebench-el. Az is kilett tárgyalva hogy nem mérvadó ez a teszt, mert inkább a frekvencia számít neki. De kiindulópontnak jó.

K10 1,6GHz (814 pont)
Xeon 2,4GHz (1274 pont)

Egy kis matek : ha a K10 1,6GHz-en csinál 814 pontot, akkor 2,4GHz-en mennyit csinál(na) = kb 2,4x814/1,6 = 1221. Tehát ebbőél lehet következtetni, ha majd lesz 2,4GHz-es K10, akkor pont a Xeon-al van pariban (legalábbis e teszt szerint. Ami szintén nem elég, mert mire kint lesz a 2,4GHz-es K10, addigra a Xeon sztem 3,4GHz körül fog szaladgálni. Lépéselőnyben ismét az Intel.


Lehet jobb lenne ha IBM felvásárolná az AMD-t többre jutna....

"Ismerősöm szerint az ő Logitech Z-623-as rendszere (bizonyos esetekben) jobban szól, mert felére feltekerve is adja a mélyet, szétveri a házat a gettób@szó számokban !" by Rasiel :DDD

Aha, és a Cinebench az egy borzasztóan mérvadó teszt ám. Pl. a 6000+ kb. ugyanazt tudja Cinebench-ben mint az E6700.

A másik meg az, hogy a Barcelona mellé 667-es RAMok mennek max. (a tesztben is 667es modulok voltak mellette), a Phenom mellé meg majd 1066-osak.

Az meg hogy szorozzuk meg ennyivel-annyival megint csak nem túl helyes szvsz, mert pl. a K10-nél olyan hogy FSB korlát nem igazán létezik, ellenben a Xeon-nál igen.

Neked sosem lesz Barcelona-d, nekem sem, de szerintem ez még elmondható itt jópár kollégáról.

[Szerkesztve]

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

Tom, hogy nem K10 de érdekes összehasonlitás

X2 6400+ vs Intel E6750/E6850 elég vegyes képet adott...

[link]


a legnagyobb veszteség K8-nak az integer... ebben veri el elég rendesen C2D

Opteron vs. Xeon témában értelmetlen Cinebench-t felhozni. Sokkal többet számít itt a Direct Connect architektúra, mint némileg alacsonyabb órajel.

Mikor lesz 3,3 [333x10] GHz-es Xeon? Talán év végén. Addigra már kint lesz a B2 stepping a Barcelonából is, ami állítólag szépen viszi a 3 GHz-t, talán többet is.

A Phenomot sem véletlenül demózták 3 GHz-en, amint lehet (szintén B2), kihozzák.

OK, Cinebench hanyagolva...

"Ismerősöm szerint az ő Logitech Z-623-as rendszere (bizonyos esetekben) jobban szól, mert felére feltekerve is adja a mélyet, szétveri a házat a gettób@szó számokban !" by Rasiel :DDD

A Barcelona-nak majd inkább az ilyesféle tesztekben kell majd domborítania: [link]

Illetve majd az lesz a kellemes ha összedobnak egy 128 procis rendszert. 128*4mag.

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

hüm akkor most teljesen feleslegesen vettem meg a 800-as tuning ramokat amik mennek 1GHz-t ?
(úgy értem hogy nem tudja kihasználni úgy, mint egy 1066-ost, hiába tud annyin menni a ram?)

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

Lesz lehetőséged hogy 800-on vagy akár 1GHz-n járasd majd. Mint ahogy most is van arra beállítás hogy visszarakd 400/533/667-re.

(úgy értem hogy nem tudja kihasználni úgy, mint egy 1066-ost, hiába tud annyin menni a ram?)

Jaa...ez hülység. Ki tudja, pont úgy mintha 1066-osként árulnák. Persze csak akkor ha stabilan tudja az 1066-ot.

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

áá köszönöm erre voltam kiváncsi ha stabilan tudom járatni akkor ezt is úgyan úgy kezeli mint az 1066-asnak eladot társait

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

Kukk ide

[link]

slett27 : Lehet jobb lenne ha IBM felvásárolná az AMD-t többre jutna....

Ebben még lehet is valami. Hisz az IBM tervezi hogy a következő generációs Power7 processzorának egyik-másik változata lábkompatibilis lesz az Opteron-nal. Igaz mintha a SUN is tervezne ilyesmit. Persze 2010 előtt ne nagyon várjunk ilyet...

AMD Phenom FX91
2.4 - 2.6GHz, 2MB L2 , 2MB Shared L3, HT 3.0, Socket 1207+ /2008Q1
AMD Phenom FX90
2.2 - 2.4GHz, 2MB L2 , 2MB Shared L3, HT 3.0, Socket 1207+ /2008Q1
AMD Phenom FX80
2.2 - 2.4GHz, 2MB L2 , 2MB Shared L3, HT 3.0, Socket AM2+ /2007Q4


AMD Phenom X4 GP-7100
2.2 - 2.4GHz, 2MB L2 , 2MB Shared L3, HT 3.0, Socket AM2+ /2007Q4
AMD Phenom X4 GP-7100
2.0 - 2.2GHz, 2MB L2 , 2MB Shared L3, HT 3.0, Socket AM2+ /2007Q4
AMD Phenom X2 GP-6800
2.4 - 2.8GHz, 1MB L2 , 2MB Shared L3, HT 3.0, Socket AM2+ /2008Q1
AMD Phenom X2 GP-6650
2.2 - 2.6GHz, 1MB L2 , 2MB Shared L3, HT 3.0, Socket AM2+ /2008Q1
AMD Phenom X2 GP-6550
2.0 - 2.4GHz, 1MB L2 , 2MB Shared L3, HT 3.0, Socket AM2+ /2007Q4

2007-8-14 04:45 [link]

[Szerkesztve]

Az embert a gondolkodás tette állattá...

Lassan indul a buli !

"Ismerősöm szerint az ő Logitech Z-623-as rendszere (bizonyos esetekben) jobban szól, mert felére feltekerve is adja a mélyet, szétveri a házat a gettób@szó számokban !" by Rasiel :DDD

[link]

Ez lenne az ?

"Ismerősöm szerint az ő Logitech Z-623-as rendszere (bizonyos esetekben) jobban szól, mert felére feltekerve is adja a mélyet, szétveri a házat a gettób@szó számokban !" by Rasiel :DDD

PL: AMD Phenom X2 GP-6650
2.2 - 2.6GHz, 1MB L2 , 2MB Shared L3, HT 3.0, Socket AM2+ /2008Q1
Ezt magyarázza el valaki pls
Mennyin fog menni a proci 2.2 v 2.6? Esetleg ez csak beszereléskor derül ki?

Amd - Radeon - Ryzen

Nem kell az ördögöt a falra festeni az AMD él és élni fog.
Csak hiresztelnek itt mindent össze vissza az AMD ki mászik a slamasztikából az tuti.
Az Intel meg elmehet................

ASUS Prime A320I-K,AMD Ryzen3 2200G ,2x8GB 3000MHz DDR4 Corsair ,240 GB Kingston HyperX Savage SSD,LG 27MP59G,SilverStone Raven Z RVZ02,Bequiet Shadow RockLP(Gyári AMD hűtő hely hiány miatt),Huawei Nova 5T, XBOX ONE X,MSI GS63 7RF Stealth

[link]
Nincs itt semmi gond.
A K10-el meg remélem aratnak majd rendesen.

ASUS Prime A320I-K,AMD Ryzen3 2200G ,2x8GB 3000MHz DDR4 Corsair ,240 GB Kingston HyperX Savage SSD,LG 27MP59G,SilverStone Raven Z RVZ02,Bequiet Shadow RockLP(Gyári AMD hűtő hely hiány miatt),Huawei Nova 5T, XBOX ONE X,MSI GS63 7RF Stealth

[link]

Szóval az K10-Agena ellenfelének szánt Penryn-Harpertown processzorok november 11-től lesznek kaphatóak. Az árak magukért beszélnek. Csak arra lennék kíváncsi hogy az E5405 FSB-je is 1333 vagy azt kisebbre vették...

gondolom egységes lesz: [link]

Ezek nem az Agena ellenfelei, mivel az Agena a Phenom FX-ek és X4-ek alapja, a cikk meg Xeonokról szól. A desktop Penrynek csak 2008 tavaszán jönnek.

A #1372-essel kapcsolatban figyelmedbe ajánlom az utolsó mondatot: ''It's not clear at press time whether the delays of Barcelonas are to do with technology problems, or whether the multinationals are getting preferential treatment over the channel.''

Gyuri27: Nem tudják előre, milyen lesz a kihozatal, amitől a végleges órajel-kategóriák függenek.

laci666: Ez nem festegetés, hanem potenciális veszély. Aki meg azt mondja, az Intel nem hagyná, mert akkor azt meg a feldarabolás veszélye felyegetné, annak elmondanám, hogy az ''egyéb x86 processzor gyártói részesedés'' nem 1%, hanem kb. 10.

(Méghozzá Socket J-t [LGA 771] használó Xeon DP-k [kétprocis rendszerekbe való].)