Ha pl. a ''nemsokára'' megjelenő új asztali amd cpu-k nem fognak működni a most kapható am2 lapokban, akkor az amd be**ja. Furcsa lenne ha így lenne. Ettől függetlenül felőlem legyen am3, ddr3, stb, de ha az elődje, vagyis a mostani am2 is ''röpke életű'' lesz, az csúnya dolog lenne.
Eddig azt nyilatkozták hogy hosszabb életet szánnak az am2-nek. Remélhetőleg nem ígéret.
Nem kevésbé fontos hogy szinte az össz. lap gyártója gondoskodjon a megfelő biosról (amitől már most félek...)

[Szerkesztve]

Az már elvileg hivatalos, hogy az AM2 és AM2+ kompatibilis.

Az AM2 és AM2+ egyezik meg teljesen fizikailag. Az AM3 kérdéses, lehet, hogy olyan lesz nagyjából, mint a többi, de már kevesebb láb lesz a procikon, és nem lehet tudni, hogy belemennek-e majd a foglalatba az AM2+-os procik. Egyes hírek szerint igen, más hírek szerint nem.

AM2: DDR2, HT1.1/2.0, non-split power planes
AM2+: DDR2, HT1.1/2.0/3.0 támogatás, split és non-split power planes támogatás (*)
AM3: DDR3, HT3.0, non-split power planes only

(*) AM2 tokos procik: non split power planes; AM2+ tokosok: split power planes

rollins: azért kell majd hozzá BIOS-támogatás is, azaz friss BIOS, ami lehet, hogy 1-2 esetben nem lesz. Ismertebb lapoknál biztos lesz.

[Szerkesztve]

Köszi a pontosításokat, meglátom még, hogy hogy fogok dönteni
Egyelőre marad a már betervezett ram csere, aztán majd később még eldöntöm, hogy váltok-e, vagy várok

Ha magányosnak érzed magad, indíts el egy horror filmet és kapcsold le a villanyt. Egyből nem érzed majd magad egyedül ;)

szerintem majdha kijöttek az első tesztek és látjuk a boltba mennyi onnan van értelme ezen gondolkozni....

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

Az már majdnem olyan, mint a DDR400 CL2,5 (pontosan CL2,665). Ez mitől rossz, amikor DDR400-ban CL3 volt az átlag RAM?

Az AMD CPU-k az adatok gyors elérésére mennek rá, kisebb köztes tárolás melett. Nekik jobb az alacsony késleltetés, mint a magas freki. Az új csúcsprocesszoraik kibővített gyorsítótár rendszere ezen valamelyest talán segít, de mindenképpen olyan irányban megy a rendszermemória fejlesztés, ami az AMD-nek kedvezőtlen.
(Pláne, ha az Intel átáll, azzal viszi a memóriapiac háromnegyedét, így a gyártókon keresztül kényszerítve az AMD-t is az esetleges idő előtti váltásra.)

+ nagyon szép a nyers sávszélességbeli összevetés, csak kérdés valójában hogyan jelenik ez meg a rendszer teljesítményében.

Vannak még tartalékok különben a DDR2-ben: [link]

Software Optimization Guide for AMD Family 10h Processors
[link]

Privat velemeny - keretik nem megkovezni...

Átnéztem, de egyelőre nem találtam magyarázatot a következőre.
Van itt egy ilyen: AMD Talks Details on K10 [link]
Van benne egy ilyen rész:
''K10 will introduce a shared L3 cache while the individual cores have dedicated L1 and L2 caches. As long as requested data lies in L1, it can be directly loaded. This also works if the data lies in the L1 cache of another core, in which case the communication works via the crossbar switch.''

Van valami elképzelésed, miért és hogyan mehet ez a crossbar-on, amikor az elvileg a L3 ''alatt'' van (memóriához közelebb), és nem magán a L3-on keresztül, ami shared a magok között?

Szerintem ez valami elírás lehet, nem lenne túl logikus. Azt meg nem hiszem hogy technikailag csak így lehetett megoldani, bár ennyire már nem értek hozzá.

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

Ezen esetekben ki kell törölni az adott mag L1-éből a vonalat, és a másik mag L1-ébe kell átvinni. Mivel AMD-k esetében (Athlon óta biztosan) az L1 a fő cache (az L2 és az L3 is csak write-back victim cache), egy CPU-n belül csak egy helyen lehet az adott adat. Tehát nem lehet beleírni az L3-ba, mert oda csak azok az adatok kerülnek, amik »helyhiány« miatt kerülnek ki az L1-ből.

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

Na nem mintha nagyon értenék hozzá, de valószínűleg Athlon előtt is így volt, lévén a K6+ szériát leszámítva csak L1 cache volt a CPU-ban.

"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." (Albert Einstein)

Úgy látom sokan nem látják a fától az erdőt, de meg merem kockáztatni, hogy inkább arról van szó, hogy nem tudják miről beszélnek.

Szerinted mi tart tovább: 50km/h-val 50km levezetése vagy 100km/h-val 100km levezetése?

Mégiscsak működött az intel marketing, mindenki csak abszolutértékben bír gondolkodni, mert ott nagyobb számok vannak. Csak memória esetén kicsit kifordult a dolog...

Nézük a lényeget:

Az első DDR szabványt 2000. júniusában adta ki a JEDEC, a jelenleg érvényes utolsó változat: [link] A legmagasabb szabványosított órajel a DDR400.
DDR200 CL2,5: 1000/100 = 10 -> 25ns ciklusidő (igen, anno így indult a DDR!)
DDR266 CL2,5: 1000/133 = 18,79ns (ez pedig a kezdeti csúcs DDR)
DDR400 CL3: 1000/200 = 5 -> 15ns ciklusidő (a tipikus DDR400)
DDR400 CL2,5: 1000/200 = 5 -> 12,5ns ciklusidő
DDR400 CL2: 1000/200 = 5 -> 10ns ciklusidő
DDR400 CL1,5: 1000/200 = 5 -> 7,5ns ciklusidő
DDR500 CL3: 1000/250 = 4 -> 12ns ciklusidő
DDR600 CL3: 1000/300 = 3,33 -> 10ns ciklusidő
DDR600 CL2: 1000/300 = 3,33 -> 6,66ns ciklusidő (a csúcs DDR, a technológia megjelenése után ~4-5 évvel.)

A JEDEC 2003. szeptember 12-én adta ki a DDR2 szabványt, a jelenleg érvényes utolsó változat: [link] A legmagasabb szabványosított órajel a DDR2-800@5-5-5
DDR2-400 CL4: 1000/200 = 5 -> 20ns ciklusidő (Indulásnak.)
DDR2-533 CL4: 1000/266 = 3,76 -> 15,05ns ciklusidő
DDR2-667 CL5: 1000/333 = 3 -> 15ns ciklusidő
DDR2-667 CL4: 1000/333 = 3 -> 12ns ciklusidő
DDR2-800 CL5: 1000/400 = 2,5 -> 12,5ns ciklusidő
DDR2-800 CL4: 1000/400 = 2,5 -> 10ns ciklusidő
DDR2-800 CL5: 1000/400 = 2,5 -> 12,5ns ciklusidő
DDR2-1066 CL5: 1000/533 = 1,87 -> 9,38ns ciklusidő
DDR2-1066 CL4: 1000/533 = 1,87 -> 7,5ns ciklusidő (Ehhez is el kellett telnie ~3 évnek a szabvány publikációjától számítva.)

DDR3 szabvány jelenleg még nem létezik.
DDR3-1066 CL7: 1000/533 = 1,87 -> 13,1ns ciklusidő

Röviden tömören: A DDR3 lesz a legjobban, legkisebb ciklusidőkkel rajtoló DDR szabvány, méghozzá nem is kicsi előnnyel az eddigiekhez képest! A DDR3 jobbn indul, mint a legmagasabb szabványosított DDR volt (DDR400@3-4-4). Akkor mi is a gond?


VaniliásRönk: Ráadásul egyből a szabvány publikációjának idején...


P.H.: A K6-III-ban mintha lett volna on-die L2 cache...

[Szerkesztve]

Athlon előtt (igazad van) nem nagyon volt L2 az AMD CPU-kban, Athlonból is csak a Model 3 és 4 esetében, 1 és 2 esetében csak az L2-vezérlő volt a CPU-ban. Viszont a kérdés nem ilyen egyértelmű, mivel amíg AMD esetében az L1 valósítja meg a MEOSI-protokollt, Intel esetében pedig Pentium Pro óta az L2 a MEOSI-megvalósító, az L1 csak write-through olvasási cache (, legalábbis Netburst-ig bezárólag, pont ezért hibahatáron belül ugyanannyi náluk az L1 írási sebessége, mint az L2-é, és a non-temporal módon (közvetlenül L1-be töltött) adatok írását is megsínyli nagyon, Core-ról/Core2-ről nincs teljes infóm, de a shared L2 miatt 99%, hogy így van ott is).
Ennek következménye, hogy integrált memory controller-rel párhuzamosan az Intel-nek ki kell fejlesztenie a saját Crossbar-ját is. Vajon az az AMD szabadalma lehet? Végülis egymagos A64 óta használják...

[Szerkesztve]

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

Ami viszont érdekes lehet, az a következő: ''The L1 data cache can support two 128-bit loads or two 64-bit store writes per cycle or a mix of those.''
A K8 micro-architecture megjelenése óta van egy sejtésem (bizonyítani nem tudom), hogy az az irdatlan nagy (88 vagy 120 entries) floating-point register-file 64 (esetlegesen? 80) bites egységekből épül fel, ahol két szomszédos elemet egy egységként lehet kezelni (úgy, hogy az első páros sorszámú), így jön ki a 128 bites (vagy legrosszabb FPU esetben 80 bites) register-méret. A fentiekből az következne, hogy ez a továbbiakban is így marad, mivel sehol sem látok 128 bites store-t, csak 128 bites load-ot és feldolgozást (és az x87-műveletek K8-hoz képest nem változó latency-értékeit nézve igencsak 64 bites lehet ez a register-file).

[Szerkesztve]

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

''Tehát nem lehet beleírni az L3-ba, mert oda csak azok az adatok kerülnek, amik »helyhiány« miatt kerülnek ki az L1-ből.''

Az L3 már más: ''The L3 Cache, however, is not exclusive, but allows for a shared bit to be set. If a core loads data marked as shared, it will reside in the L3 cache and can be fetched by other cores as well.'' (Dailyteches szövegből, ua. bekezd., de a pdf-ben is benne van.)
Eszerint tehát a L3-on kersztül megy. De akkor hogy jön ide a crossbar?

Igen, minden valószínűség szerint így van. Főleg, hogy ''Stores are decoded into two 64-bit micro-ops'' (viszont van 128 bites Store-to-Load Forwarding). Lásd itt, 25. oldal: [link]

Egyébként szerintem x86-on nincs extended prec. FP.

Az idézeted (a .PDF-ben nem találtam ilyet) és az Optimization Guide között ott van az ellentmondás, hogy az idézet szerint ''The L3 Cache, however, is not exclusive,...'' a Guide szerint viszont ''The L3 cache is considered a non-inclusive victim cache architecture,...''. Szerintem egyszerű a dolog, hogy a jelenlegi K8 X2-k/Opteron-ok esetében is két mag közötti átvitelt a crossbar valósítja meg, ezen nem változtattak semmit.

De tegyük fel, hogy az L3-on keresztül menne: akkor a CPU-n belüli teljesen exlusive hierarchia miatt az egyik L1-ből/L2-ből kiíródna az adat az L3-ba (, amiatt onnan egy értékes vonal esetleg kikerülne a memóriába), majd onnan a másik mag L1-ébe, viszont az L3-ban nem maradhatna, ezért az L3 vonalát azonnal érvényteleníteni kell. Tehát az L3-ban levő értékes adatok mennyisége csökkenne feleslegesen. És gyanúm szerint ez lassabb is lenne, mint az eddig bejáratott crossbar-megoldás. NUMA architecture mellett sem ritka az ilyen adatáramlás, tehát ez jelentős L3-teljesítményvesztést jelentene, mert az L3 egy része folyamatosan üres/invalid lenne.

[mod]: ''Egyébként szerintem x86-on nincs extended prec. FP.''

[Szerkesztve]

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

Mint írtam, az idézet ugyanabból a bekezdésből van, a #409-ben linkelt DailyTech cikkből, ami egy bizonyos AMD-s illetővel készült, német lapban lehozott interjún ([link]) alapul. De úgy tűnik, a DailyTechesek félreértették az eredeti szöveget. Ime Babelfishes fordításban az ide vonatkozó rész:

''How admits already sufficiently is, AMD introduces with the K10 a third Cachelevel. This L3 Cache together can access all cores, while they have dedicated L1 and L2 Caches. Lie if those need data in the L1 Cache, can CCUa core them directly load. This functions also, if they lie in the L1 Cache of another CCU. In this case communication runs again over the CROSS bar. If the data lie in the L2 Cache, they are gotten into the L1 Cache and deleted in the L2 Cache. If the data lie in the L3 Cache, they can be loaded directly into the L1 Cache, without a detour over the L2.

If the L1 Cache is full, the oldest data are written there again into the L2 Cache, are this also fully, into the L3 Cache etc. into main storage. In contrast to the L2 Cache data loaded by the L3 Cache are not obligatorily rejected. Assistance of a Shared bit can mark the CCU core-spreading used data, it is then also to different cores at the disposal.''

Ez már egybe cseng a doksival:

''A.5.4 L3 Cache
The AMD Family 10h processor contains an integrated L3 cache which is dynamically shared between all cores in AMD multi-core processors. The L3 cache is considered a non-inclusive victim cache architecture optimized for multi-core AMD processors. Blocks are allocated into the L3 on L2 victim/copy-backs. Requests that hit in the L3 cache can either leave the data in the L3 cache—if it is likely the data is being accessed by multiple cores—or remove the data from the L3 cache (and place it solely in the L1 cache, creating space for other L2 victim/copy-backs), if it is likely the data is only being accessed by a single core. Furthermore, the cache features bandwidth-adaptive policies that optimize latency when requested bandwidth is low, but allows scaling to higher aggregate L3 bandwidth when required (such as in a multi-core environment).''

Naszóval, akkor azt mondod, hogy a másik mag L1-éből a L2 és L3 megkerőlésével, közvetlenül a crossbaron keresztül, a kérő mag L2-jét is megkerülve, kerül az adat a kérő mag L1-ébe. (Nem lenne olyan nagy ''csoda'', tekintve hogy mint írják a L1 és L3 között is van közvetlen kapcsolat, a L2 kihagyásával.) Nos, egy másik fórumon tanakodtunk erről, és én is pont ezt vetettem fel (oly módon megfogalmazva, hogy a crossbarnak vannak közvetlen vonalai a L3/L2 fölé is), mire majdhogynem lehülyézett valaki. De akkor mégis így van. (Kivéve, ha több mag is írja/olvassa, mert akkor a L3-ba kerül, és ott is marad.)

[Szerkesztve]

En inkabb az AMD dokumentaciora hagyatkoznak mint az Anandtech-es cikkre

Ha megnezed a 182 es a 216 oldalon a diagramokat akkor ott latszik hogy az Anandos szoveg lehet kicsit egyszerusitett. Az AMD az L1 es L2 cache-t szamitja a core-hoz a SRQ-t es az XBar-t mar nem. Viszont a 182-esen teljesen hianyzik az L3 a 216-al ellentetben.

Szerk.: Ha pedig a die photo-t nezed akkor ott lathato hogy valahol az SRQ/XBar-on keresztul kell hogy menjen a kommunikacio, az L3 kicsit ''messze van''.

[Szerkesztve]

Privat velemeny - keretik nem megkovezni...

[link]

Chapter 2.1

Privat velemeny - keretik nem megkovezni...

Ez a resz leir mindent szepen es tomoren:

''Wie bereits hinlänglich bekannt ist, führt AMD beim K10 ein drittes Cache-Level ein. Auf diesen L3 Cache können alle Kerne gemeinsam zugreifen, während sie dedizierte L1 und L2 Caches haben. Liegen die benötigen Daten im L1 Cache, kann ein CPU-Kern sie direkt laden. Dies funktioniert auch, wenn sie im L1 Cache einer anderen CPU liegen. In diesem Fall läuft die Kommunikation wiederum über die Crossbar. Liegen die Daten im L2 Cache, werden sie in den L1 Cache geholt und im L2 Cache gelöscht. Liegen die Daten im L3 Cache, können sie direkt in den L1 Cache geladen werden, ohne einen Umweg über den L2.

Ist der L1 Cache voll, werden dort die ältesten Daten wieder in den L2 Cache geschrieben, ist dieser auch voll, in den L3 Cache usw. bis in den Hauptspeicher. Im Gegensatz zum L2 Cache werden vom L3 Cache geladene Daten nicht zwangsweise verworfen. Mithilfe eines Shared-Bits kann die CPU kernübergreifend genutzte Daten markieren, sie stehen dann auch anderen Kernen zur Verfügung.''

Ugy van ahogy ertelmezted.

Akkor az AMD doksi 216-os oldalan azert van az az elrendezes ami, mert igy tudtak az L3-at megfeleloen abrazolni.

[Szerkesztve]

Privat velemeny - keretik nem megkovezni...

Mint az előzőből láthatod, már megtettem. Meg megnéztem a forrást is.
(Még szerencse, hogy több, mint 5 perccel utánam írtál, még egyesek azt gondolnák a szerkesztés miatt, hogy utánad rittyentettem össze a szöveget, volt már rá legalábbis egy eset. Mármint hogy rám fogták. )

#429: igen, ezt a részt dobtam be a Babelfish szájába, mert sajnos a német nem az erősségem.

[Szerkesztve]

Thx, ezzel még nem találkoztam.
A sejtésem onnan származott, hogy K7 óta azoknak az utasításoknak, amik az XMM-register-eknek csak egyik 64 bites (vagy alsó vagy felső) felén dolgoznak, az Intel CPU-khoz képest igen kis késleltetésük van, és DirectPath-on (nem is Double-on) keresztül dekódolódnak (viszont a 80 bit-es x87-adatoknak jó lenne egy egységnek lennie). Intel-eknek ilyen esetekben mindig kell egy plusz MMX_SHIFT micro-op is.

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

Hú, ez micsoda egy oldal... Remélem, a K10-zel is foglalkoznak majd egy kicsit.

Még egy szó a cache-kerülésről: végülis mindig átmegy rajtuk (már ami a logikai blokkjukat illeti) az adat, tehát rákerül a bemeneti vonalaikra, csak beíródás/kiolvasódás nélkül rögtön rákerül a kimeneti vonalakra is. (Ami az elektronikai megvalósítást illeti.)

Ja, meg a #424-ben kimaradt: '' ''Egyébként szerintem x86-on nincs extended prec. FP.'' '' -- A 80 bites fp-t hívják extended precisionnek, amiről úgy tudom, nincs x86-on.

Egyébként én úgy tudom, csak az SSE(2-3) lett egyidejű 128 bites, az FPU nem sokat változott. Vagy mégis?

[Szerkesztve]

Itt ez a sok doksi de meg nem vilagos hogy peldaul az orajelenkent elvegezheto 64bit SSE utasitasok is megduplazodnak e vagy nem a K8-hoz kepest. Mert a 128bit megduplazodik, de volt egy GDC2007-es AMD prezentacio es abban az volt hogy a 64bit nem. A PDF-bol amit kiolvastam viszont az jon le hogy igen.

Privat velemeny - keretik nem megkovezni...

Hans a bajnok Biztosan lesz K10-es cikk is, csak eltarthat egy darabig ha epp nem er ra.

80bit-es FP osidok ota van x87-ben.

Privat velemeny - keretik nem megkovezni...

''80bit-es FP osidok ota van x87-ben.

Aham, értem, oké.

Viszont itt ez a 64 bit/128 bit dolog elvileg csak az SSE-re vonatkozik, ami viszont nem tud ilyet, és tudtommal annak külön regiszterei vannak (64/128 bitesek). (Ezt a korábban erről elhangzottakkal kapcsolatban jegyzem meg.)

Az x87 FPU kód tehát elvileg nem gyorsabb, viszont valahol írják a doksiban (vagy a GDC2007-esben), hogy ha SSE-s kódra fordítunk, ekkor persze egy operandussal, akkor 64 bit esetén 2x-esére, 128 bit esetén 4x-esére gyorsul a végrehajtás. (Mondjuk x87-en nincs is 128 bites operandus, de gondolom, úgy értették, ahhoz képest, mintha 64 bites műveletekből raknánk össze.)

[Szerkesztve]

Hmm, úgy tűnik, rosszul emlékeztem erre az FPU vs. SSE dologra, mert a GDC2007-es pdf-ben ez van:

Vectorized SSE is very fast with SSE128
- Much faster than x87 & scalar SSE
- Double-precision is 2x faster than x87
- Single-precision is 4x faster than x87

És itt elég nyilvánvalóan rendes SIMD kódról van szó.

Viszont, valahol pedig szó volt az FPU-s, x87-es kód egy operandusos SSE-re (''scalar SSE'') fordításáról, hogy az gyorsabb, de akkor nem tudom, mennyivel.

ps. egy megjegyzés a PowerPC/Cell/Xenon procik VMX/AltiVec/Velocity Engine-jéről (mind ugyanaz): ez eleve 128 bites volt megszületésétől, mármint 128 bit/ciklus, mint amilyen a K10 most lett... A Xenonban ennek VMX128 verziója van, de ez nem úgy 128, mint az SSE128, hanem azt jelzi, hogy 128 regisztere van (+ néhány új utasítás).

[Szerkesztve]

Ha a 64bit SSE utasítások alatt a skalár SSEx FP-t érted, akkor azon a téren nem változott semmi. Sőt, a vektortéren kimondott kétszeres gyorsulás is idézőjeles egy picit. Összevetettem a K8-at és a K10-et (ezeket az értékeket használom port-optimalizációnál is programozáskor):
K8 esetében:
- ADDPD és ADDPS (2x64 vagy 4x32 bit): 5 órajel alatt, 2 órajelenként 1-et indítva
- ADDSD és ADDSS (1x64 vagy 1x32 bit): 4 órajel alatt, 1 órajelenként 1-et indítva
- FADD (32, 64 vagy 80 bit x87): 4 órajel alatt, 1 órajelenként 1-et indítva
- MULPD és MULPS (2x64 vagy 4x32 bit): 5 órajel alatt, 2 órajelenként 1-et indítva
- MULSD és MULSS (1x64 vagy 1x32 bit): 4 órajel alatt, 1 órajelenként 1-et indítva
- FMUL (32, 64 vagy 80 bit x87): 4 órajel alatt, órajelenként 1-et indítva

K10 esetében:
- ADDPD és ADDPS (2x64 vagy 4x32 bit): 4 órajel alatt, 1 órajelenként 1-et indítva
- ADDSD és ADDSS (1x64 vagy 1x32 bit): 4 órajel alatt, 1 órajelenként 1-et indítva
- FADD (32, 64 vagy 80 bit x87): 4 órajel alatt, 1 órajelenként 1-et indítva
- MULPD és MULPS (2x64 vagy 4x32 bit): 4 órajel alatt, 1 órajelenként 1-et indítva
- MULSD és MULSS (1x64 vagy 1x32 bit): 4 órajel alatt, 1 órajelenként 1-et indítva
- FMUL (32, 64 vagy 80 bit x87): 4 órajel alatt, órajelenként 1-et indítva

Eddig vektoros SSE-nél 2 micro-op-ra fordult az utasítás, amik egymási órajelekben léptek be a pipe-ba (DirectPath Double és 2 órajelenkénti programutasítás-szintű indítás) és az alsó 64 bites fél már a 4. órajel után elérhető volt. (Note: The low half of the result is available one cycle earlier than listed.). Most a decode és a port-issue sávszélesség lett kétszeres.
Ami jelentősebb változás, hogy egyidőben 2 helyett 3 MOVAPS/MOVAPD (128 bites adatmozgatás) indulhat el, a 128 bites logikai műveleteket az FADD is végezheti már az FMUL mellett, és csökkent a latency-jük is, valamint a shuffle utasítások végre nem VectorPath-on fordulnak, és az FADD is végezheti őket. Sőt, úgy néz ki, hogy minden, eddig FMUL általá végzett nem szorzásjellegű műveletet megkaphat az FADD pipe is.

dezz:
Az lebegőpontos algoritmusok ugyanazok maradtak, csak megduplázták a számoló egységek számát. Az FADD és az FMUL pipe így változott szélességében (az MMX-hez szükséges 8 és 16 bites egységeket nem sorolom):
- 2 db 32 bites adder/multiplier -> 4 db 32 bites adder/multiplier
- 1db 64 bites adder/multiplier -> 2 db 64 bites adder/multiplier
- 1 db 80 bites adder/multiplier -> 1 db 80 bites adder/multiplier
Ha skalár SSEx vagy x87 utasítást használsz, akkor ugyanaz a megfelelő méretű 0. sorszámú egység fog számolni, a feldolgozás sebessége azonos. Sőt, ugyanarra a micro-op-ra vetíti le őket a DirectPath decoder, csak a méret SSE esetén az utasításba van kódolva, x87 esetén pedig a FPU Control Word-ből veszi a méretet (az FLDCW tudomásom szerint sorbarendező utasítás még mindig). Csak ami skalár SSEx-ben 4/5 byte-os utasítás, az x87-ben 2 byte-os.

A párhuzamosság miatt jogosak a 2x és 4x értékek x87-tel szemben, de ennyi van benne, pont olyan marketingszöveg, mint az Advanced Media Boost, ami gyakorlatilag pont ugyanezt a szélesítést jelenti a másik oldalon.

[Szerkesztve]

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

Vielen Dank!

Privat velemeny - keretik nem megkovezni...

Miért nem jön ki a 2x-es sebesség (főleg, hogy 5 ciklus helyett 4 alatt megvan a 2x64 v. 4x32 bit), legalábbis egy egymás után csak SIMD utasításokat tartalmazó programrészben? Vagy úgy érted, ott kijön, csak nem lehet túl hosszan ezt csinálni, plusz ''etetni is kell'', így a gyakorlati telj. kisebb?

Apropó, ha 2x annyi lett a számoló egységek száma, miért nem szélesítették ki a scalar x87 kód superscalar végrehajtását ezekre is? Akkor az is szépen gyorsulhatott volna...

''Az lebegőpontos algoritmusok ugyanazok maradtak, csak megduplázták a számoló egységek számát.''
Persze, nem tudom, honnan vettem ezt a 128 bites (egy értéket jelentő) operandust.

''- 2 db 32 bites adder/multiplier -> 4 db 32 bites adder/multiplier
- 1db 64 bites adder/multiplier -> 2 db 64 bites adder/multiplier''
Hmm, külön vannak 32 és 64 bites egységek? Azt gondoltam volna, 64 bites operand esetén összekapcsolva működik 2 32 bites egység. Vagy ilyen esetben esetleg függetlenül működhetnek, más utasítást végrehajtva? (Nem látom ennek jelét mondjuk.)

''Ha skalár SSEx vagy x87 utasítást használsz, akkor ugyanaz a megfelelő méretű 0. sorszámú egység fog számolni, a feldolgozás sebessége azonos. Sőt, ugyanarra a micro-op-ra vetíti le őket a DirectPath decoder, csak a méret SSE esetén az utasításba van kódolva, x87 esetén pedig a FPU Control Word-ből veszi a méretet (az FLDCW tudomásom szerint sorbarendező utasítás még mindig). Csak ami skalár SSEx-ben 4/5 byte-os utasítás, az x87-ben 2 byte-os.''
Szóval, az x87 itt (illetve kb. 2 generáció óta) használhatja az összes fp regisztert? Korábban ugye volt valami olyasmi probléma, hogy kevés volt a reg, és állandóan a stackba kellett pakolgatni (nem ismerem az x86-os arch.-t ennyire, csak valaki valami ilyesmit magyarázott).

''A párhuzamosság miatt jogosak a 2x és 4x értékek x87-tel szemben, de ennyi van benne, pont olyan marketingszöveg, mint az Advanced Media Boost, ami gyakorlatilag pont ugyanezt a szélesítést jelenti a másik oldalon.''
Azért pl. a C2D is elég szépen gyorsult tőle, 4x32 bit v. 2x64 bit SIMD-ben közel kijön a 2x-es seb., azonos órajelű P-D-hez képest. (Csak mondjuk a C2D nem megy akkora órajeleken gyárilag.)

Azt hiszem, itt azért látványosabb lesz a dolog, mert megvan az órajel, sőt magasabb is a K8-nál szokásosnál.

[Szerkesztve]

Megjegyezném hogy a P4D-ről a C2D SSE végrehajtása nem csak a 128 bites engine miatt gyorsult jelentősen.

Lássuk pár SSE2 utasítás késleltetési / ütemezési idejét:

MOVAPD xmm,xmm: 7 / 1 ---> 1 / 0,33
ADDPD xmm,xmm: 5 / 2 ---> 3 / 1
MULPD xmm,xmm: 7 / 2 ---> 5 / 1

elméleti sebességnövekmények:

Adatpakolászás: 7*1/1/0,33 = x 21,0
Összeadás: 5*2/3/1 = x 3,33
Szorzás: 7*2/5/1 = x 2,8

A K10-re visszakanyarodva, az alábbiakra számíthatunk:

MOVAPD xmm,xmm: 1 / 0,33
ADDPD xmm,xmm: 4 / 1
MULPD xmm,xmm: 4 / 1

Ez versenyben van a Core2-vel.

''Ez versenyben van a Core2-vel.''

Azt hiszem valos alkalmazasokban le fogja korozni a C2D-t.

[link]

A C2-nek 3 darab egyciklusos 128bit-es SSE egysege van a K10-nek csak 2 de a C2-nel a frontend a szuk keresztmetszet igy eleg nehez neki orajelenkent 3 utasitasal ellatni az egysegeket. Ezert is nem alazza jobban a K8-at sem azonos orajelen. Az egyetlen teszt ahol tenyleg komolyan megmutatkozik hogy ott vannak azok az SSE egysegek a Sandra fraktal tesztje. Meg a durvan SSE-re optimalizalt render programoknal sincs akkora elonye a K8-hoz kepest mint amilyenre az ember szamitana csak az feldolgozo egysegek osszehasonlitasaval.

A linkelt abran nagyon latszik mennyire sovanyka a P4 a C2-hoz kepest


[Szerkesztve]

Privat velemeny - keretik nem megkovezni...

Visszatérve még erre:
''- 2 db 32 bites adder/multiplier -> 4 db 32 bites adder/multiplier
- 1db 64 bites adder/multiplier -> 2 db 64 bites adder/multiplier
- 1 db 80 bites adder/multiplier -> 1 db 80 bites adder/multiplier''
Nos ugye felvetettem, hogy ebben az esetben kihasználhatnák ezt az FPU kód superscalar végrehajtásában, 2+x telj. elérve (+ pl. a 2. 64 bites, ill. 2-4. 32 bites egység más-más utasítást hajthatna végre SSE-ben is), de erről nem szól a fáma. Talán itt a megoldás:

Nagyban: [link]
Ezen ugye az látható, hogy 1-1 egész - adott műveletet végző - egység lett 128 bites. 1x64 bitnél nyilván csak a fele működik...
Csak nem értem a 128 bites FADD-ot és FMUL-t, amik ugye sima FPU-s egységek.
Egyébként működhet egyszerre az összes egység? Gondolok itt kevert SSE+FPU kódra.
Ja, meg még egy dolog: ha csak 2 SSE egység van, és 4 órajel alatt végeznek, akkor effektíve 2 órajelenként lehet új műveletet indítani, nem? Közben asszem ''rájöttem'': 4-ből csak 1-ben van ide vonatkozóan használatban az egység, 1 a load, és 2 a store? Akkor már értem, mire jó a több portos cache.

akosf: Nagyszerű, de hogy lesz ebből 1.5x telj. (fp), azonos, vagy épp alacsonyabb órajelen?

[Szerkesztve]

Az a kep a 128bit-es ujitas bemutatasara szolgal legfokeppen. Ezert hianyzik rola egy csomo dolog amit a picike FMISC komponensel inteztek el.

''Egyébként működhet egyszerre az összes egység? Gondolok itt kevert SSE+FPU kódra.''

Keverni keverhetsz, ez eddig is lehetseges volt. Viszont az hogy allandoan ellasd mukaval az osszes feldolgozo egyszeget az lehetetlen.

Privat velemeny - keretik nem megkovezni...

Oké, és? Ezzel (1.) tulajdonképpen mit akarsz mondani?

Csak annyit hogy gyakorlatilag a komplett x87 pipeline hianyzik a keprol.

Csak nem értem a 128 bites FADD-ot és FMUL-t, amik ugye sima FPU-s egységek.

Az SSE+FADD es SSE+FMUL egy-egy egyseg a ket-ket feladatra (x87 es SSE). Lasd itt: [link]


[Szerkesztve]

Privat velemeny - keretik nem megkovezni...

Breaking News!
A tervezettnél magasabb frekiken jönnek a K10-esek! És talán hamarabb is! [link]
Az AMD dolgozók örömmámorban!

[Szerkesztve]

''Csak annyit hogy gyakorlatilag a komplett x87 pipeline hianyzik a keprol.''
Izé, és ez min változtatna? Így se, úgy se mehet függetlenül az egységek 2 64 bites fele, legalábbis sima FPU (x87) kóddal, szélesítve a superscalar végrehajtást.

''Az SSE+FADD es SSE+FMUL egy-egy egyseg a ket-ket feladatra (x87 es SSE). Lasd itt: [link]''
Ja, köszi, így már világos. (Szal az FMUL, FADD x86 és SSE2+ kódhoz is ''jó'', az SSE meg főleg SSE(1) műveletekre.)

Egy szó a hírhez: hmm, azért érdekes, hogy a 4-magosok 2.8, ill. 2.9 GHz-ig skálázódnak, közben a 2-magos meg az eddigi 2.9 (legújabb táblázatban 2.8) helyett csak 2.7-ig? Hogy is van ez?

[Szerkesztve]

Azt hiszem kicsit elbeszeltem melletted Visszaolvasva, arra gondoltal hogy a 2x128bit helyett 4x64bit operaciot hajtana vegre hozza pedig valamilyen x87 vagy SSE1 stb.? Ez lehetetlen mert a schedule/disptach nem tud annyi utasitast tovabbadni.

Privat velemeny - keretik nem megkovezni...