Új hozzászólás Aktív témák
-
robyeger
addikt
Ha még nem is értünk egyet dolgokban, te azért az AMD-re utaló problémás(negatív) linkeket is megosztod a forumozókkal(vitapartnereiddel), ezt tisztelem benned, ezért bátorkodtam megemlíteni a neved. Remélem ezért nem fogsz megharagudni rám.
Tesztel kapcsolatban pont az általam linkelt oldalon 2db grafikon látható "nem módosított" adatok méréséről és pont alatta a memória késleltetéshez hasonlítják(említik), de magunk hasonlíthatjuk a Pentium D-nél mértekhez is. -
robyeger
addikt
A memória benchmárkok, a legnagyobb elérhető valós adatáresztő képességet mérik, amit le írtam már, persze egy általános programban ilyen intenzitású és idejű terhelés valószínűsége szinte a nullával egyenlő, főleg hogy ezt a maximumot általában a memória lineális olvasásakor érhetik csak el. Én ezt sose vitattam, tehát ebben akkor egyet értünk. Ezért is készítettem a WinRAR programmal tesztet, mert itt nem lineális az olvasás, sőt ami lényeges írnunk(másolnunk) is kell, az olvasás mellett.
Tehát van egy pozitív nagy értékeket mutató Everest és Sandra méréseink szemben a WinRAR gyenge értékeivel, főleg összevetve a single és dual csatorna kiosztások eredményeivel. Ezért feltételeztem régen, hogy valamiféle belső busz sávszélesség korlátozó tényező lehet, ezt viszont homlok egyenest cáfolta FX-74 mérései, mert számold ki ha nem hiszed 800Mhz-es dual channel memória elméleti sávszélessége maximum 12.8GB/sec. A valóságban ezt csak közelíthetjük akármilyen procival, de elérni vagy meghaladni lehetetlen. Mint írtam a többlet adat a hypertranszporton keresztül érkezett, így jön ki a 14GB/sec, de ez csak többprocesszoros rendszereknél lehetséges. Ebből látszik a belső buszok többet is bírnak. Tehát az egy procis rendszernél, pl. 939-en, hiába 14.4GB/sec a teljes elméleti kommunikációs sávszél, ha abból 8GB/sec a hypertranszport, viszont itt csak a videó kártyában lehet memória a másik oldalon,onnan pedig nem szoktak nagy mennyiségű memória adatokat olvasni, inkább fordítva az alaplapi memóriából töltenek fel a képi megjelenítéshez adatokat a videó ramba. Ezért nem lehet úgy venni, hogy a 14GB/sec belefér a 14.4GB/sec-be, különben is az egyik szám AM2 rendszerhez, a másik 939-es tartozik.
IMC: régebben írtam, maga az elmélet jó, de a K8-as megvalósítása primitív. A rövid késleltetés csak 1db jellemző a sok közül. A "bibi" főként a már magasabb órajelű DDR2 memóriáknál bukott ki. Habár mérges vagyok magamra is, hogy annak ideján nem szenteltem több figyelmet a 754 és a 939 közötti kis teljesítmény különbségnek, hiszen már ott is duplázódtak a memóriák elérhető elméleti sávszélességei.
K8 magok közötti komunikáció: [Dual Core dtr-analysis], (ezt P.H. linkelte be először) Magyarán hamarabb felér a memóriából az adat, mint ha a másik mag gyorsítótárából kellene kiolvasni.
Hypertranszport rövidítés: nem akarok itt régi CPU-Z screenshotokkal bombázni, régen a "HT link" szöveg helyén a "HTT" felirat szerepelt, vagy Intel doksik, ahol HT szerepel a Hyperthreading helyén, szerintem szándékosan kavarják a rövidítéseket a gyártók, sőt olyan nevet adnak új eljárásaiknak, amihez a másik konkurens eljárása hasonlít, így zavarva a lajikus felhasználókat. Hogy ki kezdte, fogalmam nincs. Igérem megszokom a "HT" jelölést, ezen nem fogok összeveszni senkivel. Mellékesen Nehalem-nél lehet, hogy visszajön a hyperthreading, akkor megint kavar lesz, na mind1.
Szóval, ha elolvasod a K10-es fejlesztéseket, ezek 60-70% a memóriavezérlőt érinti, nem hiába cserélték le azt az 1x128bites csatornát 2x64bitre. Ez már részben magyarázza, miért tud a K8 olyan jól olvasni vagy írni, de ha egyszerre kell csinálni, akkor szenved. Memóriabenchmark vs. WinRAR. Nem hiába az L3 cache a memóriavezérlővel van szoros kapcsolatban, főként azt segíti, hiszen azon az órajelen jár. És akkor még ott a prefetch logikai fejlesztések, a 256bitre növelt gyorsítótárak. Én úgy foglalnám össze 1db K8-as magra vetítve, hogy nem tud élni a dual channel adta dupla sávszélességgel. Viszont érdekes módon minél nagyobb azaz egy csatornás memória órajele, annál több adatot tud felvenni a processzor tőle. -
robyeger
addikt
válasz
muri1984
#1631
üzenetére
gyakorlatban 32bites WinXP-nél jóval kisebb az esély a visszafelé kompatibilitási problémákra, mint pl. egy 64bites Vistánál, de előfordulhat. A játékokra illik a legfrissebb javító patch-t feltenni. pldául most jutottam el oda, hogy megnézem a Quake4-et a gépemen, még v1.1 patch-el is fagyogatott, de v1.4.2-vel már kutya baja.
Ha érdekel az elmélet is, a WinXP SP2 az egyszálas programokat is, ha teheti szétbontja több magra, viszont a külön L2 cache tárazású prociknál(Athlon64 X2 vagy PentiumD) ezzel sok esetben inkább kisebb teljesítmény visszaesést csinál,mint hasznot,(a Vista ebben már inteligensebb álítólag) ez azért inkább csak mérhető, de nem okoz érezhető lassulást. Core2Dou-knál ahol egyesített az L2 cache, még ilyen probléma se léphet fel. Szóval általában mindig a szoftverek inkompatibilitást kell csak kiküszöbölni és megy is a dolog. -
robyeger
addikt
válasz
slett27
#1629
üzenetére
mivel a Conroe architektúra alapjárati sebességen gyorsabb érzetet kelt(még ha hajszálnyival is), pl: Celeron 420, azért tetszet, olyan oldtimer felling van bennem vele kapcsolatban
, a régi Intel netburst-ket lenyomja kétségtelen, persze akkortájt nem volt ilyen alacsony melegedésű és magas órajelű példányok. Ha választanom kéne 2008-ban előreláthatólag a 4magos procik közül akkor inkább egy olcsó,hűvös min. 3Ghz-es PhenomX4 proci felé húznék, mint egy Yorkfield, csak sajnos nem valószínű hogy lesz pont ilyen az AMD kínálatában, esetleg később.
Nagyobb teljesítménybeli változások szerintem most nem a CPU-knál, hanem a GPU-k és az SSD meghajtókkal kapcsolatban várhatók. -
robyeger
addikt
válasz
robyeger
#1624
üzenetére
éjszaka elfelejtettem ismertetni a tesztkofigurációt:
-Athlon64 4000+ stepping F3 (ADA4000DHBOX)
-Asus M2R32-MVP (rev 1.02G)
-Corsair 2x512 DDR2-800 4CL/EPP (CM2X512-6400C4)
-ATI Radeon 1900XTX (Gigabyte GV-RX19X512VB-RH)
Adalékként: nekem nem sikerült stabilan 400Mhz Hypertransport alapórajelre felhúznom a rendszert, mint a prohardvereseknek, ott még látható lenne egy ideális "ütemezési" állapot. -
robyeger
addikt
válasz
Oliverda
#1625
üzenetére
K8-al kapcsolatban több komolyságot várnék tőled vagy ne is várjak
Nehalem-el kapcsolatban még elég kószák az információk: [link]
Fene tudja, hogy 3 memória csatorna lesz-e? vagy marad a régi 128bites 2mem csatorna és pluszban kapna 2db I/O hypertransporthoz hasonlót, Inteles nevén Quick patch ?
Mondjuk nekem személy szerint az a 192bit nagyon sántán hangzik... -
robyeger
addikt
Közkézre szeretném adni egymagos Athlon64-el végzett [tesztjeimet], azon indíttatásából és bizonyságul, miszerint nem a DDR2 memória szabvánnyal van a baj, mikor az AM2 procik alig tudják befogni hasonló paraméterekkel rendelkező 939-es társaikat.
Ha késleltetés és sávszélesség szerint nézzük a memóriákat:
[(Kiegészítő irodalomnak)]
DDR400(2CL): 3200Mb/sec 10ns
DDR400(3CL): 3200Mb/sec 15ns
DDR2-533(4CL): 4267Mb/sec 15ns
DDR2-667(5CL) 5334Mb/sec 15ns
DDR2-800(5CL) 6400Mb/sec 12,5ns
DDR2-800(4CL) 6400Mb/sec 10ns
DDR2-800(3CL) 6400Mb/sec 7,5ns
DDR2-1066(5CL) 8534Mb/sec 9,4ns
Látható egyáltalán nem rosszabb a DDR2 szabvány a DDR1-től, pedig ez az általánosan elterjedt közhiedelem AMD körökben. Mégis ha a WinRAR tesztre pillantunk kapásból kiviláglik, hogy az AM2 procik egycsatornás(single channel) módban jobban teljesítenek, hiába duplázódik meg a sávszélesség, ha dupla csatornás(dual channel) kiosztást használunk. +Összehasonlítás képen egy 2.4Ghz-es 939 procitól kétcsatornás DDR400-2CL késleltetés mellett 628Kb/sec tömörítési sebességnél nagyobbról még nem hallottam (de szívesen várok másoktól ilyen jellegű adatokat, pl. normál 3CL késleltetés mellett,stb..) A grafikus méréseknél ha nem is akkora különbséggel, de ugyan ez a helyzet. Szóval az AM2 procik nem tudnak élni a nagyobb memória sávszélességgel?! , viszont ha memória benchmark eredményekre tekintünk, nagy fölényt láthatunk az AM2 javára a 939-el szemben. (persze a CPU magórajel nagyságával arányosan nő csak az elérhető valós memóriasávszélesség is) Ezen tények ellentétesek egymással. A nagy kérdés miért is lehet ez?? Régen azt gondoltam ez valamiféle belső busz sávszélességből ered, amit az alapórajel határoz meg, a teszt erre rácáfolt, hiszen csak az alapórajel emelése nem hoz teljesítmény többletet, a másik ami meggyőzött a Sandra XI memória benchmark mérési eredményei pl. Athlon64 FX-74 processzorokkal, ahol 800Mhz memória társaságában 14GB/sec feletti értékek jönnek ki, ami meghaladja a 800-as dupla csatornás memória 12.8GB/sec elméleti sávszélességét. Természetesen az esetben a NUMA (Non-Uniform Memory Access) segítségével a másik processzor közelében lévő memóriaadatok Hypertransport(HTT)-on elért többletével jöhetett csak ki. Marad azon magyarázat, amit ütemezésnek neveznék. Amikor különböző frekvenciájú és bitszélességű buszok közt kell adatkommunikációt felépíteni(szinkronizálni), erre Intel platformon az alaplapi chipset a példa, ahol egy FSB : DRAM aránypárral szinkronizálnak, ideális esetben ez 1:1-hez, de ha nem, azaz különböző, akkor bizonyos eljárásokkal(adat-prefetch algoritmusok,stb…) próbálnak javítani a kihasználatlan ütemeken(ciklusokon). Márpedig az Athlon64-nél a DDR400 memória alapórajele pont szinkronban volt a HTT alapórajelével. 200Mhz-el. Viszont DDR2-nél 400Mhz-en nagyobb a késleltetésünk, 533 és 667Mhz-en pedig oda a szinkron. Könnyen belátható hogy ugyan rosszabb egy K8 proci DRAM vezérlője, mint akármilyen különálló chipseté, de el se várható tőle, mivel sokkal kisebb területen, kisebb melegedéssel, kevesebb tranzisztorszámmal nem tudják még annyi db vagy olyan hatékony optimalizáló-javító algoritmussal ellátni, mint szükséges lenne. De szerintem ez a probléma kisebbik része, a nagyobbik magában a K8 architektúrában keresendő. Ha a K7-es egy memória csatornás fogyatékosságát vesszük alapul, akár örökletes tulajdonságnak is nevezhetnénk. K8-nál ugyan is a memóriavezérlő köztudottan csak egybe képes kezelni a 128bit széles dupla csatornát és ott van a 128bites L2 cache tár is, ami megoszlik 64bit olvasásra és 64bit írásra. Intelnél a 256bites L2 cache-nél és a névadó 4 dugattyús tűzoltópumpánál (quad pump) 2x64bitet olvas és 2x64bitet ír egyidőben, tehát jogos a memória benchmark-oknál az a meggyőző jó olvasási képesség, de ha írni és olvasni kell egyidőben, főként nem lineárisan a memóriákból, akkor jócskán csökken a kommunikációs teljesítménye. A magyarázatból pedig egyértelműen következik miért is volt életképes a 754-es platform. 3D grafikával kapcsolatban az is felmerül, hogy míg Intel platformon a videó kártya a AGP és PCIE buszokon keresztül képes a CPU kihagyásával ergo kizárólag a chipset-en keresztül adatokat cserélni az alaplapi memóriákkal, addig K8-asnál? Szerintem az AMD fejlesztőmérnökei pont azon helyeken javítottak a K8 architektúrán, ami a leggyengébb részei. A K10-nél a memóriavezérlő órajele függetlenül állítható lesz a processzor magórajelétől, és a 128bitet már képes lesz 2 külön 64biten kezelni, a L2 cache-t 256bitre bővítik, 128bit olvasás és 128bit írás, végül a közös L3 cache, ami azért szükséges, mivel a K8-as X2 procik magjai marketing szerint képesek magórajelen kommunikálni, persze mert hardware-sen az osztott memóriavezérlőn keresztül összekötetésben vannak, de gyakorlatilag pongyola megfogalmazásban az „ütembe” már nem fér bele. A magok hamarabb jutnak az adataikhoz, ha a memóriából töltik fel, mint ha a másik mag gyorsítótárából kellene kiolvasniuk. Hiszem, hogy a K10 már ki fogja tényleg aknázni a dupla csatornás memóriák teljesítményét.
Gyakorlatiasan összefoglalva, a magórajel nagyságából adódóan lemérhetjük, hogy milyen olvasási teljesítményre képes K8-as procink, ha azt tudjuk egy memória csatorna felhasználásával prezentálni, akkor úgy lesz a legjobb. Vigyázat, mert 2 mag esetében, a memória benchmark-ok az együttes memória kommunikációs teljesítmény jelenítik meg, köszönhetően az osztott memóriavezérlőnek. Játékoknál bukhat ez ki igazán, ahol az szorosabban összefüggő adatok miatt nagyon nehéz 2 vagy több magra bontani az utasítások végrehajtását, ilyenkor ha minél több adatot vagyunk képesek egy magra vetítve juttatni a memóriából annál gyorsabb lehet a játékunk is. Ezért a DDR2-800 és az AM2 - 2400Mhz alatti processzor tulajoknak, mindenképp single csatornás memóriabeállítást javaslok.
A röhej az, hogy a K8 procikhoz tényleg a magas órajelű DDR3 memóriák lennének a legjobbak, igaz csak 1csatornás kiszerelésben. Az AMD marketing gépezete *5 érdemel, mond egy féligazságot, a másik negatív féligazságot pedig elhallgatja, így nem lehet ráfogni hogy hazudna. Érdekesség képen az Intel ezen fölényét a K10-el szemben a Nehalem architektúránál már 4db memória csatornában látja biztosítottnak. Kíváncsian várom a harc folytatását . -
robyeger
addikt
válasz
Zeratul
#1454
üzenetére
mivel elég síralmasan megy az Intel konkurensének az AMD-nek, így az Intel visszafogja magát fejlesztési tempóban, sajnos
Mert hogy az Enhanced Dynamic Acceleration Technology(EDAT) előzőleg minden Penryn procira be lett ígérve, erre csak az árbevétileg leghúzóbb mobil szegmensben fogja bevetni a cég. A későbbiekre (egyenlőre tartalékba helyezve) igéri a desktop és a szerver prociknál a bevezetését.
[Szerkesztve] -
robyeger
addikt
válasz
Oliverda
#1402
üzenetére
te nem vagy tisztában azzal, hogy a K8-nál mint jelent a processzor szorzója, ami ugye nem keverendő a HTT szorzóval, már belinkeltem neked minden általam ismert ezzel kapcsolatos infót, nem látom értelmét még1x megtenni, szóval további jó rajongást kívánok
(bizonyos szerver alkalmazásokban szerintem is rúghat labdába a K10, de az csak egy szelete az egész tortának ) -
robyeger
addikt
válasz
Oliverda
#1375
üzenetére
Olvastam az Xbitlab leírását és örülök hogy ha nehezen is csak megszületett egy más alternatíva az Intel procik ellen, vannak benne szép jövőbe mutató elméletek, de a jelenlegi gyakorlatban nem látok benne nagy átütő erőt, főleg nem az otthoni játék orientált felhasználásra, így szerintem az optimizmusod inkább töretlen, mint reális. Például egy Akosf-en és rajtam kívüli vélemény: [link]
-
robyeger
addikt
válasz
#21346560
#1275
üzenetére
szerintem a te méréseid is illenek a képbe
, hiszen a te 5600+ procidnak csak 89W a gyári fogyasztása a 6000+ 125W-val szemben, és a videó karid is jóval alul marad a 8800GTX-nek, másodsorban biztos vagyok, hogy a Stalker nem terheli le 100%-ra a procid mind2 magját, ha nem hiszed, indíts el alatta egy CPU terhelés monitorozó,logoló progit vagy próbálj két Prime95 mellett játszani és úgy mérd le a fogyasztást 
[Szerkesztve] -
robyeger
addikt
eddigi kérdezőknek: ha van pénzed már egy 4Mb cache-s Intel procira (E6320, E6420, E6600, stb...) és legalább egy olyan deszkára amivel jól húzható (min. Abit IB9, ami egyáltalán nem drága), persze itt is legjobb a P35 chipset, Abit IP35-E, Abit IP35, Asus P5K, stb..., (közép és felsőkategóriás 965chipsetes lapot már nem érdemes venni,mint pl: Asus P5B), szóval akkor egyértelmű a válasz, hogy jobb választás az Intel platform, mint az AMD. Alsóbb árkategóriában kis tuningal lehet versenyképes az AM2, de ott is csak a 65nm-es procijai, amik nem melegednek annyira.
[Szerkesztve] -
-
#1210
robyeger
addikt
VaniliásRönk
#1209
robyeger
addikt
válasz
VaniliásRönk
#1209
üzenetére
nem csak a PentiumD-nél gyorsabb, olvasd el fLeSs idézetet is. Amúgy lesz még itt több csővezeték, mind AMD-nél, mind pedig Intelnél, majd meglátod
[Szerkesztve] -
robyeger
addikt
#1123 hsz-re is: E6300 és E6400 procit már nem érdemes venni, helyette E6320 és E6420 a 4Mb cache miatt. Amúgy nem minden az órajel arányítás, hiszen az összes architektúrának van egy ''alapjárati'' sebessége, mikor a magok terhelése még 1pillanatra se haladja meg pl. a 60%-t, egyszerű műveleteknél, böngésző és egyébb ablakok nyitogatása, ami a mindennapi windows-hoz hozzátartozik, ebben jelenleg a Core2dou procik a leggyorsabbak, már a legkisebb E2140-t is beleértve, persze ezek 1másodpercen belüli nüánszok, ha nem lépnek közbe olyan magasabb rendű lassító tényezők, mint a memória méret szűkössége és a winyók sebessége, stb. Ezt az érzést próbálta leírni fLeSs, ezért is idéztem tőle. Én is elég sokáig kitartottam a PentiumD procim mellett, mert nincs szükségem nagy CPU teljesítményre, de be kell ismerni a Core2-n szinte minden egér kattintásnál érezni, hogy gyorsabb.
[Szerkesztve] -
robyeger
addikt
tele van a halo tesztekkel, messzire se kell menni érte: [link]
''A sok technológiai specifikáció, a sok újítás, amire az ember először csak legyint egyet, egy csapásra értelmet nyer, amikor azt érzi, hogy a keze alatt futó Core 2-es rendszer gyorsabb, mint egy Athlon 64 X2-es.'' by fLeSs
1re telett, az időm kevés, sorry Roby.
[Szerkesztve] -
robyeger
addikt
talán az autoiparban járatosabb vagy, ezért tételezzük fel; ha a turbó feltöltő teljesítmény növelő hatását akarnák vizsgálni, akkor nem az a minimum, hogy azonos hengerűrtérfogatú motorokkal teszteljük. (egyikben turbo, másikban a nélkül) Szerinted a több processzoros rendszer mióta van egy kategóriában az egy processzoros rendszerekkel?!
-
#1117
robyeger
addikt
TomBoy1986
#1112
robyeger
addikt
válasz
TomBoy1986
#1112
üzenetére
Gart, sikerült találnod olyan tesztet, ahol a kisebb cache-el rendelkező megelőzi a nagyobb cache tartalmazó CPU-t
Ez kb. az összes teszt 5% ahol ilyen előfordul, mert ha tovább nézegetnéd a Tom's hardware tesztjeit láthatnád az ellen példát. Már irtam neked, hogy minél több program egyidejű futtására vizsgáljuk a teljesítményt, annál jobban kijön a gyorsítótár méretének ereje. (erre 1db vagy 2db programteszteket hozol fel példának) Másodsorban az egy dolog van egy hardverünk, azt csak megfelelő szoftverrel tudjuk kihasználni, több tesztnél ütköztek már ilyen szoftveres csapdába, jó példa erre a Dual-Core Optimizer nevű windows patch is.
[Szerkesztve] -
robyeger
addikt
nem vinne rá a lelkiismeretem ha azt állítanám, hogy az AMD-vel jobban jársz, még ha nem is akarsz tuningolni.(de majd kedvet kapsz hozzá, hiszen megfelelő deszkával a Core2-ket gyerekjáték húzni) Az Intel 4Mb-os egyesített gyorsítótára brutálisan erős, a 2x512kb-al szemben, a 2Mb-os Intelnél már lehet vitatkozni, az 1Mb-os Inteleknél pedig alapórajelen még jobb választás is lehet egy AM2-s. Kétségtelen az is hogy egy számítógépnek általában nem a processzor a leggyengébb láncszeme, ezért hatalmasat akkor se tévednél ha egy magasabb órajelű és drágább 65nm AM2 procit vennél, viszont a 90nm-es AM2 prociktól mindenképp óva intelek, mert sokkal jobban melegednek a Core2-hez képest. Nekem aztán 8, hogy mit veszel, nem tartom magam fanatistának, csak érvekre és ellenérvekre akarom felhívni a figyelmedet
-
#1104
robyeger
addikt
TomBoy1986
#1096
robyeger
addikt
válasz
TomBoy1986
#1096
üzenetére
dicséretes hogy megmaradtak a fejedben a suliban elhangzott fogalmak, csak nem kellene a saját szájízed szerint összekötni őket vagy értelmezni. Ahelyett hogy dobálózol a ''mutual exclusion'' és a ''Data-Flow architecture'' kifejezésekkel, amik a többszálú(párhuzamos) utasítás végrehajtás(1mag vagy több mag) témakörét feszegetik és nem tartoznak szorosan a gyorsítótárak szervezése kérdéséhez.
Azt végképp nem értem mit akarsz bizonyítani az Everest eredményeiddel, bechmark szempontból eléggé kérdőjeles az 1szálon ''Streaming Non-Temporal Store'' eljárással mérő rutinja, de még itt is látszik az Intel 256bites cache fölénye. Ha valamit látni is akarsz architektúra jellemzők szempontjából javaslom a Sandra használatát. Szerinted a szintetikus benchmarkok primitív műveletei alatt milyen virusellenőrzés történik, elárulom semilyen. Szerintem csak akkor folytassuk tovább ezt a vitát, ha konkrét példát vagy dokumentumot tudsz mutatni arra, ahol a különálló gyorsítótár teljesítményben megelőzi az egyesített gyorsítótárazást. Nehéz lesz hiszen az adat allokáció nagyságrendekkel gyorsabban végrehajtó művelet, mint maga az adat mozgatása, és ha már adatot kell mozgatni az sokkal nagyobb ellenőrzést is kíván.
Gyuro!: mint már írtam 90nm-es Am2 procikat újonan semmiképp nem éri meg venned.
[Szerkesztve] -
#1095
robyeger
addikt
TomBoy1986
#1082
robyeger
addikt
válasz
TomBoy1986
#1082
üzenetére
biztos hogy nem kevered össze a hyper-threading technológiával?, ott lehetséges hogy bizonyos esetekben teljesítménycsökkenés léphet fel, de hogy a Core prociknál lévő egyesített gyorsítótáron alkalmazott Intel Advanced Smart Cache-nél bármi nemű teljesítmény csökkenés mutatkozna a független gyorsítótárrakkal szemben??
Erről még nem hallottam, megmutatnád hol olvastad?? Én nem tudok egyetlen egy ilyen esetről sem!
A kölcsönös kizárás(mutual exclusion) eseténél is, ugyan nem lehetség a több magon, azaz utasításszálon való végrehajtás, az adatösszefüggések(szinkronizációk) miatt, de ilyenkor az egyesített gyorsítótárnál 1mag akár megkaphatja a teljes gyorsítótár méretét, míg a független megoldásnál, csak a saját gyorsítótárjából dolgozhat, nem nehéz kitalálni ebben az esetben is ki lesz a győztes, hát nem a K8!
Furcsa számomra manapság dicséretet hallani a jelenlegi K8 magok közötti kommunikációról, hiszen most akarja az AMD a K8L-nél az L3 cache-el ezen gyorsítani, mert az igazság az hogy a 128bites L2 cache-ek csak alapórajelen tudnak kommunikálni egymással és nem magórajelen.
Éppen a gyakorlati életet próbálom magyarázni, mikor nem szűz win alatt futattunk játékokat, mint a publikált tesztekben. -
#1078
robyeger
addikt
TomBoy1986
#1074
robyeger
addikt
válasz
TomBoy1986
#1074
üzenetére
látom nem vagy tisztában, hogy melyik a jobb cache felépítés, előjáróban annyit, hogy az egyesített. a másik amire céloztam, hogy minél több külön program fut egy időben, annál jobban kijön a nagyobb cache méret előnye.
[Szerkesztve] -
robyeger
addikt
Vannak ilyen tesztek is: [link], nem mintha sokat kellene foglalkozni ezekkel a tesztekkel, ez ''szakmabeli'' embereknek mond valamit, hiszen szűz win alatt futtatni valamit vagy hétköznapi rezidens progikkal megtűzdelt (viruspajzs, tűzfal, stb...) win mellett tök más a helyzet. De ha a Core2 egyesített 4Mb-os cache mérete nem tudott meggyőzni, AMD-ből a 65nm-es 5200+ -nál nagyobbat nem szabad venni, mert azok jóformán ''áramzabáló hőkazánok'' a Core-hoz képest.
-
#980
robyeger
addikt
VaniliásRönk
#979
robyeger
addikt
válasz
VaniliásRönk
#979
üzenetére
az én szemem kitisztult pillanatában talán 20-25 képkockát felismer másodpercenként, de ha a tiéd jobb, esküszöm elmegyek a szemészetre
-
robyeger
addikt
[link], tuningal bármelyik fölékerekedhet a másiknak, játékok alatt alig érezhető a különbség, mivel a tesztben is jól látszik, közel sincs kihasználva a processzor teljesítménye, még 1magra vetítve is tikán közelíti meg a 100%-t. Client játékokra egyáltalán nincs szükség csúcs procikra.
-
#963
robyeger
addikt
VaniliásRönk
#957
robyeger
addikt
válasz
VaniliásRönk
#957
üzenetére
a E2xxx és E4xxx procinak 200Mhz az FSB-je, és egy átlag lap tudja gyárilag a 266Mhz FSBt, így 33% tuning a garantált. (az Asrock átlag alatti tuning terén) , amúgy megnézném azt a AM2 procit ami legmagasabb szorzón bírja a 300Mhz feletti alapórajelet
-
robyeger
addikt
ha már adott a ram, inkább Intel válasszál, mert az AM2-es procik a 667mhz rammal gyengén muzsikálnak. 33% tuningot garantáló olcsó deszka. pl: Asus P5L 1394, az integrált VGA megoldásnál, ha ideiglenes úgy is, szerintem jobb egy PCI VGA kari átmeneti megoldásnak vagy Asus P5L-VM1394 (ami integrált VGA-s), vagy megtartod a régi VGA karid egy Asrock 4CoreDual-VSTA deszkában, de ezzel csak minimális a tuning.
[Szerkesztve] -
#951
robyeger
addikt
VaniliásRönk
#949
robyeger
addikt
válasz
VaniliásRönk
#949
üzenetére
...de a 2140 valószínűleg elég gyengén muzsikál ha tuningra kerül a sor, nem mellesleg alacsony a szorzója, komoly alaplap kell alá még ha bírja is szuflával....
Ezt honnan vetted , a E2140-es kitünően húzható és a szorzója is magasabb, mint pl. E6300 vagy E6320-nak. -
robyeger
addikt
válasz
gamer_hun
#926
üzenetére
pl. Rome Total War játéknál két 4ezres sereg találkozásánál már 3.73Ghz 1magos P4-nél is beszagat, persze ha lekapcsoljuk a rezidens progikat, mint antivirus és tűzfal, javíthatunk a helyzeten. A mai játékoknál (Supreme Commander,stb...) gondolom még kritikusabb lehet a helyzete egy 1magos procinak. Szerintem aki nem sajnálja a VGA karira a pénzt, annak bőven futja belépő szintű dupla magos procikra is (pl: E2140 vagy X2 3600+)
Amúgy egy 800Mhz FSB procit 400Mhz-es dupla csatornás memória tud megfelelő mennyiségű adattal ellátni, ergo 1csatornán 800Mhz memória szükségeltetik, ha ennél több a memória órajele az javít a dolgokon, de ha kevesebb akkor nagyban ronthat a dolgon. -
#922
robyeger
addikt
VaniliásRönk
#919
robyeger
addikt
válasz
VaniliásRönk
#919
üzenetére
ennyi erővel a következő lottó nyerő számait is leirhatnád
-
robyeger
addikt
a képlet nagyon 1xű, lajikus felhasználónk hall valahol egy tesztet, hogy milyen jó a Pentium E vagy a Celeron 4xx procik, aztán mire eljut a boltba vásárolni, elfelejti pontosan mi is volt a neve ezeknek és az eladó még simán rá tudja sózni a régi PentiumD és Celeron 3xx procikat is, ő meg nyugodt szívvel hazamegy, hogy milyen jót vett.
Ez marketing, Intel helyében én is ezt tettem volna 
-
robyeger
addikt
PentiumE <nem egyenlő> PentiumD
A Pentium E procik Core2 alapokon nyugszanak, eddig két féle példánya létezik E2140 és E2160
A K8 témát sikerült elég részletesen kivesézni, a crossbar-nak semmi baja (magórajelen futkosó 64bit széles fullduplex drótozás), a 200Mhz alapórajel és 128bites cache együttes hatása a baj forrása a k8-nál -
#830
robyeger
addikt
Deathmatch
#828
robyeger
addikt
válasz
Deathmatch
#828
üzenetére
majd veszel bele egy PentiumE procit és röhögsz egyet a K8-on
-
robyeger
addikt
válasz
Oliverda
#781
üzenetére
P.H.-val már tisztáztuk, hogy a ''Streaming Non-Temporal Store'' eljárás kikerüli az L1/L2 cache tárakat, így ez nem dönti meg a 6.4GB/sec adatlimit megállapításomat.
Az általam linkelt Sandra tesztben ne keress DDR1 memóriát
1magosokat hasonlítsd azonos órajelen futó 2magos testvéreikhez. -
robyeger
addikt
-
robyeger
addikt
válasz
Oliverda
#773
üzenetére
a ''core''(mag), kifejezést nem igazán a multi-processzoros környezet megfogalmazására használják. Amúgy is gyorsítótár koherenciáról van szó és memóriakezelésről, a HTT csak később említik. Az hogy magyarul se értjük egymást, de hogy angolul se, ezt tényleg csúcs!
Elárulom a normál DDR2-800 ramnak 533Mhz-en már 3CL késleltetése van alapfeszültségen. -
-
robyeger
addikt
Miért akarja az AMD a K8L-nál kiszélesíteni a 128bites L2 cache-t 256bitre?
Miért akar L3 cache-el egyesíteni a 2db L2 cache-t, ha úgy is magórajelen tud kommunikálni egymással a két L2 cache?
Mert ha belegondolunk a cache mindig is azt a célt szolgálta, hogy ha lassú egy busz, akkor az adatok pufferelésével javítson a feldolgozás hatékonyságán. De az AMD állítása szerint ez magórajelen történik, az nem lehet lassú, amúgy is a 3.szintű gyorsító tár a nevéből is eredően lassabb, mint egy 2.szintű.
A válasz lehet hogy sokkoló egyesek számára, de a valóság az, hogy K8-nál a két mag csak 6.4GB/sec tud egymással adatot cserélni, hiszen magonként az adatkapcsolat az SRQ között 200x2x64/8=6.4GB/sec, mivel 2db 64bites buszon 200Mhz-es alapórajelen történik az adatáramlás. [link]
Many industry insiders have commented that the K8 is eerily reminiscent of the ill-fated Alpha EV7. The EV7 augmented a high performance core with on-die directories for cache coherency and four interprocessor communication links operating at 6.4GB/s each. The EV7 also incorporated two memory controllers supporting eight channels of RDRAM, a total memory bandwidth of 12.8GB/s per processor. Like the EV7, the K8 enhanced on a prior generation design; adding a memory controller, and three Hypertransport links.
A K8L-nél a megduplázott L2 cache sávszélességgel, már 1magba is eljuthat akár dupla csatornás 800Mhz-es ramok ereje is, K8-nál csak a fele.
Na most ez a 6.4GB/sec limit csak kifejezetten adatokra vonatkozik, más egyéb utasítások, állapotjelzők tényleg magórajelen közlekedhetnek a magok között. Tehát az AMD nem hazudott, csak kicsit ferdített, elhalgatva a részleteket. Mikor Netburst processzorok szorzózár ügyében nyomoztam, megtapasztaltam, hogy az Intel-t se kell ilyen téren félteni, a lényeg hogy ne vegyünk be szószerint minden hangzatos Marketing szlogent.
Kedvenc AM2 tesztem: [link]
A SiSoft Sandra 2007 - Memory Bandwidth Benchmark táblázaton jól látható a dolog.(1magosak vs. 2magosak.)
Ez közre játszik abban, hogy DDR2-800 memóriával tudja felvenni a versenyt az AM2 a 939-es DDR400-al szemben.
[Szerkesztve] -
robyeger
addikt
Hiába guglizok itt nektek, legalább vennétek a fáradságot, és 1x végigolvasnátok a linkjeimet
[link]
The memory controller is connected with a 64bit bus working at the CPU frequency with the X-bar (and the latter with the processor's core) - at 2 GHz it results in 16 GB/sec. Now they can add any memory type - there is no bottlenecks between the memory controller and the processor. Such throughput system is superfluous for any existent memory type - but it seems that it was simpler to develop it than to think out a special bus between the X-bar and the controller.
Írtam kiegészítés képpen, hogy lehet kommunikáció a két mag között utasításokban, állapotjelzőkben az adatlimit felett is ''akár magórajelen'', de adatcsere szempontjából max. 6.4GB/sec.Amúgy ezektől a sz@r marketing ábráktól tudok kiakadni: [link], a valóságban igy fest: [link], tehát a IMC és a HTT összekapcsolódik az SRQ-ban, mielőtt további kapcsolatot teremtene a cache-tárakkal és nem úgy, mint a marketing ábra két átellenes végén
Ha szerinted azért nincs egyesített cache-tár A64-nél, mert Write Through, legyen, szerintem nem csak ilyen apróságon mulik, hogy Write Back vagy Write Through, ezen nem veszünk össze, nincs kellő infóm a dologról.
''non-temporal store/write'', az a lényeg, amit te írtál; kikerüli az L1/L2 cache-tárakat, én nem kívánok programozás szintjén foglalkozni vele.
[Szerkesztve] -
robyeger
addikt
lányos zavaromban elírtam
, jó hogy szólsz
200x10, 5x HTT, 500 ram =nem <> egyenlő=250x8, 4x HTT, 500 ram
igen régebbi BIOS-oban úgy jött fel, mint választható opció, hogy ''4/5'', ez az eredeti doksiban is benne van, de tudott, hogy a magórajel/a memóriabusz órajelével képezi a K8 a memória sebességét, (ezt már én is tudom, már át estem ezen a fejlődési ponton) , főként AM2-nél látványos ez nem egész memória osztók esetében, ami nem lehetséges így a legközelebbi kisebb egész osztót választották AMD-ék.
[Szerkesztve] -
robyeger
addikt
Igen ez már később jött az ''E'' reviziós venice-ekkel, ezért bizonyos deszkánál nem állítható be a DDR500, 200Mhz alapórajel mellett, persze minden tuningképes deszkánál és A64-es procinál beállítható a alacsonyabb szorzó és 250Mhz alapórajel. Ezzel nem mondtunk egymásnak újat, azt írd amivel nem értesz velem egyett, mert
200x10, 5x HTT, 500 ram =nem
egyenlő=200x8, 4x HTT, 500 ram
Kapis? -
robyeger
addikt
válasz
Oliverda
#756
üzenetére
Tudod engem mindig hajtott az ismeretlen, amit nem tudok és ha azért hogy némi infóhoz jussak be kell vállalni a hülye szerepét, örömmel eljátszom.
Egymás szubjektív megítélése és hasonlatokkal illetése érdektelen egy szakmai topic-ban, szerintem.
Sose jutott még eszedbe visszább venni a procid szorzóját?, mit bír FSB-ben a deszkád?, mert hát adott nálad egy Opteron1214-es, ami bírja a 3Ghz-t is, ha jól látom, a leg ideálisabb tuning állapot teljesítmény szempontjából a gépednek 500Mhz-es alapórajel lenne, azaz 6 szorzóval, HTT szorzó 2-n, memória 1Ghz-en, ugyan is 3000x64/8=24GB/sec,amiből levonjuk a 8GB/s HTT, maradna tisztán 16GB/sec, ami pont a 1Ghz ram dual channel-el egyezik meg. Soft-osabb megoldás a 333 alapórajel, így 9 szorzó, 3 HTT szorzó. memó szintén 1Ghz-en, habár itt már a 667Mhz alacsonyabb késleltetéssel jobban jársz. Ez a három variáns mind1ke jobb lesz, mint ha 272x11 hajtanád a procit 1088Mhz-es memóval. ...már így is bőven sokat segítettem .... -
robyeger
addikt
válasz
Oliverda
#754
üzenetére
A feladványodban pedig nincs mit megoldani, mivel tök mindegy hogy mennyi az External Clock, meg az is mindegy hogy milyen osztóval jön ki a mem. frekvenciája. Az eredmény a fontos. Tehát ha CPU Clock 5x400-ból tevődik össze, és mellette 500Mhz-n mennek a RAMok, akkor is hajszálra olyan gyors lesz a rendszer mintha 10x200-ból hoznánk ki a CPU Clock-ot, és mellé egy olyan osztót állítanánk be, hogy 500Mhz-n üzemeljenek a RAMok.
Ez nem igaz, és a tesztek 200-as alapórajel(FSB) és 400Mhz-nél magasabb memória sebességekről ott van csak lapozni kellene. A tuning példára a keresést rád bízom, külön topic is indul ennek a nyomozására itt a P.H.-n, nem én nyitottam, de én voltam a felbujtó
[Szerkesztve] -
robyeger
addikt
válasz
robyeger
#749
üzenetére
kiegészítés: ahogy olvasgattam a System Request Queue (SRQ)-ról, hogy is lehetne ezt magyarra fordítani
talán ''rendszer folyamat rendező'', szóval amit irtam 6.4GB/sec limirtől a magok felé az kifejezetten adatokra vonatkozik, tehát közben utasítások, állapotjelentések, stb... áramolhatnak a magok között vagy kifelé a IMC és a chipset felé, így tényleg nem beszélhetünk klasszikus FSBről, mint Intelnél, de limitek vannak mindenre, ha más nem külön-kölün, mert olyan csak a mesében van, hogy határ a csillagos ég! -
robyeger
addikt
válasz
Muad-Dib
#748
üzenetére
én láthatatlanba az olcsóságot beleszámítva inkább a Turion felé voksolnék, mert szűkös FSB-ken kevésbé jön ki még a Core2 ereje is, viszont az integrált memóriavezérlők ilyen alacsony környezetben jobban szerepelnek, habár a pontosabb képhez mindenképp kellene a memória felállása hány darab modul és milyen sebességű?
-
robyeger
addikt
válasz
#65675776
#745
üzenetére
Oliverda és Zeratulnak is: Ti kergettek ábrándokat (vagy sose tuningoltatok K8 rendszert) azzal kapcsolatban, hogy az alapórajel az a bővös 200Mhz, csak a HTT alapórajelének beállítására szolgál. Akkor az összes diagnosztikai programok is az írnák pl. a 2.4Ghz A64-re, hogy 1000x2.4, már leírva is nevetségesnek tünik. Adok egy feladványt, ha ezt nekem részletesen meg tudjátok magyarázni hogy nem úgy van ahogy fentebb gondolom, akkor elismerem, hogy tévedek. tehát itt van a 939-es venice ''E'' reviziós magok DDR500-as támogatása: [link], pl. Athlon64 3200+-nál, miért hoz alig valamivel többet, ha 500Mhz-re állítjuk a memóriát, de mellette marad a 200-as alapórajel?, viszont ha levesszük a szorzót 10-ről 8-ra és a HTT szorzót 5-ről 4-re, alapórajelet felemeljük 250Mhz-re jelentősen gyorsul a rendszerünk sebessége?
(direkt nem akartam belekeverni az AM2 (DDR2)-t, ne hogy arra fogjátok )
[Szerkesztve] -
robyeger
addikt
Ha jól látom abban egyetértünk, hogy a belső felépítése a K8-nak hasonlatos a K7-hez, annak egy továbbgondolt verziója. Mit dupláztak meg: pl: az L2 cache szélességét és a TLB-t.
Igazad van az XBAR is magórajelen működik. Méghozzá 64bites keresztkapcsolatot épít ki az IMC, az SRQ és a HTT között. (A corssbar-k amúgy se szoktak bonyolult szerkezetek lenni, csak sok-sok vezeték keresztbe-kasba kötözgetve.)
pl. egy 939-es Athlon64 3200+ proci esetében 2000Mhz x 64bit/8bit = 16GB/sec., ez azt jelenti, hogy az SRQ felé 8GB/s érkezik a HTT felől, tehát marad 8GB/sec a memóriának. mondjuk DDR400-al semmi gond nincs, hiszen dual channel-ben, 2000/200 azaz 10 memóriaosztóval csak 6.4GB/sec sávszéligényt generálhat. Érdekesebb a helyzet, ha megnöveljük az alapórajelet(FSB-t) 200-ról 250Mhz-re. A processzor szorzót 10-ről 8-ra csökkentjük és a HTT szorzóját is 5-ről 4-re. Ilyenkor csak a memória sávszélünk növekedet 250x2x(64+64)/8=8GB/sec. Így viszont már az SRQ felé telítettük 8Gb HTT + 8Gb IMC = 16GB/sec buszt, ha tehát a 8-nál is lejjebb vennénk a szorzót és több növelnék az alapórajelet, memóriaátvitel szempontjából többletet nem érnénk el. Végre teljesen világossá és számolhatóvá vált számomra az egyik korlátozó tényező,régen ezt önkényesen ''teljesítményvisszahajlásnak'' neveztem el, ha te nem is mások biztosan emlékeznek , miszerint a memóriaátvitelünk nagyban függ az FSB mellett a magórajel(de beszélhetünk szorzóról és memóriaosztóról is) nagyságától. egy másik példa: Am2 Athlon64 3800+
2400x64/8=19.2GB/sec. memóriaosztó 800-as rammal 2400/400=6, (habár ez egy félhivatalos memória osztó, mert a processzor adatlapja szerint csak 667Mhz-ig támogat DDR2 memóriákat. Miért is van ez így, hamarosan leírom), tehát dual channel esetén a memória busz sávszélessége 400x2x(64+64)/8=12.8GB/sec. Ha levonjuk az SRQ felé haladóból a HTT sávszélességét, akkor 19,2-8=11.2GB/sec. Ez azt jelentené, hogy tekintélyes mennyiségű adat tudna beáramolni az L2 cache-tárba, de a Sandra 2007 valós memóriasávszél mérése más mutat és az a tény is, hogy egy 667Mhz-es ram társaságában se képes elérni a 939 tokozású testvére DDR400-al karöltve elért eredményét.
Akkor nézzük a másik korlátozó tényezőt(ahogy te nevezted szűk keresztmetszetet). Ott tartottunk, hogy Magórajelen és 64bites buszon a HTT és a IMC adatok eljutnak az SRQ-ba. Eddig én se gondoltam volna(pontosabban rosszul gondoltam), de itt történik a felszorzás, pontosabban a magórajel 200Mhz-es csoportokba rendezése. pl. 2.4Ghz-es processzoruknál maradva 200x14. továbbá az SRQ feladata a két mag közötti kapcsolat tartás és feladatmegosztás, hiú ábránd lenne azt hinni, hogy a két mag magórajelen tud egymással kommunikálni, ha ez így lenne, akkor már ott is lenne az egyesített L2 cachetár, mint a Core2-nél, de a K8-nál ez a kommunikáció 200Mhz-en és 2x64bit folyik, ennek a sávszélessége 6.4Gb/sec.![[kép]](http://www.ixbt.com/cpu/amd/hammer-series-arc/hammer-core.gif "[kép]")
Ezért is szokták egy bekeretezett egységként feltüntetni a SRQ,XBAR,IMC és HTT-t, mert ezek magórajelen működnek, de két végükön az SRQ a magok felé és a HTT a chipset felé már csak 200Mhz-es csoportokban(alapórajelen) kommunikálnak. Ezért van az, hogy a Sandra 2007 mérések 1magos AM2 procinál sosem haladják meg bármelyik 800FSB Pentium processzor valós memóriasávszélességét, mert azok is 6.4GB/sec elméletivel kommunikálnak. Így hogy magonként 6.4GB/sec limitáció van, még is hogy mérhet ennél többet az Everest, ezen sokat gondolkodtam, de mivel azt írtad, hogy a ''Streaming Non-Temporal Store'' utasítás, aminek nagy része az SSE1, teljesen megkerüli a L1/L2 cache-ket, akkor egyértelmű, hogy megkerüli ezt a 6.4GB/sec limitációt is, hiszen közvetlenül a magban max. a TLB-ben, mint virtuálisan megcímzett adatokként lehetnek jelen, azaz fizikálisan nem is áramolnak át a főbb végrehajtó egységeken. Ezért is lehet, hogy pár verzióval előrébb az Everest még Core2 proci esetén is a tényleges elméleti memóriabusz sávszélességén nagyobbat mért a proci FSB-jén, ami teljesen valótlan és nevetséges. Mivel ez a ''Streaming Non-Temporal Store'' nagyon speciális eset, és tényleges adatáramlást nem valósít meg a főbb egységek között (csak az SRQ és az IMC +HTT között), én nem tekintem processzor számára elérhető valós memóriasávszélesség mérésére alkalmas dolognak.
Visszakanyarodva a K7-hez és annak 3.2GB/sec FSB-ből következő 1csatornás(single-channel) memória kihasználtságára, így már érthető lehet K8-nál a magonkénti 6.4GB/sec limitáció a 754 tokozás szükségessége(életképessége).
[Szerkesztve] -
robyeger
addikt
válasz
robyeger
#727
üzenetére
A K8-as architektúra titkai, mi az a 200Mhz FSB(alapórajel):
A történetet a megértés céljából érdemes a K7 procik utolsó példányainál kezdeni, itt is 200Mhz-es alapórajelet alkalmazott az AMD alpha EV6 rendszerű előoldali buszon(FSB), így effektív 400Mhz FSB kapunk, azaz 400x64/8=3200Mbyte/sec a busz elméleti sávszélessége. A kaput a K7-nek az tette be végleg, hogy az Intel is bevezette a 200Mhz FSB a procijainál, ott viszont a quad pump-nak és a 256bites cache-nek köszönhetően az effektív órajel 800Mhz FSB, így 800x64/8=6400Mbyte/sec a sávszélessége. Tehát ha 1db(single channel) 400Mhz DDR memóriát használtunk a K7 procinkhoz, akkor az pont kielégítő a CPU számára, mert 400x64/8=3200Mb/sec ugyan ennyi sávszélességet kapunk a DDR400-as memóriára, ezért is nevezik PC3200-nak, viszont ha már 2db(dual-channel) memóriánk van, akkor ugyan nem tud a K7 proci 3.2Gb/sec többet fogadni, de már az AGP busz is lehetővé teszi a videókártya GPU-ja számára, hogy a CPU kihagyásával adatokat kérjen az alaplapi DDR memóriáktól, így tehermentesítve a CPU-t.
A K7 nevezhetnék akár Athlon32-nek is, de miért is; AMD-k leegyszerűsítve a dolgot megduplázták egy K7-es procit, így kaptak egy K8-as Athlon64-et. így könnyű kitalálni, hogy ha maradt a 200Mhz-es alapórajel, akkor 400x2x64/2=6400Mb/sec kapunk az elméleti sávszélességre. Volt itt azért még jó pár apró kisebb nagyobb fejlesztés is, de legfőbb változás a Integrált memóriavezérlő(IMC) behelyezése a processzorba. Ennek van jó és rossz oldala is, ha a DDR memóriákból akarunk adatokat a CPU-ba juttatni, akkor jó, mert rövidebbek az utak, de ha a videókártyánk az alaplapi DDR-ből szeretne adatokat, míg Intelnél és a K7-nél a CPU-tól függetlenül történhetett meg az adatáramlás, addig itt kénytelen kelletlen a CPU is át kell áramolnia az adatoknak. Mivel a K8 procink végrehajtó egysége csak 6.4GB/sec adat befogadására képes, ezért létrehozták a crossbar-t, ami lehetővé teszi, hogy a grafikus port felé menő adatok ne terheljék magát a végrehajtó egységeket(az L2 cache-t).![[kép]](http://www.xbitlabs.com/images/cpu/hammer-preview/pic6.jpg "[kép]")
A corssbar(xbar) feladata összeszinkronizálni, lebonyolítani az adatáramlást a Hypertransport(HTT), a IMC és a System Request Queue(SRQ) között, az SRQ pedig az L2 cache tárakkal és végrehajtó egységekkel közvetlen kapcsolatban van. Így keresztkötéssel létrejött a SRQ-ból egy 6.4GB/sec csatorna(ág) a HTT és egy másik 6.4GB/sec csatorna(ág) az IMC felé. Mivel a 200Mhz-es alapórajel és a 64bit buszszélesség behatároló tényező az SQR számára, célszerű volt az IMC-t a processzor magórajelén üzemeltetni, mert csak így képes egyszerre ellátni(betömni) akár extrém esetben a 6,4GB/sec L2 cache adathiányt és a HTT fellépő 8GB/sec adathiányt, ezek együttes összege 14.4GB/sec is lehet. 2db végrehajtó egység esetében (2magnál) pedig már 20.8GB/sec. mivel ügyes húzás volt az AMD részéről, hogy osztott IMC-t (shared IMC) alkalmazott a dupla magos processzorainál, ami azt jelenti, hogy a kibővített Xbar és az SQR egyenként tud a magoknak 6.4GB/sec biztosítani. Viszont a gond megint ott kezdődik, hogy van egy 64bites csatornánk a XBAR keresztül az IMC-től, de dual channel memória alkalmazásánál, 128bitet kell 64bites csatornákba gyömöszölni. Ez a hátrány szülötte pl. a 754-es tokozást ahol csak single channel memóriakezelést alakítottak ki. 939-nél DDR400-nál megvan az a szerencsés esetünk, mikor az SRQ-hoz vezető 6.4GB/sec csatornánkba pont beilleszthető 2db egyenként 3.2Gb/sec sávszél(PC3200). viszont ha ezek a sávszélességek nem esnek szinkronba, megtapasztalhatjuk az IMC pocsék Prefetch logikáját,a következő szinkronban állás a DDR2-800 memória esetében áll fenn, mikor 1 memória csatornára esik 6.4GB/sec. Ezért is kell az AM2 rendszerek hatékony működéséhez 800Mhz-es memória. Ebből következik, hogy 1magos AM2 prociknál leszámítva a 3D alkalmazásokat, mikor a Videókártya a HTT keresztül kérne nagyobb tömegben adatokat a DDR2 memóriáktól, 800Mhz-es single channel is tökéletesen kielégítő a CPU számára. De mivel az AMD is dual channel-ben kénytelen gondolkodni, hivatalosan csak 667Mhz támogatással látták el az 1magos AM2-t. Ugyan ezen jelenségből kifolyólag a Venice ''E'' magoknál bevezetett félhivatalos DDR500-as támogatást se verték nagy dobra, csak úgy volt hatékony ha az alapórajelet a memória alapórajeléhez igazítottuk (250Mhz). Biztos sokan észrevették már, hogy a magórajel nagyságától(szorzótól) is függ a valós memória átvitelünk, nem is csoda hiszen az IMC a magórajelen működik. Ezért alacsony szorzószámnál és viszonylag magas alapórajelnél már nem tud növekedni a valós memória átvitelünk. Tehát pl. 2Ghz-nél hiába akarna az AMD 250 vagy ennél nagyobb alapórajelet alkalmazni, a valós átvitel alig vagy inkább nem növekedne. Hogy még érdekesebb legyen a dolog nézzük a memória benchmárkok szemszögéből a K8 procikat. Sandra 2007 már képes két szálon mérni a valós memória sávszélességet, ezért itt jól látható a 6.4GB/sec limitáció, pl. megfelelően magas órajelű 1magos AM2 proci és 800-as dual channel memória használat esetén is, míg az Everestnél talán rajtam kívül másnak is feltünt, hogy a v2.8 verzió-ig a 2magosokra se tudott 6,4GB/sec fölött mérni, majd a V2.8 verzió után már 1magos Athlon64 esetén is meghaladta az általa mért valós sávszélességet a 6.4GB/sec. Mert az Everest csak 1szálon tud mérni, így az osztott IMC-t a dupla magos procik esetén hagyományosan nem tudja kihasználni, mint a régi verziók, viszont az új verziókban már ugynevezett ''Streaming Non-Temporal Store'' eljárást használnak a mérésre, ez azt jelenti, hogy adatki/behozatalkor a memóriába nem csak a hagyományos 6.4GB/sec csatornán az SRQ és az IMC között áramolnak az adatok, hanem a maradék részük kerülő úton a HTT csatornán keresztül próbál eljutni az IMC-ig. Ez vitatható szerintem és a Sandra írói szerint is, hiszen az Everest az adatok célba jutásának idejével már nem foglalkozik, csak teljes betöltés és kitöltéssel. Angol irodalmak: [link], [link], [link]
Részemről eddig ennyit tudtam meg és utólag is bocs mindenkitől, ha régebben valótlanságokat beszéltem ezzel a témával kapcsolatban, de idő kellett hogy eddig a szintig is ''megértsem'' Mellékesen az Everest jól elvitt a sötétbe. Ha valaki másról vagy ezek kiegészítésről képes meggyőzni, várom észrevételét. -
robyeger
addikt
Csak nem te is fudzilla rajongó vagy
Egyenlőre az AMD 65nm-en 2x512Kb cache-nél többet nem tud felmutatni, akkor hogy akar L3 cache-s procikat gyártatni. A 3600+ kis windsor szörnyszülöttet inkább hagyjuk, mert hála az égnek már a multé. Sajnálnám az AMDt ha kipurcanna, mert az Intel egy monopolpiacon csak drágulna a felhasználok felé és a fejlesztési tempó is lassulna.
PentiumD: #726 hsz. ennyit tud se többet se kevesebbet.
Az K8 architektúránál már kezdetben is léteztek eredendő problémák(hátrányok), amik a DDR2-vel és a 6,4GB/s magasabb memóriasávszélnél csúcsosodtak igazán ki. [link]
IMC: az elmélet szép, de a jelenlegi AMD-s megvalósítás primitív, nem hiába DDR1-400Mhz rammal élte fénykorát. Prefetch logikája csapnivaló egy valamire való Intel platformos északi hídhoz képest. Egyszerűen ha a proci 200-as gyári alapórajelétől eltér és nem az egész többszöröse a memória alapórajele pocsék összteljesítményt nyujt, ez már megmutatkozott régen is a DDR266 és DDR333 időkben. Másik nagy hátránya a Hypertranszport és a processzor alapórajel kényszerű házassága,rájátszik a 128bites cache és az XBAR is. E dokumentum szerint az XBAR az IMC-t és a tényleges végrehajtó egységeket csak 64biten köti össze, ez megmagyarázná, hogy Sandra2007 memória benchmark programban, miért nem tud egy 1magos Atholn64 6,4GB/sec-nél nagyobb valós sávszélt produkálni. Az X2 tudnak ennél nagyobbat, de csak az osztott IMC miatt azaz csak a két magra összesen. A jelenlegi felépítmény korszerűtlenné vált. Az AMDnek kell a JEDEC-hez alkalmazkodnia nem fordítva. Remélem kijön a K10, kíváncsi vagyok ott hogyan javítják(fejlesztik) a crossbar-t. AZ L3 cache-től én nem várok csodákat, volt már a világtörténelemben L3 cache-s aztali proci, tuti hogy ettől az Atholn64 nem fogják felvenni a versenyt a Core2 procik egyesített L2 cache-tárával, persze a jelenleginél biztos jobb lesz.
Kár lenne fekete-fehérben nézni a világot, azaz a hobby számítástechnikát AMDben vagy Intelben nézni, mind1knek van előnye és hártánya is, jelenleg az AMD több hátránnyal küzd és ennyi -
#726
robyeger
addikt
VaniliásRönk
#723
robyeger
addikt
válasz
VaniliásRönk
#723
üzenetére
egy D915 könnyűszerrel felhúzható a Hyper-threading leszámítva egy Pentium 965XE proci teljesítményére, ezután esetleg majd így nézegesd a teszteket. Persze most annyira olcsó AM2, hogy belépő szintre én is azt ajánlom, D915 csak egy köztes lépcsőnek a Core2 felé, de ha tényleg olyan olcsók lesznek a PentiumE procik ahogy ígérik, akkor nem fogok tudni mire és hova ajánlani AM2
-
#721
robyeger
addikt
VaniliásRönk
#720
robyeger
addikt
válasz
VaniliásRönk
#720
üzenetére
Természetesen a VGA limit miatt játékra elég egy PentiumD vagy AMD X2 is ebben egyet értünk, de a körítés nem drágább egy LGA775 procihoz, mint egy AM2-hez.
-
#719
robyeger
addikt
VaniliásRönk
#718
robyeger
addikt
válasz
VaniliásRönk
#718
üzenetére
ahol én néztem az Abit KN9-S deszkát 18eFt brutto, egy Asus P5L 1394 (19eFt brutto) + E4300, a proci 266x9=2.4Ghz szerinted ezt a AM2-esed még ha húzod is meg fogja majd?
[Szerkesztve] -
#717
robyeger
addikt
ballington
#714
robyeger
addikt
válasz
ballington
#714
üzenetére
szerintem ha tuningolni akarsz AM2-nél, akkor ott is többet kell fizetned a deszkába, ha nem kell tuning Core2-nél ott is vannak olcsó Asrock és stb.. lapok
Írj egy konkrét AM2 lapot összevetjük árban.
[Szerkesztve] -
#713
robyeger
addikt
ballington
#711
robyeger
addikt
válasz
ballington
#711
üzenetére
szerintem csak a proci drágább a körítés nem
-
-
#703
robyeger
addikt
ballington
#699
robyeger
addikt
válasz
ballington
#699
üzenetére
szerintem vagy X2 3600+ brisbane magos vagy esetleg X2 3800+ windsor, ennél több pénzt már csak a Core2 E4300-ra szabad költeni, ettől kezdve pedig E6320, E6420, E6600 ahogy anyagilag győzöd
800-as memó egyedül az E4300 kivételével mind1khez javasolt, de 667-es ramnál inkább 945 vagy 975 chipset javasolt
[Szerkesztve] -
robyeger
addikt
válasz
MZsoltee
#677
üzenetére
Szerintem eddig a világtörténelemben az E4300-as proci a legkönnyebben tuningolható 266x9=2.4Ghz-re biztosan. Ezt valószínűleg már csak a hamarosan érkező PentiumE döntheti meg vagy E4400. Persze mint minden tuninghoz, megfelelő alaplap szükséges, ahol lehet állítani a megfelelő paramétereket a BIOSban. Már alapon is elég erős E4300-as. De ha van pénzed és igényed E6600-tól javaslok. Szűkre szabott pénztárcára pedig a 65nm X2 3600+-t.
[Szerkesztve] -
#613
robyeger
addikt
VaniliásRönk
#611
robyeger
addikt
válasz
VaniliásRönk
#611
üzenetére
[link]
The E4300 does well for its price here, even beating an AMD 5000+ X2. -
robyeger
addikt
Intel Core2Dou E4300 procit vegyél még olcsóbb is, mint egy X2 5000+
vagy javaslom a AMD X2 3600+ 65nm procit és a megspórolt pénzt öld a VGA-ba, hiszen a 7900GT nem egy csúcs kártya, így játékoknál még középkategóriás procival is előbb fogsz VGA limitbe ütközni.
[Szerkesztve] -
robyeger
addikt
természetesen a Windsor magos 3600+ gondoltam, hogy az kerülendő, hiszen már az ''amdcompare'' weboldalán sincs rajta az a kis Windsor szörnyszülött
Amúgy is inkabb a 65nm proci vásárlása javasolt, habár kicsit nevetséges számomra, hogy nem tudnak 2x1Mb cache-t összehozzni a kisebb csíkszélességen, reméljük a K10 architektúrára gyúrnak és már ilyen apróságokkal nem is foglalkoznak.
Mindig is tudtam, hogy ritka hülye jelölési rendszere van az AMD-nek!
[Szerkesztve] -
#596
robyeger
addikt
Mákosmetélt
#594
robyeger
addikt
válasz
Mákosmetélt
#594
üzenetére
Hali! Én is SirIQ álláspontján vagyok
, most olcsó az AMD vegyél azt, viszont a X2 3600+ felejtős, mert alig olcsóbb, de a felezett cachetár miatt főként párhuzamos programfutásoknál jóval gyengébben muzsikál. A D820 a melegedés miatt megint felejtős, D915 pedig csak akkor éri meg manapság venni, ha már adott a deszka vagy egy köztes lépcsőnek tekinted a Core2Dou procik felé.
AM2-höz mindenképp 800Mhz-es ramot vegyél, a D915 és majd a E4300 procikhoz elég akár a 533Mhz-es is. (memóriákban sincs már nagy árkülönbség) -
#588
robyeger
addikt
VaniliásRönk
#587
robyeger
addikt
válasz
VaniliásRönk
#587
üzenetére
igen, de ha a legújabb proci tokozásokhoz nem is ilyen létezett(létezik).
-
robyeger
addikt
hamarosan kijönnek az asztali 1333Mhz FSB Intel procik és chipsetek, akkor mégint esni fog. AMD-nél is most esett a gyártói lista ár, várni kell még hogy elérjen kis hazánkban. (én nyárra/végére/ prognosztizálom a legoptimálisabb árakat, ha nem csúsznak az új hardverek) Olcsó most az AM2 kétségtelen, de mivel nálad nem látom szükségét a deszka cserének, 2GB is általánosan elég, nem hiszem hogy megéri átnyargalnod AM2-re.
Szóval vagy új E4300 proci vagy ha DDR1-es ramod van, azt cserélném DDR2-re tekintettel a jövőre. -
robyeger
addikt
-
-
robyeger
addikt
válasz
alienpapa
#440
üzenetére
attól függ konkrétan mire gondolsz?
-A 64bites memóriacímzés(EM64T) elsőként a Pentium 4 - 5x1 processzoroknál alkalmazták
-ha a processzor rendszer sín szélességére gondolsz, akkor az első 32bites a 80386 processzorok voltak és az első 64bites a Pentium 1.
[Szerkesztve] -
robyeger
addikt
válasz
AMD!4ever
#128
üzenetére
csak az akár abban a ''picit fejlettebb'' K8-ban, hogy 400Mhz-es memóriaórajelre tervezték a gyorsítótárak felépítését
Stabilitást tesztekkel kapcsolatban pár szót ha megengedtek:
Jók meg hasznosak ezek a CPU és memória stabilitást végző progik, de két egyáltalán nem lényegtelen terültetét nem terhelik le az alaplapnak, ez pedig a déli híd és a PCIE vagy AGP.
-Déli hídnál ott az UDMA és rossz memóriabeállítás esetén előfordulhat, hogy a winyókon csak nagy állományokkal végzett műveleteknél bukik ki a bibi. CRC-vel érdemes ellenőriztetni, mielőtt kijelentjük egy gépről, hogy stabil.
-a másik a VGA kari a CPU kihagyásával szokott a DDR felől adatokat nyerni, ezt max. 3D benchmarkokkal és sok-sok játék futtatásával tesztelhetjük. (a BIOSban erre vannak a PEG beállítási funkciók is)
[Szerkesztve]
Tesztel kapcsolatban pont az általam linkelt oldalon 2db grafikon látható "nem módosított" adatok méréséről és pont alatta a memória késleltetéshez hasonlítják(említik), de magunk hasonlíthatjuk a Pentium D-nél mértekhez is.
Mert hogy az Enhanced Dynamic Acceleration Technology(EDAT) előzőleg minden Penryn procira be lett ígérve, erre csak az árbevétileg leghúzóbb mobil szegmensben fogja bevetni a cég. A későbbiekre (egyenlőre tartalékba helyezve) igéri a desktop és a szerver prociknál a bevezetését.
(bizonyos szerver alkalmazásokban szerintem is rúghat labdába a K10, de az csak egy szelete az egész tortának 
, de az Asrock 4CoreDual-VSTA lap szeretettel fogadja 
, kérdés mi az elvárt teljesítmény
egyenlő=200x8, 4x HTT, 500 ram
Új hozzászólás Aktív témák
- Vegyes , 3 db memoria egyben vihető, teszteletlen.
- Hp 450 G9 Core i5 1235U 10 mag 12 szál 15.6 FullHD IPS Fém ház Boltból Garanciával Számlával
- Apple iPhone 12 Pro Max 256GB, Kártyafüggetlen, 1 Év Garanciával
- GAMER PC! i7-10700F / RTX 3070 / B460-Plus / 16GB DDR4 / SSD 512GB / BeszámítOK!
- iPhone 17 Pro 256 GB Silver - Bontatlan !! www.stylebolt.hu - Apple eszközök - Számlás
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest