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]

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]

duplicatiton error - better go to sleep

[Szerkesztve]

Erm, most viszont egy érdekes ellentmondásra bukkantam.
Mint tudjuk, és a doksi is írja, 1 makroOP két mikroOP-ból állhat, amiből az egyik egy int v. fp művelet, a másik meg egy load/store/load-store. A DirectPath Single és Double-ről meg ezt írja:
''DirectPath Single Decodes directly into one macro-op in microprocessor hardware.
DirectPath Double Decodes directly into two macro-ops in microprocessor hardware.''

Namost, akkor mi a csudáért van, hogy 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. Pedig a fentiek alapján nyugodtan beférne az utóbbi is egy makroOP-ba, és így lehetne Single...

Az a gyanúm támadt, hogy az idézett rész (definíció) hibás, és nem 1 v. 2 makroOP-ra gondoltak ott valójában, hanem 1 v. 2 mikroOP-ra...

Nos ebben az esetben DirectPath Double esetén sem kellene lemondani a(z esetleges) 3,0-ás IPC-ről, hiszen valójában az is 1db makroOP, két mikroOP-pal.

[Szerkesztve]

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]

Ez az új Barcelona proci jobb lesz mint a Penryn?
Árban hogyan fognak viszonyulni egymáshoz?

szia..

[link]

''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?''

Lehet hogy nagyon leegyszerűsítem a kérdést (de ez csak is azért van mert ezen a talajon ez én ismereteim konvergál a nullához)

Akkor megvalósult lényegében utasítás késleltetési idejenek csökkentése?

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

A mostani x86-os processzorok több száz különböző utasítást ismernek, ezek közül egy pár utasítás végrehajtási ideje ( késleltetése ) valóban csökkent. A baj az hogy leginkább nem azoké amelyek a leggyakrabban fordulnak elő, ugyanis azokat már eddig is elég jól megcsinálták.

Például nagyon gyakori hogy két számot össze kell adnia a processzornak, azonban a fent említett regiszter-cserélés nagyon ritka a mostani programokban. Bár ez utóbbit is lehetne gyakrabban használni, de ahhoz még okosabb fordító programokra lenne szükség.

Igazából a legfájóbb pont hogy a K10-es továbbra is csak 4 órajel alatt fog tudni összeadni két lebegőpontos számot, míg a Core2-eseknek 3 órajel kell. Ezt csak kis részben kompenzálja hogy a dupla-pontos szorzásban viszont épp fordított ( 4:5 ) az arány.

[Szerkesztve]

''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.''
Igen, tudom, hogy elvileg így van. ;)

''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.''
Í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.

''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?''
Hát erről (is) beszélek. (Meg arról, hogy miért kell Double-nek lennie mindennek, ami két egységet dolgoztat, miközben ezek elvileg 1-1 mikroOP formájában egy mikroOP-ba kerülhetnének.) Az is érdekes lehet, hogy sok Double-nek 1/1 a throughputja. Bár 2/1-es v. 3/1-es nincs, de ez nem is csoda, hiszen két egységet foglalkoztat.

Gerr'y: mi is szeretnénk tudni a válaszokat ezekre a kérdésekre. Én azt gondolom, jópár dologban jobb lesz - azonos órajelen. Kérdés persze, milyen órajelek lesznek. Az ár meg valószínű attól fog függeni, hogy teljesít...

Andre1234: Én nem végeztem ilyen összehasonlítást, de azt ugye tudjuk, hogy a 128 bites utasítások (2-way 64 bit v. 4-way 32 bit SIMD) utasítások végrehajtási ideje alaposan csökkent, hiszen nem két 64 bites lépésben történik meg. És úgy tudom, ezen felül is gyorsult sok utasítás, plusz több utasítás mehet párhuzamosan.

''A mostani x86-os processzorok több száz különböző utasítást ismernek, ezek közül egy pár utasítás végrehajtási ideje ( késleltetése ) valóban csökkent. A baj az hogy leginkább nem azoké amelyek a leggyakrabban fordulnak elő, ugyanis azokat már eddig is elég jól megcsinálták.''
Kifelejted a 2 lépéses 64 bites -> 1 lépéses 128 bites végrehajtás általi gyorsulást, ami elég sok utasítást érint. Persze csak vektorkódnál, de ma már sok programot így írnak.

''Például nagyon gyakori hogy két számot össze kell adnia a processzornak, azonban a fent említett regiszter-cserélés nagyon ritka a mostani programokban. Bár ez utóbbit is lehetne gyakrabban használni, de ahhoz még okosabb fordító programokra lenne szükség.''
Ha jól tudom, a regiszter-rename által erre ma már nincs akkora szükség.

''Igazából a legfájóbb pont hogy a K10-es továbbra is csak 4 órajel alatt fog tudni összeadni két lebegőpontos számot, míg a Core2-eseknek 3 órajel kell. Ezt csak kis részben kompenzálja hogy a dupla-pontos szorzásban viszont épp fordított ( 4:5 ) az arány.''
Mint direkt ADD utasítás igen, de ha ''embedded'' a dolog, mint pl. FCMP, FMAX, FMIN, stb., akkor sokszor megvan 2 órajel alatt. Meg ugye nem csak ez számít, hanem a throughput is.

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.

Elnézést kell kérjek a #1288-as és részben a #1286 hsz miatt, hagyd figyelmen kívül, semmi értelme nincs, utólag olvasva. Így jár az, aki az ajtóból fordul vissza válaszolni (és a végtelen ciklusok mindig nagyon zavarnak). Sorry.

Az IPC 5 eléréséhez először azzal próbálkoznék, hogy a MOVQ helyett egy integer load-ot tennék a kódba, bár a throuhput-on ez elméletileg nem változtat:

''In general, instructions with load operations that execute in the integer ALU units require two more clock cycles than the corresponding register-to-register flavor of the same instruction. Throughput of these instructions with load operation remains the same with the register-to-register flavor of the instructions.
Floating-point, MMX technology, Streaming SIMD Extensions and Streaming SIMD
Extension 2 instructions with load operations require 6 more clocks in latency than the register-only version of the instructions, but throughput remains the same.''

Bár arra sem rémlik pontos adat, hogy a macro-op fusion egy órajel alatt történik-e.

Az XCHG EAX,EBX probléma szerintem egyszerűen feloldható, és máris itt a példa a 2 micro-opos Double-re: ezt úgy is meg lehet valósítani, a micro-opok először (egyszerre, még az ICU-ban) kiolvassák az EAX és EBX értékét, majd az execution unit-ba kerülve kiírják azt EBX-be illetve EAX-ba. Így teljesen függetlenek egymástól, akár egyszerre ''futhatnak le'' valamelyik két ALU-ban (a futás is képletes, mert igazából nem csinál semmit, csak mindkettő a megadott célra kiírja a forrásadatát, változtatás nélkül), ezért a latency 1 érték. Single-ben nem lehet megoldani, mert mindkét micro-op ALU-ba kerül, egy macro-opban pedig egy ALU-AGU micro-op páros kerülhet, amelyek függőségi viszonyban is vannak egymással, vagy legalábbi fix a lefutási sorrendjük (mint egyes esetben a Double-ok micro-opjainál is, de ebben nem vagyok biztos. A PUSH azért lehetett Single, mert ott a SUB ESP,04 műveletet a decode fázis ''végzi'', pontosabban a stack-engine, tehát belül az már csak egy egyszerű store. Mint ahogy a POP is egy egyszerű load, így talán könnyebben magyarázható a LEAVE és a CALL is).

[Szerkesztve]

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

''Í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]

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

''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]

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

Így már talán érthető. Az nem számít bele a latencybe, hogy egy-egy dekóder kimenete - a doksi Figure 8-a szerint legalábbis - 1 macro-op széles, így egy Double-nek 2 órajel alatt kellene elhagynia?

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? És tehát egy külön macro-op utasítja az LSU-t? Hát, ezzel kicsit ellentmond a Table 1-ben olvasható definíció:
''A single macro-op may specify—at most—one integer or floating-point operation and''
(Nem beszélve a folytatásról:
''one of the following operations:
• Load
• Store
• Load and store to the same address'')
Szal, egy Load-Store Unitos műveletet nem neveznék integer vagy floating-point operationnak, hanem sokkal inkább egy load/store/load-store operationnak.

A másik dolog, hogy az FPU-ban nincs külön AGU, így nem tudom, itt kinek szólna a load/store/load-store micro-op, ha nem az FSTORE egységnek... De az ciklusszámokból úgy tűnik, mégsem így van a dolog. Talán az FPU is az integer pipeline AGU-it használja, így az fp-s célzatú macro-op-ok load/store/load-store micro-op-jai az integer pipeline-on mennek keresztül?

szerk: ja, közben még írtál, azokat most olvasom.

[Szerkesztve]

Hmm, én csak azt figyeltem, hogy az ''FPU Pipes'' oszlopban mely egységek szerepeltek. Az x86/stb. asm-et nem ismerem. Tehát, az xmmreg2 (mem) egy regiszter-tartalommal indexelt memóriahozzáférés, vagy ilyesmi? Ahamm! Most már kezd a helyére kerülni a dolog. Már csak azt nem értem, hogy ilyenkor mi végzi el a memóriahozzáférést? Azt hittem, ahhoz az LSU is kell.

[Szerkesztve]

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]

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

Hali P.H.!

P.H.:ADDPS xmmreg1, mem DirectPath Single FADD 6 1/1

Hogy lehet itt kimutatni az L1 késleltetését?
Érdekelne hogy hol fog ''meglátszani'' ez a 6-os késleltetési érték...

[Szerkesztve]

Elnézést, hogy itt teszem fel a kérdést de ez a topik áll legközelebb a kérdezni valómhoz.
Valaki részletesebben leírná nekem, hogy mi lesz az a Fusion mi lesz az előnye és úgy egyáltalán.
Köszönöm!

Ha az ember féreggé teszi saját magát, ne csodálkozzon, ha rátaposnak.

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]

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

''#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''
Ezt most nem egészen értem.

''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)''
Ahamm. Eddig azt hittem, az AGU-k, azaz az Address Generation Unitok a nevüknek megfelelően memóriacímeket számolnak (pl. indexelésnél), és magát a műveletet egy LSU hajtja végre.

ps. előnyösebb lenne nem keverni egy válaszban jelzés nélkül mások szövegeit a címzettével.

#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?

7600GT: Fusion = a CPU és egy GPU közelebbi viszonyba hozása. Korábban úgy volt, hogy eleve egy chipre lesznek integrálva, de mivel ez egyelőre technikailag problémás (az AMD CPU-i SOI technológiához tervezettek, az ATI féle GPU-k meg nem, és az aktuális vonalszélesség is eltér), első körben a Torrenza platform keretében egy 2-foglalatos lapon az egyik foglalatba megy majd egy GPU, PCIe busz helyett a közvetlenebb HT buszon kommunikálva. A következő verzió meg az lesz, hogy egy tokba teszik őket, de 2 külön lapkán lesznek azon belül. Aztán majd úgy 2 év múlva jön az egy lapkára integrált változat.

A Fusionnek kétféle célja van:
- A feltörekvőben lévő GPGPU (General-Purpose computation on GPUs) alkalmazások gyorsítása - desktop/munkaállomás/szerver frontokon. Ekkor nem mint videovezérlő lesz kihasználva, hanem mint nagy mennyiségű számítást multiparallel elvégző egység. A GPGPU módszerről bővebben itt: [link]
- Költségcsökkentés - entry level desktop/laptop/egyéb mobil eszközök terén, mint integrált videovezérlő. (Igazából nem tudom, ez így miért jobb, mint ha a szokásos módon a chipsetbe lenne integrálva.)

Költségcsökkentés:
- hatékonyabban lehet kiválogatni az alacsony fogyasztású chipeket
- nem kell int. VGA-s chipseteket külön gyártani
- a teljesítményt is lehet növelni és hatékonyabban skálázni, ami a notikra nagyon ráfér
Szerintem.

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

Játékok terén lesz-e valami nagyobb előnye?
Engem leginkább ez érdekelne, mert a szerverek nem igazán érdekelnek.

Ha az ember féreggé teszi saját magát, ne csodálkozzon, ha rátaposnak.

Én viszont azt nem értem, hogy nem szivárogtak még ki teszteredmények. Core2 amikor megjelenni készült, már hónapokkal azelőtt lehetett sejteni milyen lesz, de itt semmi nincs. Egy hónappal a megjelenés előtt. Mit titkolnak ?

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

Bizonyára lesz. Persze nem a 2+ tokos Torrenzásnak, amit nem tömeges PC-s felhasználásra szántak, hanem ha terjedni kezdenek az egytokos változatok. A GPU-t egyes fizika-szimulációs effektekhez felhasználó Havok FX már ma is létezik, csak egyelőre elég kevés játék használja, mert egy ideig csak Nvidián volt elérhető, ott is csak egy 2. kártyán, és egyelőre amúgy is az összes GPU-kapacitásra szükség van a grafikához. Meg sokáig csak két egyforma kártyával működött az SLI, és ha már 2., ugyanolyan erős kártya, akkor azt inkább szintén grafikára használják, mint beáldozzák fizikára. ATI-nál is valami ilyesmi volt, ha jól emlékszem. Szal csak nemrég óta vált lehetővé, hogy a 2., esetleg 3. kártya valami olcsóbb lehessen, mint a másik(ok), amit már nem sajnál az ember fizikára használni. Viszont ettől még nincs mindenkinek SLI-s v. CF-es konfigja, így nem építhetnek erre a játékfejlesztők.

Kicsit más helyzetet teremt, ha kijönnek ezek a GPU-t a CPU mellett tokon belül tartalmazó ''procik'' (2008 vége felé). Ha nem lesznek túl drágák, valószínű sokan ráállnak majd (az érdekessége miatt is, a marketing gépezet is szépen nyomja majd, és nem utolsó sorban azért, mert pl. video- és hangfeldolgozásban is jól használható). És ha elég sok lesz belőle a piacon, már érdemes lesz foglalkozni vele a játékfejlesztőknek is. (Hiszen tömegesen adott egy rendelkezésre álló ''tétlen'' GPU, amit többek között elsősorban fizikára használhatnak.) Hozzátenném még ehhez, hogy a Nehalem vonalon az Intel is kihoz majd hasonló megoldást, tehát nem csak az AMD különlegessége lesz. Ketten együtt jobban el tudják terjeszteni ezt a megoldást.

slett27: A desktop változat fél év múlva jön, így a desktop teszteredmények még várhatnak. (Túl korán nem lenne előnyös kiszivárogtatni, mert az fontos információ a konkurenciának.) Egy hónap múlva a szerver változat jön, és arról kimerítő szerveres összehasonlítást publikált már az AMD.





[Szerkesztve]

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.

Több helyen olvastam a hálón ( de a forrásnak mindenki Fudot jelölte meg ) miszerint a quad K10-B2 1,08..1,38 V tartományban 1,6G..3,0 GHz közé skálázódik. De szeptemberben csak a B1 stepping jelenik meg 1,12..1,28V illetve 1,6G..2,7GHz skálázhatósággal. A B0-ra is van adat, erre 1,17..1,31V / 1,6..2,4GHz-et írtak.

Na, majd hiszem ha látom.

szerk.: Vajon Fud honnan veszi ezeket az adatokat? Vagy gyakorlott álomfejtő?

[Szerkesztve]

Conroe vs. Wolfdale teszt ( 2,33GHz ): [link]

Úgy tűnik a Penryn 5-8%-kal gyorsabb a mostani Core2-nél.
Bár az SSE4-gyel DivX 6.6 tesztben duplázott...

szerk.: és a döbbenet, a fogyasztás... az 30%-kal kisebb!

[Szerkesztve]

Bázze, HL2-nél több, mint 30%-os növekedés, DivX-nél meg tényleg duplázott. Mi a fene van ebben, ebbe már beleültettek pár sejtet a szürkeállományból?
K10 tényleg készülhet valami nagy dobásra, ez kezd elfajulni.

...

ami leginkább a +50% cache-nek tudható be.

Same rules apply!

Tudod jól hogy vannak olyan emberek akik még a betonba is belekötnek. Lehet hogy épp miattuk. Ha nem így tesztelték volna, akkor ugyanezek az emberek most azt kérdeznék hogy miért nem azonos frekin tesztelték őket. Vagy tévedek?

Kötözködni akarsz?

Cseppet sem döbbenet hogy ugyanaz a processzor kevesebbet fogyaszt kisebb feszültségen, hisz ez törvényszerű. Azonban itt kétféle processzorról van szó. Ráadásul a gyorsabb fogyaszt kevesebbet. Én cseppet sem számítottam rá hogy 30% lesz a különbség. Ezért döbbenetes számomra.

Ami miatt csökkenhet a fogyasztás:
30%-kal kisebb a csíkszélesség...
13%-kal kisebb a mag tápfeszültsége...

Ami miatt nőhet:
86%-kal több tranzisztor...
5-8%-kal nagyobb számítási kapacitás...

Ennek ellenére 30%-kal kisebb a fogyasztás.

Aztán persze, lehet bővíteni a listát.

Te tudod?

Mivel jobb ötletem nem volt így vettem a fáradtságot és levadásztam két die fotót a netről. Ezekből megnéztem hány pixel a cache, majd arányítottam a teljes képhez...

Conroe: 220 millió tranzisztor, ennek 38%-a az L2 cache ( 84 millió )
Wolfdale: 410 millió tranzisztor, ennek is 38%-a az L2 cache (156 millió ).

Ami azt jelenti hogy a +50% cache az 72 millió tranzisztort jelent.
Ebből már számolható a kérdésre a válasz: 72 / ( 410 - 220 ) = 38%.

Nem tudom, azért kérdeztem.

AMD's Barcelona architecture - July update

[link]

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

''...a másodszintű gyorsítótára is, pedig az jelentős fogyasztási és hőtermelő tényező szokott lenni, nem?''

Nem.

Privat velemeny - keretik nem megkovezni...

Vasárnap ismét demózik az AMD japánban.
- 3GHz Phenom FX
- RD790 chipset
- HD2900XT

[link]

csak nem válaszolnak a penicilin tesztjére???

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

AMD to launch Barcelona quad-core on September 10

AMD today sent out emails inviting analysts, media and industry representatives to what the company calls ''the most anticipated premiere of 2007''.

Barcelona will not arrive one day too early: While the company does not explicitly mention the new quad-core as the proponent of its announcement, there is little doubt what will be announced on this day. Matching a report published by the Inquirer published in June, AMD will unveil its new quad-core architecture, which the company so desperately needs to restore its competitiveness in the 2P server market and prepare itself for the arrival of Intel's Tigerton processor in the 4P segment.

If the Inquirer is right, then Barcelona will arrive with clock speeds of up to 2.0 GHz, while faster versions with up to 2.4 GHz are expected to be available during the fourth quarter of the year. If AMD keeps its promise of avoiding a paper launch, then Barcelona-based systems should be available for purchase beginning at launch or the day right after it, September 11.

The question now is when AMD will be able to follow up and bring the Barcelona architecture to the desktop. We were told by AMD representatives that Phenom will follow 60 to 90 days after Barcelona, which puts the introduction of the chip into the mid-November to mid-December time frame.

The Barcelona launch event will be held in San Francisco's Presidio, beginning at 6:30 PM on September 10.

[link]

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