- Vivo V40 5G - az első benyomás fontos
- Hová lett 1000 mAh?
- Fontos fejlesztéssel érkezik a Galaxy A17 5G
- Friss koncepciót hoz a Nothing Phone (3)
- Samsung Galaxy A54 - türelemjáték
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Amazfit Active 2 NFC - jó kör
- Csak semmi szimmetria: flegma dizájnnal készül a Nothing Phone (3)
- Magisk
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
-
Mobilarena
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
#95904256
törölt tag
Ha jól értem akkor az hogy ''nem procilimites'' az azt jelenti hogy szinte mindegy hogy egy gyors vagy még gyorsabb processzorral zajlik le a mérés, az eredmény ettől nem változhat, igaz?
Ez esetben a 2,5GHz -> 3,0GHz CPU tuning nem okozhatta a 3Dmark pontszám ilyen mértékű emelkedését. -
Gorneck
legenda
Ez egy szimpla mérési eltérés is lehet vagy egyszerű tweak...vagy ki tudja még milyen finom kis trükkök...
Pl. egyes lapok képesek játszani a kártyák órajelével...de gondolom ezt tudod...így Én erre nem alapoznék pláne nem úgy, hogy nem Én mérek...vagy nem vagyok ott és tudom a körülményeket.. -
Raymond
titán
Ehhh....ugye nem sokat ertesz a 3DMark-hoz?
''Figyu, akkor lehetne nem proci-limites, ha nem full 100%-on menne a proci...''
A 3DMark CPU teszt mindig proci limites lesz. 640x480-as felbontasban fut es direkt a CPU leterhelesere lett letrehozva.
''Hasonló konfig, mindkettőnél Core 506 MHz/Memory Clock 513 MHz a 2900XT-k.''
Az a 3Dmark altal detekalt orajel. Az ATI kartyak eseteben a 2D-s, mert csak azt lehet kiolvasni ha a desktop-ot latod a kepernyon. A valos orajelet a commentekbe szokjak irni. Az elso linknel nincs odairva, a masodiknal ott van (''2x Asus 2900XT in CFire @11xx/10xx''). Az eredmenyekbol itelve az elsonel is valami hasonlo lehetett.
Nezd at meg egyszer azt a Top 20 oldalt. Lenjebb ott vannak az alkategoriak is. Hasonlitsd ossze par ATI kartya eredmenyet az SM3 kategoriaban. Lathatod hogy a proci abszolut lenyegtelen. A teszt teljesen VGA limitalt. Egy dual core ugyanazt az eredmenyt adja mint egy quad. Mikozben a quad ketszer annyi CPU pontot kap. Az SM2 eredmenyeket meg befolyasolja a CPU sebessege a felhasznalt engine miatt (par geometriai program resz a procin fut). De ott sem az FSB a szuk keresztmetszet. Hasonlitsd ossze ket kulonbozo orajelu ketmagos vagy negymagos teljesitmenyet. A gyorsulas az orajel novekedesevel lesz aranyos. -
Raymond
titán
Nem hogy nem erted! Osszegezzuk mit mond az Inq:
CrossFire 2900XT @ 830GPU es 3Ghz negymagos Barcelona ad 30K+ pontot 3DMark06-ban
Milyenek a valo vilag adatok szamtalan publikalt eredmeny alapjan?:
Az hogy egy CrossFire 2900XT konfig legalabb az egyik (az SM3.0) grafikus tesztben 10K pontot kapjon 900Mhz felett kell jarnia.
A 3 alpontszam a vegso 3DMark eredmenynel nem egyszeru osszeadas, hanem merlegelt. A CPU eredmeny kisebb mertekben jarul hozza a vegeredmenyhez mint az SM2 es SM3 eredmenyek. Tehat ahoz hogy meg a publikalt leggyorsabb kartya eredmenyeit veve is egy gep 30K feletti vegeredmenyt kapjon 14K+ CPU score kell. Ezt negymagos procival nem csinalod meg. A Barcelona-val sem. Egy 5Ghz-n jaratott C2Q nem fogja vissza a 2900XT Xfire-t. Amennyit ki lehet belole hozni azt kihozza. Ezt megnezheted a publikalt Top 20 eredmeneknel: [link] A grafikus altesztek eredmenyei a kartyak sebessegetol fuggenek. A CPU alig jatszik mar szerepet. A kulonbozo meghajtok tobbet valtoztatnak rajta mint peldaul +300Mhz a CPU-hoz. -
dezz
nagyúr
-
ftc
nagyúr
-
robyeger
addikt
[link]
add még hozzá a táblázathoz a Windsor magos X2 4800+ és hasonlítsd a 3800-as Oreans maghoz. Ugyan így lehet viszonyítani egymáshoz az azonos magórajelű 1 és 2magos procikat, csak minél kisebb a magórajel annál lustább az XBAR és az IMC is, ezért csökkenek a különbségek is. -
robyeger
addikt
valószínűleg az van, amit te mondasz, hogy gyors egymásutánban váltogatja a magokat és ezek átlaga 50% mutat. Teljesítmény szempontjából 1szálú programnál Core2n ugyan mind1, hogy egyik pillanatban az egyik magra másik pillanatban a másik magra allokálja az alapadatokat a műveletvégzéshez, hiszen az L2 cache közös, viszont K8-nál még ilyen esetben is növekszik a teljesítmény, mert az osztott memóriavezérlő miatt az adatelőkészítés gyorsul 2magnál az 1magos procihoz képest. Csak azt tudom mondani nehéz 1magra tesztelni, 2magos procival. Talán Win98 alatt, ahogy Rive javasolta.
-
-
Raymond
titán
Bocs, de nem ertem mit irsz.
A 14K+ szam ugy jon ki, hogy a legjobb elerheto grafikuskartya eredmenyeket innen:
[link] beirod a linkelt szamoloba es megnezed milyen CPU score kell ahoz hogy az osszesitett eredmeny 30K+ legyen. Es ahoz a mar emlitett 14K+ kene. Mar mennyire valoszinu, hogy egy (legyunk nagyvonaluak) 3Ghz-n jaro Barcelona majdnem ketszer akkora eredmeny-t ad mint egy 5Ghz-n jaro C2Q? Szerintem semennyire. Annak aki nem akarja a Futuremark oldalt kinyitni itt a mostani csucs eredmenyek:
3DMark Score 27039 3DMarks
SM 2.0 Score 11273 Marks
SM 3.0 Score 12088 Marks
CPU Score 7619 Marks -
#95904256
törölt tag
Hali dezz!
Szerintem közel jársz az igazsághoz. A C2Q négy magját bizony erősen visszafoghatja a szűk memóriasávszélesség. Még P.H. mutatott nekem épp egy Prohardver!-es teszteredményt ami ezt jól példázza. [link] Itt a PhotoWorxx benchmark alatt a C2Q csak 20% előnyre tett szert egy C2D-hez képest. Nem lehetséges hogy a 3DMark is beleütközik ebbe a korlátba?
Tudna valaki egy C2D és egy C2Q eredményt is megadni?
szerk.: Kicsit nézelődtem a neten, a C2Q és C2D közt 3DMark06 alatt kb. 70% különbség van azonos órajelen. Nos lehet hogy az AMD négymagosa ennél jobbat produkál egy kétmagoshoz képest...
[Szerkesztve] -
-
-
robyeger
addikt
most néztem Core2 alatt a WinRAR sebesség tesztjét és hiba kapcsoltam ki a multithreading-et, csak annyi történt, hogy leset a magok terhelése 100%-ról 50% körülire, de attól még mind a két mag ugyan azon a teljesítményen dolgozott, tehát a progi a Conroe-t nem tudta rábeszélni az 1magos feladatvégrehajtásra.
Jutt eszembe csak a Vista kernele képes arra, hogy programozási szinten külön kijelölhetők a magok. Ezt pedig XP alatt csináltam.
[Szerkesztve] -
robyeger
addikt
elméletben vagy ha DOS oprendszert használsz.
A lényeg hogy befolyásolja még a szűz win alatt is. Nem pontos tesztet ad vissza. Másodsorban a transzfer teljesítmény erősen magórajel függő, tehát minél nagyobb annál nagyobb különbségeket lehet produkálni az alapórajel növelésével. pl: 2Ghz-nél 250mhz alapórajel felett már nem hoz teljesítmény növekedést, míg 3Ghz-en 333Mhz-ig is emelkedik.
Ha alaposan nézed, teszteled X2-nél is lehet érzékelni ezt nem tagadom.
[Szerkesztve] -
robyeger
addikt
Azért valamilyen egy magot fullra terhelő programmal jól lehet tesztelni. Hacsak nem néhány % difiről beszélünk. 200 -> 250 MHz-nek ~25% gyorsulást kellene okoznia, ha igazad van.
25% gyorsulás nem lesz természetesen , mert ez elméleti, még a Sandra memória benchmark részénél is lefaragódik ebből. Pedig az csak transzfer teljesítményt mér, hátha még olyan programmal nézzük, ahol nem csak a transzfer, hanem a matematikai műveletvégző teljesítmény is számít, mert ugye azonos magórajelen nem fog tudni gyorsabban összeadni, csak a nagyobb alapórajel miatt hamarabb jutt adatokhoz a műveletvégzéshez. De mivel adódik teljesítmény többlet, bizonyitja azt hogy tényleg történik szorzás a procin belül, nem dísznek van az alapórajel és a szorzó.
Meg irtam már, hogy X2-nél nem tiltható le az egyik mag, nem választható szét tisztán a teljesítmény a magok között, akár milyen 1szálú programmal terheled.
[Szerkesztve] -
-
-
Zeratul
addikt
Robigyerek az nem veszi figyelembe hogy bizonyos processzor szorzók nem minden esetben használnak szabvány frekvenciákat minden ramtipusnál. Van ahol uder van ahol overclocking van alaphelyzetben is. Másik amit nem vesz figyelembe hogy ha növeli az alapfreki megy vele minden ram, CPU HT freki is. AGP/PCI/PCIE azért nem változik mert külön órajelet kap PLL től viszont a megnövekedett HT fereki jobban terheli az északi hidat.
-
#95904256
törölt tag
Várj dezz! Látom te érted hogy mit is javasolt robyeger. Bevallom én első nekifutásra nem értettem meg, de még neki futok újra. Már elindítottam egy AM2 rendszer beszerzésést, de processzort még nem választottam. Melyik X2 lenne ideális egy ilyen teszthez? Gondolok itt arra hogy említve lett a DDR500-at támogató Venice mag. Eddig csak fél füllel hallottam hogy ilyesmi is létezik...
-
-
robyeger
addikt
sajnos van egy-két féligazságunk, de nem elég hogy összerakjuk a teljes igazságot
Igen vannak akik detto ugyan annak gondolják a kezdetektől, vannak akik az SRI-t az SRQ tovább fejlesztésének tekintik. Ha figyelted az előző hozzászólásokat, én azzal indítottam, hogy kétségbevontam az X-bit lab állítását miszerint a két mag csak a memóriavezérlőn keresztül tud kommunikálni egymással, de a gyakorlat az oroszokat igazolja, gondoljon mindenki amit akar, én személy szerint nem ezt látom fő problémának, hanem azt hogy az 1magos AM2 procik dual 400Mhz-es memóriánál gyorsabbat nem tudják kihasználni, vagy a Venice magoknál bevezetett DDR500-as támogatásnál tapasztaltak, ezekből pedig az következik, hogy az SRQ(SRI)-től az L2 cache csak alapórajelen érhető el. Szívesen fogadom bárki véleményét, aki el tudja magyarázni nekem, hogy hol található a processzor szorzó a K8-ban és miért van ez így a gyakorlatban(az előbb felsoroltak).
#1503: szerintem az L2 cache-t kapcsolják a SRQ-hoz, a kérdés itt hogy hány db 64bites adatbusz megy és milyen órajelen?
[Szerkesztve] -
dezz
nagyúr
''két, viszonylag közeli végpont van [miközben a HT mindenféle egzotikus elrendezést megenged]'' -> na ezt úgy értettem, hogy az elsőnél két fix végpont van, de miközben HT-nél is egyszerre két végpont között zajlik a csomagátvitel (mivel ez csomag-alapú), ezek akár több pont közül választódhatnak ki mindkét oldalon (valószínűleg végpont-címzéssel megy a dolog).
(Ja, meg azt se felejtsük el, hogy a HT busz nem korlátozódik az AMD procijaira, hanem iparszerte jópár cég alkalmazza, és előfordulnak olyan esetek, amikor csak a HT órajel képzheti a szinkronizációt, mármint az a HT buszon lévő eszközöknek pl. eltérő az alapfrekije.)
[Szerkesztve] -
#95904256
törölt tag
A HT órajelének mivel kell szinkronban lennie? Minden bizonnyal azzal közös órajelforrásra támaszkodik, akár felszorozza azt, akár leosztja.
szerk.: Ha nincs szinkronban semmivel ( pl. vezérlőjeles handshake-t használ? ) akkor meg teljesen mindegy hogy mi az órajel forrása, a lényeg hogy stabil legyen és előállítható legyen belőle a kívánt HT órajel.
[Szerkesztve] -
robyeger
addikt
Én is azt hittem az SRQ közös, de az X-bit labs és egyéb írások által, kénytelen voltam átértékelni álláspontom, amúgy az XBAR-tól nem kell félni
-Igen, K8-nál a magórajel leosztásából képződik a memória órajele, én csak azt akartam kifejezni, hogy a GPU függetlenül dolgozhat a CPUtól az alaplapi memóriában. Tehát ha pl. alacsony a CPU magórajele és ezáltal pl. egy 800Mhz-es memóriából valósan kevesebb az általa elérhető sávszél, attól a GPU számára ezen felül is biztosított sávszélesség egészen a memória teljes terhelhetőségéig.
-K10-es DDR3-as kihasználását sávszélességre értettem, a késleltetés már más tészta. -
Rive
veterán
A koherens jelző a HT esetén szerintem arra vonatkozik, hogy többprocis rendszerekben a HT vonalak egymástól függetlenül működve egy időben többfelé többféle transzportot valósíthatnak meg.
Izé. Nem neked szól: aki nem tudja, MP-fronton mi a koherencia, az inkább ne terhelje a topikot.
Alapesetben ugyebár van egy core, egy hozzá tartozó cache és egy memória. A cache egyes memóriaterületek másolatait tartalmazza. Ezek a másolatok a core áldásos közreműködése folytán megváltozhatnak. Mivel a rendszerben a cacheable területekhez csak egy magnak van hozzáférése, elég a megváltozott tartalmat akkor visszaírni a memóriába, ha a gyorsítótárban valamire épp nagyobb szükség van.
MP esetén egy memória, több core, több cache. Azonos memóriaterületnek több gyorsítótárban is lehetnek másolatai. A több gyorsítótár több maghoz tartozik, és elvileg előfordulhat olyan eset, amikor a magok egyszerre próbálnak azonos memóriaterülettel - illetve az adott memóriaterület helyi másolataival dolgozni. Komolyabb extra hardver nélkül nem igazán biztosítható, hogy ilyenkor az egyes másolatok ne térjenek el egymástól.
A koherencia azt jelenti, hogy az egyes másolatok mindig ugyanazt tartalmazzák, illetve ha az egyik változik, akkor ez a változás 'azonnal' jelentkezik a többinél is. Az azonnal itt annyit jelent, hogy a klf. magokon futó klf. programok számára azonnal. Maga a művelet természetesen akár igen sok órajelnyi időt is igénybe vehet. De ebből a programok nem vehetnek észre semmit.
A HT link egy olyan adatút, ami transzparens összeköttetést biztosít a két végén található memóriatartományok között. Ha legalább az egyik végén nincs olyan memória, amit gyorsítótárazni lehet, akkor ez elég is. Illetve akkor is, ha csak egy procc van a rendszerben.
Ha a HT mindkét végén procc fekszik, saját cacheable memóriával, akkor gondoskodni kell az adatok másolatainak automatikus szinkronizálásáról. Az olyan HT link, ami erre képes, a koherens HT. -
Raymond
titán
Back in business...majd egy honap utan. My precious broadband
[link]
''In a single-processor configuration, the links are non-coherent – all three are available for connection with system I/O components. In a multi-processor configuration, one must be coherent, leaving the others for I/O responsibilities. The coherent link allows each processor to access another’s memory. Thus, an AMD Opteron processor 800-series CPU, designed for four- and eight-way configurations, needs three coherent HyperTransport technology links to communicate with its neighboring processors.''
Errol szol a koherencia. Ha jol emlekszem ezert kell fizetni a HT-ert az AMD-nek. A sima HT ingyenes, a cHT mar nem. -
P.H.
senior tag
Az logout eleve kizárt, két ok miatt is:
- a megjelenést követően okafogyottá válik ez a fordítás, úgyis lesz egy cikk róla
- a szöveg .TXT-ben 33 KB, az 15 ezres limitet figyelembe véve legalább 3 darabban lehetne lehozni.
''- 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!)''
Ezt kifejtenéd egy picit bővebben? Sejtem, mire gondolsz, de nem akarok elhamarkodott választ adni.
''2. Ha az FPU-s memória-műveletet is az AGU és az LSU végzi el, mit csinál az FSTORE?''
Fontos elem az FPU-egységben, hogy a registerfile olvasásának lépcsője közvetlenül az FADD/FMUL/FSTORE kezdőlépcsői előtt vannak, de már az ütemezés után - és így a műveletek indítása után (míg az integer-egységben ez az ütemezés előtt). K8 esetében továbbá a registerfile-ba is csak a három egység valamelyike írhat.
Ebből következik, hogy lebegőpontos betöltés (sima load) esetén egy AGU-művelet adja a címet, egy FPU-műveletnek pedig a kapott betöltött adatot be kell írnia a registerfile-ba. Ehhez szükséges egy FPU micro-op, de ezt bármely egység végre tudja hajtani. Csak nem egyszerű eligazodni a K8-as Optimization Manual-ban sem, mivel
MOVAPS reg,mem (load 4x32 bit) mellett nem szerepel semmi
MOVAPD reg,mem (load 2x64 bit) mellett pedig FADD/FMUL/FSTORE szerepel
MOVSS reg,mem (load 1x32 bit) mellett szintén semmi
MOVSD reg,mem (load 1x64 bit) mellett pedig FADD/FMUL van
holott az első két művelet gyakorlatilag ugyanazt jelenti: 128-es memóriaadat betöltése register-be, a második kettő is csak adatméretben tér el egymástól. (A cikk azt írja, a sima load utasításokat eddig az FSTORE végezte, van olyan forrás, ahol tényleg ez található, az Opt. Manual-okban viszont nem).
OP reg,mem esetben a betöltött adatot ugyanígy tudja fogadni az FADD és az FMUL egység (és az FSTORE is), csak mint forrásadatot kezeli és végrehajtja vele a megfelelő műveletet, nem csupán kiírja azt a registerfile-ba.
K10 esetében úgy látszik, megoldották, hogy a registerfile-ba lehet egy negyedik úton is lehet írni (talán az ICU felől), ezért nem szükségesek FPU-erőforrások a sima betöltésekhez, és pl. a konvertálás nélküli (bitmásolásos) intreg->xmmreg adatmozgatáshoz.
Viszont az FSTORE egység legfőbb jellemzője, hogy (az FADD és FMUL egységekkel ellentétben) egyetlen forrásadata lehet csak (vagy egy sem), ennek megfelelően tárolások (szinte az összes) esetén ez az egység olvassa ki a registerfile-ból a megfelelő értéket, és küldi az AGU által kiszámolt cím mellé, de csupán ennyi a dolga sima lebegőpontos adatok esetében. További egyedi tevékenységei (melyeket az FADD és FMUL nem végezhet):
- FPU-státuszok továbbítása az FPU-egységből közvetlenül az integer register-ekbe ([link] ábrán jól látszik a belőle kiinduló adatút az integer egységbe)
- (betöltésnél, integer vagy xmm register-ből) integer->lebegőpontos és (tárolásnál, integer vagy xmm register-be) lebegőpontos->integer konvertálás.
- x87 lebegőpontos konstansok betöltése (0.0, 1.0, PI, log2, stb.)
Kicsit összegezve, a memória-műveletek »csak« azért dolgoztatják (részben csak eddig dolgoztatták) az FADD, FMUL, és FSTORE egységeket, mert a registerfile ''mélyen benn van'' az FPU-egységben, közvetlenül előttük vagy rajtuk keresztül (volt) hozzáférhető.
#1442 robyeger:
Még mielőtt a leveleddel néhány vidám pillanatot sikerülne szerezned nekik, azért érdemes átnézni, hogy ők mire jutottak. Úgy veszem észre, nem találkoztál még vele. Akkor kezdjük az elején, a MOESI-vel, ahogy az elméletben működik (innen: [link])
''If a processor does not find the cache-line in someone else's cache then it loads it from system memory into its cache and marks it as Exclusive. Now whenever it writes something in the cache-line then it becomes Modified. It does in general not write the modified cache-line back to memory. It only does so if a special memory-page-attribute tells it to do so (write through). The cache line will be evicted only later on if another cache-line comes in which competes for the same place in the cache.
If a processor needs to read from memory and it finds the cache line in someone else's cache then it will mark the cache line as Shared. If the cache-line it finds in the other processors cache is Modified then it will load it directly from there instead of reading it from the memory which may be not up to date. Cache to cache transfers are generally faster then memory accesses.
The status of the cache-line in the other cache goes from Modified to Owner. This cache-line still isn't written back to memory. Any other (third) processor that needs this cache-line from memory will find a Shared version and a Owner version in the caches of the first two processors. It will obtain the Owner version instead of reading it from system memory. The owner is the latest who modified the cache-line and stays responsible to update the system memory later on.
A cache-line stays shared as long as nobody modifies the cache-line again. If one of the processors modifies it then it must let this know to the other processors by sending an invalidate probe throughout the system. The state becomes Modified in this processor and Invalid in the other ones. If it continues to write to the cache line then it does not have to send anymore invalidate probes because the cache line isn't shared anymore. It has taken over the responsibility to update the system memory with the modified cache line whenever it must evict the cache-line later on.''
Csak megjegyzésképpen: érdemes elolvasni hozzá ezt a cikket, főleg ezt az oldalát: [link]. Az alján látható, hogy többek között az Intel által használt MESI cache-protocol és az AMD által használt MOESI eltér skálázhatóságban, utóbbi mellett több magot lehet összerakni, mint előbbinél, ezért használja ezt az AMD.
A következő: X-bit's Investigation: Data Transfer Rate between the Cores in Dual-Core Processors, átfogó cikk többmagos rendszerek inter-core kommunikációjáról. Ami itt fontos: [link], [link] és [link]. Érdekes olvasmány; a lényeg kiemelve:
- nem módosított adat esetén: ''So, the results of reading unmodified data make me think that there’s no fast reading directly from another core’s cache. This must be how the MOESI protocol is implemented here: it requests the most recent copy of data from system memory.''
- módosított adat esetén: ''So, I have to state that I can’t find any indication of direct data transfers from one execution core to another in the Athlon 64 X2 processor. According to my tests, the most recent copy of data is always read from system RAM. This must be a limitation of the MOESI protocol implementation. The following seems to happen when data are accessed: on receiving a read request probe read that the second core puts on the system bus, the first core performs a write-back of the modified cache line into memory. After this write or at the same time with it, the requested line is transferred to the second core. If the data in the first core’s cache haven’t been modified, they are read from system RAM. Why is there no direct transfer between the cores via the crossbar switch? Ask AMD’s engineers about that!''
Tehát ezek szerint a MOESI (ami a nagy skálázhatósághoz kell) implementálása olyan, hogy több olyan helyzetben is a rendszermemóriához fordulnaki, amelyekben elméletileg nem kellene.
De ez még mindig csak teszteken alapuló következtetés, mint a te véleményed, itt még csak Occam és az ő borotvája lehet érv a tieddel szemben (és az, hogy nem látnak bele 200 MHz-eket a CPU-ba, illetve nem akarják annak ismert szerkezetét átrajzolni ). De tegyünk hozzá további két dolgot:
- itt [link] egy elég érdekes beszélgetés van a cikkről, az oldal közepén kezdődően. Egy kissé szőrszálhasogató, de van benne valami:
''Today I talked to Patrick Patla, AMD's Director - Server Workstation Division and John Fruehe, Worldwide Channel Market Development for the same division. I asked them about whether the two cores in an AMD dual-core processor can share information in their Level 2 cache with each other over the System Request Queue, and they both emphatically said they could.''
válasz: ''From what you are telling me, AMD says that they can, but ''They Can'' & They Do'' is a different story. And as far as I am concerned they at this point do not share L2 cache. The same goes for there upcoming Quad-Core. L3 is a different story.''
- ...és a K10 az L3-mal: Amint korábban kiderült, a korábbi Athlon64 processzorok magjai a memóriabuszon keresztül cserélnek adatokat, nagyban lassítva a közösen módosított adatok cseréjét (Shared/Modified, MOESI protokoll szerint), K10 ezt az L3 cache-en keresztül oldja meg: ha az egyik mag a kérdéses adathoz fordul, a másik mag elhelyezi a módosított adatot az L3 cache-ben, így az előbbi sokkal kisebb késleltetéssel férhet hozzá ahhoz. (Így értette, kissé leegyszerűsítve a fent vázolt helyzetet)
A mechanizmus ugyanaz maradt: a másik mag ''elindítja a tárolási eljárást'' a módosított adatra, amely ''az L3-ig jut'' csak, és a másik mag onnan kapja meg, a rendszermemória helyett.
És tényleg nagyon zavaró, hogy (már nem először) a kifejezéseket látszólag értelmük ismerete nélkül használod, egyszerűen nem lehet odafigyelni a valós mondanivalóra, és komolyan venni azt, az ilyen mondatok mellett.
[Szerkesztve] -
robyeger
addikt
-
Raymond
titán
''Világosan látszik, hogy a 250nm->130nm váltáskor is, és a 130nm->90nm váltáskor is majdnem pont a felére sikerült nyomni a magot.''
De a dolgok nem ilyen egyszeruek. A fizika es kemia is beleszol a dolgokba. A 90nm egy hatar ami mogott (alatt) mar valtoznak a torvenyek. Ezt mindegyik gyartonal lathattad.
''31/55=0,5636 -> az eredeti 56%-a.''
A 90nm feletti vilagot felejtsd el.
''20,8/31=0,67 -> az eredeti 67%-ára, ebből is látható, amit írtam, de más forrásból is lehetett hallani: a Brisbane egy gyors, ''felületes'' shrink volt - túl sokat nem volt érdemes dolgozniuk vele, a gyártás kisebb részét teszi ki, stb.''
A feluletesseghez annyit hogy a Barcelona mag ugyanakkor mint a Brisbane plusz a bovitett FPU resz. A tobbi valtoztatas nem igenyelt sok heleyt, csak kicsivel tolodott par komponens de azt sem nagyon. Hasonlitsd ossze a Brisbane magot a maik keprol az egyik Barcelona maggal. A ''gyartas kisebb reszerol'' pedig annyit hogy per pillanat ezekbol a procikbol el az AMD. A ket(harom) csucs procin kivul (amit csak tenyleg kis mennyisegben gyartanak) mind 65nm K8 es a desktop piacon az lesz jovo tavaszig.
''Ha viszont azt feltételezzük (a korábbiak alapján), hogy .......... nagyjából 50%-os bővítés (b. verzió).''
Ezt igy nem vehetd. Nem ugralhatsz at node-okat csak ugy. Egy 130->65 osszehasonlitas ertelmetlen. -
Raymond
titán
Was?
A kep ugyanarrol az oldarol van ahonnan a tablazat. Csak egy 90->65 kicsinyites van es az arany ugyanaz a Brisbane es a Barcelona eseteben is. Annyi csak a kulonbseg hogy a Barcelona kicsit nagyobb a Brisbane-hez kepest a plus FP egysegek es a par toldas miatt.
Egy magot nem tudsz 50%-ra kicsinyiteni egyik valtasnal sem, hiaba van az elmeleti szam. Nincs szo felmagoldasrol vagy hasonlokrol. Nezd att a szamokat ujra mindket gyartonal. -
-
P.H.
senior tag
''#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] -
dezz
nagyúr
Pontosítanék: persze nem fél év múlva, hanem 3-4 hónap múlva. (De gyorsan tellik az idő...) Végülis már tényleg nem ártana némi desktop kiszivárogtatás sem. De pl. hiába gyorsabb valamivel clock-for-clock, ha nem sikerül elég magas órajeleket elérniük. Szóval most az órajel növelésén dolgoznak 1000-rel, és majd meglátjuk, ez mennyire sikerül, legalábbis év végéig.
-
#1322
VaniliásRönk
nagyúr
dezz
#1321
-
P.H.
senior tag
Jól értem, te azt mondod, hogy egy macro-op load/store/load-store micro-op-ja nem az LSU-nak szól, hanem csak egy AGU-nak?
Az L1 (és csak az) tekinthető Intel és AMD esetében is a pipe (és az AGU-k vagy a Port2:Load) meghosszabbításának. Ha a kért címet és a teljes adatméretet tartalmazza az L1, akkor load és store esetben nincs baj, +2 cycle kell a teljesítéshez. De ha nincs ott, vagy load-store esetben kell segítőeszköz, előbbi esetben ez a 2 db Load/Store Unit (AMD esetében). Ha az adat nincs L1-ben, akkor a cím a kisebb L2 LSU-ba kerül, és csinál egy próbát a nagyobb késleltetésű L2-n. Ha az L2-ben sincs, akkor a nagyobb memory LSU-ba kerül, ez a rendszermemóriához fordul. Mindkét eset kimenetele az, hogy az adat cím és az azon szereplő 64 byte-os adat az L1-be kerül (64-byte violation esetén 2x64 bit)
Viszont mindhárom esetben (load, store és load-store egyaránt) a cím (és az kiírt adat, ha van ilyen) bekerül az átmeneti tárolóként szolgáló Memory Order Buffer-be (akárhogyan is nem szerepel a képeken; ha AMD esetében valóban nincs, akkor az L2 LSU-nak kell átvennie ezt a szerepet, mert egy ilyen szerepű egységnek kötelező lenni out-of-order felépítés esetén), mivel out-of-order esetben lehetséges spekulatív load, de spekulatív store nem, visszavonhatónak kell lennie a retirement által. A load-store itt ''ül meg'', továbbá itt dönti el a megfelelően fejlett egység, hogy melyik művelet rendezhető át melyikkel (load-load vagy load-store is akár, Core2 és K10 esetén). Illetve a Store-to-Load Forward (az Intel-es Store-Forwarding megfelelője és kiterjesztése AMD-nél) akár megvalósítható lenne csak a result bus-rendszeren is, de ez is egy forrás, mert ez is tartja a tárolt adatot egy ideig.
#1318 akosf: Az L1 késleltetést talán egyszerűen AMD esetében, össze kell hasonlítani sok teljesen függő egyszerű integer reg,reg utasítás RDTSC-jét teljesen függő reg,mem utasítások idejével, de ezen még gondolkodok egy kicsit (lehet, hogy célravezetőbb a Store-Forwarding elkerülésével 32 bites store és eltolt 8 bites load azonos címre, majd elosztani a clock-count-ot kettővel...)
[Szerkesztve] -
P.H.
senior tag
Affene, én is lassan flood-olok...
''A 4/5 mikroOP bizony jelenthet 4/5 utasítást is a Core2 esetében, ugyanis az utasítások jelentős részénél 1 utasítás = 1 mikroOP megfeleltetés áll fenn, ha nincs memória hivatozású operandus.''
A véleményem: kézzel írt assembly-kódban valóban sokkal kevesebb a memória-operandus, mint fordított kódokban. Viszont általában a programozási nyelvek alapjai a változók, ezeken dolgoznak, tehát minden egyes utasítás egy-egy betöltés-(jó esetben komplex) operation-tárolás sorozat. Persze adottak a register direktíva, némi fordítási optimalizáció, illetve a ciklusváltozók register-ben tartása (ahogy én észrevettem, ezekre a célokra az ESI-EDI-EBX használatos - a kernel-hívások ezek értékeit megtartják, plusz az EBP-t természetesen -, de az objektumorientált nyelveknél ide kerülnek még maguknak az objektumoknak a címei is, tehát elég szűkös a készlet). Az említett kompex operation-ökkel meg az a baj, hogy jó hosszú szekvenciális függő utasításfolyamot generálnak, amin túl kell látnia az out-of-order magnak, hogy tudjon hatékonyan működni, tehát minél hosszabb, annál rosszabb.
Van egy kb. 23 ezer utasításból álló teljesen assembly programom (amiből lett kis módosítással a korábbi teszt is, azért olyan a kezelőfelület, amilyen, mert teljes program, de csak bizonyos részeit tettem elérhetővé GUI-ról), ebből akár tudok pontos adatot is mondani, hogy kézzel írt programban mennyi a memória-operandusú utasítások száma (teljesen általánosan, GUI, általános és specializált algoritmusok, értelmes egésszé összerakva).
''Mert a dekóderek utáni részeknek, és talán a retirementnek szűkebb a keresztmetszete.''
Ez így lehet, de fontosabb, hogy a decode-fázis az egyetlen a magon belül, amit nem befolyásolnak a függőségek.
''Egyébként ha azt veszem amit már írtam, hogy az IPC=1,5 értéket is nehéz elérni akkor ezzel csak megerősítettél abban hogy az IPCmax érték növelés nem hoz túl sokat a teljesítmény növelésében.''
Egy mondat: mint korábban említettem, Intel esetében eddig is (legalábbis semmi nem szólt ellene) 128 bites volt a decode, a schedule (az execute unit-on belül tört 64 bitre a 128 bites micro-op, majd állt össze 128 bitre az eredmény) és a retirement, tehát a natív 128 bit bevezetése egyetlen (bár a legfontosabb) lépcsőt érintett, a pipeline hosszát. AMD esetében mind a négy fő lépcső 64 bites volt, tehát a hatásának végig a teljes CPU-n érezhetőnek kell lennie, sokkal jobban, mint Intel esetében.
#1316: így értendő (L1-hozzáférés +2 cycle latency, az FMISC/FSTORE az egyoperandusú nem-integer műveleteket - konvertálás, ilyesmi - hajtja végre):
ADDPD xmmreg1, xmmreg2 DirectPath Single FADD 4 1/1
ADDPD xmmreg1, mem DirectPath Single FADD 6 1/1
ADDPS xmmreg1, xmmreg2 DirectPath Single FADD 4 1/1
ADDPS xmmreg1, mem DirectPath Single FADD 6 1/1
A memóriahozzáférést természetesen az AGU-k végzik, kiteszik a result bus-ra az eredményt. 3 result bus van összesen, az operation micro-op ott kapja el az eredményt, ahova ment (integer vagy FPU egység)
[Szerkesztve] -
P.H.
senior tag
''a Table 15. 128-Bit Media Instruction Latencies-ben csak azok az utasítások Single-k, amikben vagy csak egy aritmetikai, vagy csak egy load/store/load-store művelet végződik el? Amikben meg egyszerre a kettő, azok meg mind Double-k.''
Melyekre gondolsz? Én K10 Opt. Reference-ben ilyen bejegyzéseket látok:
ADDPD xmmreg1, xmmreg2 (mem) DirectPath Single FADD 4 (6) 1/1
ADDPS xmmreg1, xmmreg2 (mem) DirectPath Single FADD 4 (6) 1/1
Az előző OFF részhez: nem csak a 'finished' state vezethet, hanem elég hangsúlyos, hogy a három ALU/AGU-egység közvetlenül is kommunikálhat egymással, a result bus megkerülésével. Lehetséges, hogy ennek itt van szerepe.
[Szerkesztve] -
P.H.
senior tag
''Írnál 1-1 konkrét példát 2 mikroOP-os Single-re, és 2-3 mikroOP-os Double-re? Úgy értem, hogy pontosan mi történik.''
Induljunk ki ebből: [link]
Minden macro-op kap egy saját tag és egy #chn értéket, valamint minden micro-op kap minden egyes bemeneti értékére egy-egy tag-#chn párt, amitől függ (legrosszann esetben két register plusz a FLAGS, ha egyet sem sikerült kiolvasni valamely registerfile-ból).
Vegyük az ADD EAX,[EBX+ECX] utasítást: ez DirectPath Single, két micro-oppal: MOV temp,[EBX+ECX] AGU micro-op, két forrásértékkel, tehát legrosszabb esetben két előző utasítástól függ (nem sikerült kiolvasni az értéket valamely registerfile-ből), ezek tag és #chn értékeit megkapja. (pl. ADD EBX,01h; ADD ECX,01h; ADD EAX,[EBX+ECX] utasításfolyam); valamint egy ADD EAX,temp micro-oppal, ekkor állítsuk be úgy a tag és #chn értékeket benne, hogy az EAX-re legyen a tag és #chn érték a megfelelő előző utasításé, a temp-re (ami valójában magát az egyik result bus-t jelenti) pedig a saját macro-opjának értékpárját. A saját tag-ja egyetlen esetben fog megjelenni a #chn-nel jelzett result bus-on: ha lefutott a load.
Ebben az nem tiszta, hogy egy ezt követő, EAX-tól függő utasítás hogyan különbözteti meg, hogy a load vagy maga az összeadás történt-e meg, ehhez valami (eddig számomra nem világos) további információ is szükséges. Bár minden macro-op (vagy micro-op?) rendelkezik egy 'finished' state-tel, ez elégséges lehet.
Fordított eset csak ADD [EBX+ECX],EAX esetben lehetséges, itt egy kicsit bonyolódik a dolog. Van egy AGU-művelet, amely kiszámolja az EBX+ECX értéket, és betölti a megfelelő adatot, majd az ADD elvégzi az összeadást, eddig ugyanaz, mint fentebb. Az ADD is kiteszi a tag értékét a megfelelő #chn result bus-ra. Viszont a load/store ''megült'' a Load/Store Queue-ban, és tovább figyeli a result bus-t, hogy mikor jelenik meg ez a tag (amikor ő kiküldte, hogy 'load completed', az persze nem számít). Ha ez megtörtént, akkor elvégzi a store-t (a címet már ismeri).
A Double egy kicsit nehezebb dolog: K8 esetén a PUSH EAX Double, itt a macro-opok között is meg kell tartani megfelelő sorrendet. Talán erre is szolgál a pack-stage, de ebbe ugye még mindig nem látunk bele teljesen. De pl. 128 bites utasítások esetében nem is fontos a sorrend, teljesen mindegy, hogy a felső vagy az alsó 64 bites művelet hajtódik végre előbb, ebben egyedül az ütemezők egyik legfontosabb alaptörvénye ad útmutatást: ha több micro-op alkalmas a futásra adott órajelben, akkor mindig a (programsorrendben?) legkorábbit fogja indítani.
[Szerkesztve] -
#95904256
törölt tag
dezz:Írnál 1-1 konkrét példát 2 mikroOP-os Single-re, és 2-3 mikroOP-os Double-re? Úgy értem, hogy pontosan mi történik.
Nem tudok ilyet írni, mert nincs hozzá dokumentációm. Csak találgatni lehet a mikroOP-ok felépítéséről és arról hogy melyik utasítás mennyi mikroOP-ra fordítódik le. -
#95904256
törölt tag
Szerintem a DirectPath Double kódolású utasítások két, időben egymás után létrejövő makroOP-ra fordulnak le. Ezért is lehet az hogy a DirectPath Double utasítítások ( az XCHG reg,reg utasítást kivéve ) mind legalább 2 órajel késleltetéssel rendelkeznek.
Példa:
BTC reg,reg -> BT reg,reg ; XOR reg,mask(reg)
CALL near -> PUSH ESP ; JMP near
JCXZ near -> CMP CX,0 ; JZ near
LEAVE -> MOV ESP,EBP ; POP EBP
Természetesen a második oszlopban, ahová szintén utasításokat írtam ott több a kombinációs lehetőség mint a rögzített x86 utasításkészletben, mert ezek tulajdonképpen 1-2 mikroOP-ot jelentenek. Vagyis egy DirectPath Double 2\3\4 mikroOP-ra fordulhat le, míg a DirectPath Single csak 1\2-re. Ezekből persze egyik-másik mikroOP végrehajtási ideje több órajelet is kitehet.
Egyedüli kivétel a fent említett XCHG reg,reg utasítás, ami megcáfolhatja ezt a dolgot. Ugyanis ez a K8-ban még 2 órajeles VectorPath utasítás volt, viszont a K10-ben már csak 1 órajel késleltetésű DirectPath Double utasítás. Ez meg hogy lehet?
[Szerkesztve] -
dezz
nagyúr
Na jó, közben elértem a Figure 8-hoz, és az utána következő részhez - amit korábban már persze néztem, de kicsit megfeledkeztem róla. Szal úgy tűnik, tényleg 3 makroOP-ról van szó, ennyi az áteresztő képesség. Viszont nincs ésszerűtlenség, mert a dekóderek kimenete is egyenként 1 makroOP széles, nem több.
bocs a floodért, csak itt magamban beszélgetek
[Szerkesztve] -
dezz
nagyúr
Ja, és még van egy kis bonyolítás AMD-nél: a DirectPath lehet Single (1 makroOP -> 1-2 mikroOP) v. Double (2 makroOP -> 2-4 mikroOP). Mivel az ábrán keveredik a mikroOP és a makroOP, nem vagyok benne biztos, hogy az (egyszerűbb) dekóderek kimenete is 1-2 makroOP vagy 1-2 mikroOP (azaz 1 makroOP) per ciklus. Szerintem makroOP-ról van itt is szó. Szóval ez a rész itt elég ''ütős''.
Csak azt nem értem, hogy akkor ezek után a Pack Buffer miért csak 3 makroOP széles? Így ugyebár a DirectPath Double utasítások torlódnak, azaz azoknál sem jöhet össze a 3,0-ás IPC. Feltéve, ha ez egyátalán korrekt infó, mármint a 3 makroOP széles Pack Buffer kimenet, és persze az elhagyhatatlan retirement. Kedvenc doksinkban (10h opt. guide) ezt találtam:
''The fetch window has changed from 16 bytes on previous AMD64 processors to 32 bytes on AMD Family 10h processors. The 32-byte fetch, when combined with the 128-bit floating-point execution unit, allows the processor to sustain a fetch/dispatch/retire sequence of three large instructions per cycle.''
Szerintetek ez mit jelent? Úgy hangzik, mintha az alap x86/stb. utasításokról lenne szó. (Persze a VectorPath-osokról biztos nem, mert abból egyszerre egyet tud. -- Megjegyzem, a VectorPath elnevezés kicsit csalóka, nem sok köze a vektor [SSEx] egységekhez, azaz a legtöbb SIMD-es utasítás DirectPath-os, sőt abból is Single. Ugyanakkor pl. a bitmanipulációs műveletek jó része VectorPath-os.)
[Szerkesztve] -
dezz
nagyúr
Sőt van itt még valami. AMD-nél 1db VectorPath, vagy 3db DirectPath, akár összetett, 2 mikroOP-os utasítás mehet át. Intelnél viszont csak az egyszerű, 1 mikroOP-osokból mehet át több (*), az összettekből viszont csak 1...
* Elvileg ugyan minden Simple Decoder tudja a mikroOP fúziót, azonban ez nem tűnik igaznak, mivel tesztek szerint 4 egyszerre végrehajtott mikroOP-ból csak egy lehet fúzionált. (Akinek van kedve, letesztelhetné.) -
#95904256
törölt tag
akosf:Na, ez lehet hogy egy kicsit homályos nekem.
dezz:Melyik része?
Úgy tudtam hogy a K10 egy decode egység csak egy utasítást fordít 1-2 microOP-ra.
Te meg írtad hogy a decode egységek kimenete 1-2 microOP-ot generál.
Nem tudtam mire venni a dolgot. De ezek szerint csak redundáns információ.
akosf:De a Decode csatornákon keletkező 1/2 mikroOP az csak 1 utasítást jelent, nem 1/2-őt. Vagy tévedek?
dezz:Nem tévedsz, de én nem is mondtam mást. 3,0 -> 3,0.
Nem mondtam hogy mást mondtál.
A kérdést azért tettem fel hogy tisztázódjon a homályos folt.
Tisztázódott. Mindketten ugyanazt állítjuk. -
#95904256
törölt tag
dezz, akkor most a segítségedet kérem. Ugyanis nem értettem meg hogy ''a dekódolás szélessége önmagában nem döntő tényező''. Először is, ezt miért mondod? Másodszor mit értesz ''döntő'' alatt? Harmadszor ha a döntő = jelentős, akkor miért nem az?
Egyébként ha azt veszem amit már írtam, hogy az IPC=1,5 értéket is nehéz elérni akkor ezzel csak megerősítettél abban hogy az IPCmax érték növelés nem hoz túl sokat a teljesítmény növelésében. -
#95904256
törölt tag
Ezek remek ábrák!
dezz:Itt 4 mikroOP széles ''csatorna'' látható, és tesztek szerint ebből 1 lehet fúzionált, azaz 4 v. 5 mikroOP mehet át, ami 2,0 v. 2,5 x86/stb. utasítás.
A 4/5 mikroOP bizony jelenthet 4/5 utasítást is a Core2 esetében, ugyanis az utasítások jelentős részénél 1 utasítás = 1 mikroOP megfeleltetés áll fenn, ha nincs memória hivatozású operandus.
dezz:És amikor ezt összehasonlítod a K10 ide vonatkozó csatornájával, ami 3 szintén ''uop''-nak van jelölve, vedd figyelembe, hogy az valójában nem mikroOP ott, hanem AMD-féle makroOP, ami egyenként 2db mikroOP. (Ez a nem teljesen korrekt jelölés fel lett róva a szerzőnek, írta is, hogy talán módosítania kellene a képen, de végül nem foglalkozott vele tovább.)
Na, ez lehet hogy egy kicsit homályos nekem. De a Decode csatornákon keletkező 1/2 mikroOP az csak 1 utasítást jelent, nem 1/2-őt. Vagy tévedek? -
#95904256
törölt tag
Hali dezz!
Mi az ami egyre rosszabb?
Idézem még egyszer ami pár sorral feljebb a #1278-ban is olvasható.
All of the decoders can decode one macro-fused pair per cycle, with up to three other instructions, resulting in a peak decode bandwidth of 5 instructions per cycle.
Remélem most jobban látszik. -
#95904256
törölt tag
Hali dezz!
Értem én hogy szépen kijön, de mégis hogyan?
Ezzel csak azt akarom mondani hogy szerintem senki nem fog tudni mutatni olyan float-point kódot ami 3,6-szor gyorsabban fog futni a K10-en mint a K8-as magon. Esetleg úgy tudom elképzelni hogy egy SSE4 optimalizált kódot futtatok a 128 bites motoron egy a 64 bites motoron futó SSE2 kód ellenében ... de ezt is csak azért mert bízom az SSE4-ben. -
Raymond
titán
Jol nezett ki az investorhub-os post, de valaki mar elmagyarazta neki hogy rossz SKU-kat hasonlitott ossze: [link]
Az alacsony orajelek elsosorban azert lehetnek mert 4 magnak kell megutni bizonyos mercet hogy az adott SKU bin-be bekeruljon. Hiaba megy 3 mag 2.5 Ghz-n ha a negyedik csak 2.2-n megy megbizhatoan akkor az egesz chip 2.2 lesz. Az hogy opteronrol van szo szinten nem javit a helyzeten, mert a minosegi tesztek meg szigorubbak mint a desktop termekeknel ugyhogy meg nehezebb egy magasabb bin-be bekerulni. -
P.H.
senior tag
''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] -
#95904256
törölt tag
-
-
-
P.H.
senior tag
Ahogy mondod. Nem ingatta meg azon hitemet, hogy teljesen független utasítások esetén (akosf kódja 8 SSE-utasítás, max. 5 latency mellett, tehát abszolút in-order ütemezés, egy execution unit-ra) kétszeres a növekedés, (by throughput), teljesen függőség esetén legfeljebb 25% (by latency).
Akosf: cseréld ki az összes célregister-t xmm0-ra, így láthatjuk, lesz-e 25%-os növekedés.
Az user-kódok valahol a kettő között vannak. Hétvégén kiollózok egy ilyen '''user-kódot'' (lesz benne egy 3+1 szálas JPEG_decode_to_YUV + YUV->32bitBMP + stretch_to_screen - a'la Irfanview, csak lassabb és jobb eredményt ad - 4x4MB-os pufferekkel kommunikálva (csak SSE), egy amúgy is ''állatorvosi ló'' (SSE2, SSE és x87 implementációval) és egy brute-force (SSE2 és x87), ha lesztek partnerek, meglátjuk az eredményt ott is.
[Szerkesztve] -
#95904256
törölt tag
A PerfMonitorral méret IPC=0.6 jó értéknek tűnik. Elméletileg IPC=0.5 a maximumum az E6-os Sempronon, hisz a 128 bites SSE összeadás műveleteket 2 egymást követő 64 bites összead-s műveletként futtatja, és ebből egyszere egy órajelre csak egyet tud indítani. Az IPC=0.5 feletti érték azért jött ki mert van ott a ciklusmagban két integer utasítás is, a ciklusszervezés miatt. A PerfMonitor minden bizonnyal ezt is belemérte.
Elvileg 2.000.000.000 órajel szükséges hogy 64 bites SSE enginnel lefusson a kód. A többi órajel többmindenből adódik össze, egyrész az TimeStampCountert kezelő programrészlet illetve az első ciklusban az adatok cache-be tárolása igényel néhány száz órajelet. A többi a megszakításokból és az azokat lekezelő windows rutinok futásidejéből adódik.
Természetesen lehet olyan kódot is írni ami a fetch/dekóder részt is leterheli, de itt most arról volt szó hogy a 128 bites SSE engine-t valóban megfojtja-e az adatutak szűkössége vagy sem. Egyébként a fetch/dekóder részt szerintem meglehet fojtani hosszú SSE(2) utasításokkal, de ekkor még lazábban fogja tenni az SSE műveletvégző a dolgát, vagyis épp az ellenkezőjét érjük el mint amit szerettünk volna... -
Raymond
titán
''Ja, A64-es megjegyzésre: ja, látom, ha más is fut, akár ''passzívan'', az eléggé befolyásolja az eredményt. Azért nem egészen tökéletes a WinXP multitaskja.''
Masrol lehet szo, mert a PM-es gepen semmi nincs a Win-en kivul. A PD-s eredmenyeken pedig latszik hogy OS-tol nem fugg a dolog. Tobbszor futtattam a programot egy kornyezetben es az elteresek csak nagyon kicsik voltak a futasok kozt. -
Raymond
titán
-
#95904256
törölt tag
Ez az L2-n keresztüli adat utaztatás csak úgy működik ha az egyik szál számára lefoglalsz egy adatterületet az OS-től, majd elérhetővé teszed ezt a területet a másik magon futó szál számára is. Ekkor egy memóriacímről olvashat a két szál. Ha szerencséd van, akkor ez a memóriaterület az L2-be is bekerül...
-
#95904256
törölt tag
akosf: ''A linkelt tesztben az L2 a Pentium-D-ben és Core2-ben is 2-2 MB magonként.''
dezz: De az utóbbiban közösített, ami egy kétszálas kódolásnál számíthat.
Ez elvileg lehetséges!
Jó lenne látni egy tesztet, erre a megosztott cache-s dologra...
Itt a Prohardveres! tesztben használt programoknál azonban kétséges hogy a Pentium-D illetve Core2-őn futtatva más-más kód futott volna. Valószínűleg épp azért futtaták ugyanazt a programot hogy összehasonlítható eredményeket kapjanak. A megosztott cache használatra egyébként kikell okosítani a programokat, ezt az oprendszer nem képes automatikusan lekezelni. Ez nem egyszerű feladat. Másfelől videokódolásnál nagyon nem is látom túl nagy hasznát, ugyanis itt folyamatosan változik a bemenő adat. Ennek a megosztott cache-nek akkor lehet jelentős szerepe ha pl. egy méretes Look-Up Táblát (LUT) használ az ember. Szerintem...
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Igen vannak akik detto ugyan annak gondolják a kezdetektől, vannak akik az SRI-t az SRQ tovább fejlesztésének tekintik. Ha figyelted az előző hozzászólásokat, én azzal indítottam, hogy kétségbevontam az X-bit lab állítását miszerint a két mag csak a memóriavezérlőn keresztül tud kommunikálni egymással, de a gyakorlat az oroszokat igazolja, gondoljon mindenki amit akar, én személy szerint nem ezt látom fő problémának, hanem azt hogy az 1magos AM2 procik dual 400Mhz-es memóriánál gyorsabbat nem tudják kihasználni, vagy a Venice magoknál bevezetett DDR500-as támogatásnál tapasztaltak, ezekből pedig az következik, hogy az SRQ(SRI)-től az L2 cache csak alapórajelen érhető el. Szívesen fogadom bárki véleményét, aki el tudja magyarázni nekem, hogy hol található a processzor szorzó a K8-ban és miért van ez így a gyakorlatban(az előbb felsoroltak). 
Új hozzászólás Aktív témák
Hirdetés
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Az ide nem illő hozzászólások topikja:[link]
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva.
- Vivo V40 5G - az első benyomás fontos
- Hová lett 1000 mAh?
- Házimozi haladó szinten
- Anglia - élmények, tapasztalatok
- Fontos fejlesztéssel érkezik a Galaxy A17 5G
- Gyúrósok ide!
- Friss koncepciót hoz a Nothing Phone (3)
- Samsung Galaxy A54 - türelemjáték
- Építő/felújító topik
- Konteó topic
- További aktív témák...
- HATALMAS AKCIÓK! GARANCIA, SZÁMLA - Windows 10 11, Office 2016 2019 2021,2024, vírusírtók, VPN
- ÁRGARANCIA!Épített KomPhone i5 13400F 16/32/64GB RAM RTX 5060 Ti 16GB GAMER PC termékbeszámítással
- HPE Apollo 4200 Gen9 2U rack szerver, 1x E5-2620v4, 64GB RAM, 24x3.5" 2U-ban! ÁFA-s számla, garancia
- BESZÁMÍTÁS! ASUS B450 R7 2700X 16GB DDR4 512GB SSD RTX 2060 Super 8GB Zalman i3 FSP 600W
- Bomba ár! Dell Latitude E5550 - i3-5GEN I 8GB I 128GB SSD I 15,6" HD I W10 I HDMI I Cam I Gari!
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged