''...de vajon az mennyi idő alatt, és hogyan végzi el a dolgát?''

Itt szovegertelmezesrol lehet sz. Az en verziom a kovetkezo:

''We find a very large block of logic with fourfold symmetry directly near the position were the 16 byte blocks of data are read and written from and to the instruction cache. We'll discuss the most likely candidate here, A fourfold incarnation of an earlier pre-decoder described in gate level detail in US Patent 6,260,134

This fourfold version can, according to the patent which describes it, pre- decode an entire line of 16 bytes in only two cycles by means of what it calls: massively parallel pre-decoding..........

..........The instruction pipeline may invoke the pre- decoding hardware in this case to initialize or correct the pre-decoding bits within only two cycles.''

En ugy ertelmezem hogy ket ciklus alatt vegez fuggetlenul attol hogy magatol tette a dolgat beolvasaskor vagy ahogy ott irva van ''something is wrong'' es soron kivul kell meghivni. Hosszabb vagy rovidebb ideig nem tarthat mert csak 16 byteos blokkal dolgozik.

Privat velemeny - keretik nem megkovezni...

''a pre-decode egység figyeli a dependenciákat''

Az biztosan nem. A pre-decode csak megprobalja megtalalni es megjelolni a parancsok parametereit egy blokkon belul. A dependenciakat csak a dekodolas es ''szeleteles'' utan lehet elvegezni a ROB-ban hogy az OOOE elv mukodjon.

Privat velemeny - keretik nem megkovezni...

Hogyan tudod párhuzamosítani több utasítás elejének és végének meghatározását, ha változó hosszú utasításokról van szó? Meg kell taláni az opcode byte-ot (byte-okat, mert 486/MMX/SSEx esetén a 0Fh prefix is ott van, 3DNow4 esetén kétszer is - 0F0Fop ), - és még szó sem esett még az REPZ, REPNZ, argumentum- , vagy címhossz-befolyásoló prefixek-ről, amik SSEx - x >=2 - esetében válnak fontos tényezővé- , a ModR/M által leírt címhez tartozó azonnali érték, a SIB-byte-ot, és az adathoz tartozó azonnal érték hosszát. (és ezek is 1/2/4/8 byte hosszúak, prefixről változóan).

[Szerkesztve]

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

Nem lehet, hogy több ponttól kezdve kezdi keresni a köv. utasítást? (Csak egy ötlet, mert nem ismerem közelebbről az x86 gépi kódját.)

ps. ''SSEx - x >=2'' - ezt manapság így írják: SSE2+.

Hali Rive!

Nem sikerült beizzítanom az AMD-féle CodeAnalyst-ot. Állandóan hibára fut amint indítani akarok egy profilt. Neked hogy sikerült működésre bírnod?

Viszont az Intel vTune -, ami az AMD-s CodeAnalyst birodalmi megfelelője - tökéletesen működik.

A 8/16/32/64 bites x86 készlet (folyamatosan bővítve a P1-ig) így néz ki:

- othogonális stílusú utasítások: op dest,src forma, ahol dest és src vagy register, vagy cím, vagy közvetlen adat lehet, de nem lehet op mem,mem forma, értelemszerűen a dest nem lehet közvetlen.
prefix | opcode | ModR/M(+SIB) | addr_offset | immediate (32 bitben a leghosszabb utasítás tizenvalahány byte-os lehet).
pl. lock add [edi+ecx*2+0000100h],eax vagy add eax,20h
Az kód alap cím- és adatméretet (default word = 16/32/64 bit, 8 bites adatméret mindenhol van, az más opcode) a kódszegmens bizonyos bitjei határozzák meg, ezért az addr_offset és az immediate egyenként 16/32/64 bites lehet. Lehetne, de ha valamelyik -128 és 127 között van, akkor az 8 biten kódolódik, decode idején előjelhelyesen kiegészítődik.
A default word méretek között egy-egy utasítás erejéig a 66h (adatméret) és 67h (címméret) prefixekkel lehet váltani, 64->16 és 16->64 váltás nincs. Az opcode kódolja az adatméretet (8 vagy default word), a ModR/M és a 32 biten megjelent opcionális SIB (scale-index-base) kódolja az memóriaoperandus címének formáját és hosszát (8 vagy default word méret), ha van egyáltalán, illetve az egyik vagy mindkét register-operandust.
- van egy nagycsomó egybyte-os egyoperandusú utasítás, közvetlenül opcode-ban kódolt argumentummal: nyolc külön darab INC, DEC, PUSH, POP,... utasítás van a 8 register-re, persze ezeknek van egy-egy 9. formája is, ami memóriaoperanduson dolgozik (ModR/M vagy SIB segítségével), minden 8 bit displacement-es feltételes urgásra (később 0Fh prefix-szel kiegészítve jelentek csak meg a default word displacement-es változatok).
- a 8086 átvette a 8085 jórészt klasszikusan akkumulátoros/célregister-es utasításait is, ezek is egybyte-os utasítások, pl. a MOVSD 32 bitet beolvas a ESI által mutatott címról, azt kiírja a EDI által mutatott címre, majd továbblépteti 4-gyel a megfelelő irányba (ezt a EFLAGS egy bitje mutatja). Ha emellé odateszünk egy REP/REPZ vagy REPNZ prefixet, akkor ezt annyiszor ismétli, amennyi ECX értéke kezdetben (meg ha időközben a ZERO FLAG beállt/törlődött, összehasonlító jellegűeknél, mint CMPSD, SCASD). Viszont ezek némelyikének is van 8 bit-es argumentuma. Rengeteg utasítás tartozik ide is.
- De hasonló jellegű utasítás máig az integer osztás (osztandó EDX:EAX-ben, eredmény EAX-be, maradék EDX-be), a port-I/O utasítások, és még sokan mások. Ezek egy 1 opcode byte-osak, egyik operandusuk fix, a másikat mondja egy ModR/M(+SIB) mondja meg.

Még leírni se egyszerű. És ez még csak a kezdet, a rendszerutasításokat, mint time-stamp counter, controlregister-ek, descriptor table register-ek kezelését hagyjuk inkább.

Az x87 utasítások opcode-ja 2 byte-os, az első (talán) 9 bit megegyezik, a többi 7 kódolja a műveletet, és hogy memóriacím vagy register a másik operandus, ha előbbi, jön a ModR/M(+SIB).

Időközben elfogytak az egybyte-os opcode-ok, így a 486-os időkben már egy 0Fh byte-ot is fel kellett venni az új utasítások elé (pl. CPUID, de azért csak sikerült pl. 8 darab BSWAP utasítást elhelyezni a táblában...), mint 'alternative instruction set' prefix, ez később elvesztette prefix jellegét (a decode-nál nem volt mindegy P6-ig), az MMX és az SSE1 utasításokban mindben benne van. Az AMD a három dínó idején egyszerűen megduplázta a 0F prefix-et, így ők már akkor 3 byte-os opcode-nál tartottak.
Az Intel sem fért bele teljesen a 2 byte-os opcode-ba SSE1 esetén, ezért ők mást találtak ki. A skalár és vektorutasítások (ADDSS és ADDPS) abban különböznek, hogy a skalár előtt ott egy REPZ prefix, innen ugyanaz a formája, mint a vektoros alaknak.
De az SSE2-t is ábrázolni kellett valahogy, az megint több, mint 140 utasítás, itt az 66h adatméret-váltó prefixet tettek az SSE1 és az MMX megfelelő alakjai elé. De hogy ne legyen egyszerű, a skalár floating-point SSE2 előtt nem 2 prefix van (66h és REPZ), hanem csak egyetlen REPNZ.

Az egészet fejeljük meg 64 bitben egy REX prefix-szel, hogy a plusz 8-8 általános és XMM registerhez hozzá tudjunk férni. Mindezek mellett az AMD és az Intel is bizonyos esetekben azt ajánlja, hogy NOP műveletek helyett a kód (cikluskezdés) 16/32 byte-os határra illesztését inkább az opcode-dal együtt nem értelmezhető prefix-ekkel tegyük meg (pl. x87-műveletek elé betett REPZ prefix-szel), mert a NOP-pal szemben ezek nem foglalnak macro-op és micro-op helyet...

A kód a kódban, tehát hogy egy ugró utasítás célja egy másik utasítás azonnali értékének valamely belső byte-ja, ami onnan önmagában is értelmes utasítás, még 8 éve is egyetemi vizsgatétel volt assembly-ből.

Nagyon egyszerűen: code segment az alapméretet adja, akárhány prefix lehet az opcode előtt, az opcode mondja meg az azonnali érték létét és hosszát, valamint, hogy van-e ModR/M byte, a ModR/M mondja meg, hogy van-e SIB byte, és utóbbi kettő, hogy van-e a címhez is azonnali érték. Mindezt módosítják a prefixek.
Erre mondják azt sokan, hogy ki kellene dobni az egészet a fenébe, és egy teljesen új (lehetőleg regularized instruction field alapú) utasításkészletre áttérni.

SSE2+ persze, addigra már megártott a sok .PDF, amit aznap olvastam

[mod]: ...ha csak egyszer sikerülne pársoros hsz-t összehozni.

[Szerkesztve]

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

Már megint nem keveset írtál, csak az nem világos belőle, legalábbis nekem, hogy lehetséges-e tetszőleges ponttól kezdve keresni a köv. utasítást, vagy csak a program legelejétől kezdve egyenként lehet lépkedni.

Mivel a ModR/M byte mind a 256 féle lehetősége értelmes, a SIB byte 256 féle lehetősége ugyancsak, illetve a prefixek és 1 byte-os opcode-ok egyesítve megintcsak kitöltik majdnem teljesen a 0..255 teret (egy-két üres hely lehet már csak benne, a REX prefix-nek is találtak még üres elemet, ezen kívül a 0Fh prefix és két segment override prefix jött be összesen utólag 8086 óta, mindkettő 386/486 alatt), azonnali értékek és címeltolások bármik lehetnek, így gyakorlatilag tetszőleges belépési pontban értelmes utasítás találtható.

Az utasítás meghatározásához pontos belépési pontra van szükség, lehet ez ugrás, CALL, RET, INT célja, vagy az előző utasítás vége.

[Szerkesztve]

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

sziasztok lenne egy olyan kérdésem h mikor jelennek meg ezek a procik




ja és bocsánat h nem olvasom a topikot el me elég hosszunak tunnik
THX a válaszokat

Az utóbbi (a teljesen megbízhatatlannál valamivel megbízhatóbb forrásból származó) infók szerint a nyáron jön a 4-magos Opteron, kb. szeptemberben a Phenom FX, Phenom X4, és november-decemberben a Phenom X2.

POV Bench eredmény egy 4-procis Barcelona szerveren: ''just over 4000'' pixel/sec. [link]
(Megjegyzés: a többprocis rendszerek nem egyenes arányosan gyorsulnak a procik számával, tehát egy Barcelona proci egyedül nem 1000 pontot hozna, hanem többet.)
szerk: ja, az órajeleket nem tudni.

[Szerkesztve]

Kicsit leült a topik... Már mindent megbeszéltünk? Akkor egy kis frissítés.

Igaza volt P.H.-nak, az RWT-s elemzésben van egy kis kavarodás a mikro-op/makro-op témában. Ezt többen jeleztük is a szerzőnek a fórumban. Kért, és kapott pontos AMD-s definíciót is. Elismerte, hogy ''talán nem ártana kicsit ápdételni a szöveget''. Kiderült, hogy ő az Inteles terminológiát használta, amiben máig az alap x86/x87/stb. kód a makro-kód (ill. makro-opok), és a RISC kód a mikro-kód (ill. mikro-opok) - viszont itt 2 ilyet lehet fúzionálni. Miközben AMD-nél a makrokód (és makro-opok) már a lefordított kód, és egy makro-op két mikro-opból állhat: egy ALU/FPU/stb. operáció, és egy load/store/load-store (ugyanazzal a címmel).

Tehát, a dekóderek és a Pack Buffer kimenetei AMD-s terminológia szerint x makro-op, nem x mikro-op. A retirementnél is makro-opokban kell számolni.

Persze lehetne az egészet az Inteles terminológia szerint venni, ekkor - látszólag - helyesek lennének az ide vonatkozó ábrák, csakhogy valójában nem azok, mert az jön le belőlük - amit a cikkíró le is vont -, hogy a C2D 33%-kal szélesebb, de ez tévedés. Ugyebár C2D 4 uop (amiből 1-2 lehet fúzionált is) = 4..6 uop vs. K8/K10 3..6 uop... Ugyanez igaz a retirementre is. Valaki direkt ki is próbálta: legjobb esetben 2 fúzionált, és 2 nem fúzionált uop mehet át a C2D-n.

Btw, ismeritek a PerfMonitort? [link] Jó kis program, könnyedén lehet vele nézegetni az aktuális IPC-t, és sokminden mást!

Barcelona bemutató....[link] pár embernek

nagyon szépen köszönö a válaszodat

Valamiért nem akaródzik elindulni...

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

Hmm, ez vicc? Nem néztem végig, mert beleuntam az ''áutpörform'' és hasonló kifejezések vég nélküli szajkózásába...

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

Figyelem! Fudzillás hír következik! [link]
(+ a Google sehol máshol nem találja az ''am2p_roadmap.jpg''-t.)

Ezek a sampling időpontjai, ami ha jól tudom, a gyártás elejét jelenti , utána még több hónap, mire igazán beindul a tömeggyártás!
Jól néz ki ott az a 2.8-as szám... Akkor talán tényleg igaz volt, hogy sikerült 500MHz-cel emelni a frekit a legutóbbi revizióban.
Viszont kicsit érdekes, hogy a 2.5-öshöz későbbi időpont társul.

[Szerkesztve]

az hogy lehet,hogy az egyik FX AM2+ foglaltaba kerül a másik meg Socket F-be?

Érdekes lesz a Computex
mivel még nincs leforditva a hir

Első alaplap AM2+

[link]


elméletileg ez már PCI-E ver2

[Szerkesztve]

Úgy hogy a Socket F-es FX a jelenlegi AMD 4X4-es (2 procis) rendszerek helyére megy, az AM2-es FX meg az egy procisokba. Jelenleg is létezik ilyen is meg olyan is.

"Minden negyedik-ötödik magyar fiatal funkcionális analfabéta – derült ki a nemzetközi felmérésekből. Az arány a felnőttek körében sem jobb."

Akkor erről szólt a #661-es. ;)

Btw, na jellemző... Az Intel a Microprocessor Forumon azzal villogott, hogy bezzeg az ő 2x4 magos (Xeon 5365) 3GHz-es rendszerük 4933-at hoz a POV-Benchben, és ''miért is venne valaki 16 magos rendszert az AMD-től, amikor a mi 8 magos rendszerünk gyorsabb?'' (lásd linkek a lap alján). Az AMD válasza: ''Azzal a bemutatóval nem éppen a lehető legnagyobb teljesítmény demonstrálása volt a cél, hanem a közel 2x skálázódásé egy dual-core Opteronos rendszerhez képest.'' - Mellesleg 65W TDP-n! (És csak x87 kódban, miközben SSE2+-ban inkább a 4x-t közelíti a dolog, hála a 128 bites SSE műveletvégzésnek.) Hozzátették: ''Lesz majd Xeonos összemérés is...''

VaniliásRönk: mi a vicc?

[Szerkesztve]

Igen erről szolt,de közel voltam hogy fejbe lövöm magam mikor végignéztem ....


igen ez a szép egy 8xxx-s Opteronban... közel 8x teljesitmény...még Intel 4 mag felett elég rendessen vissza esik...

''Igen erről szolt,de közel voltam hogy fejbe lövöm magam mikor végignéztem ....''


''igen ez a szép egy 8xxx-s Opteronban... közel 8x teljesitmény...''
Már úgy érted, 8db 8xxx egy 1xxx-hez képest?

''még Intel 4 mag felett elég rendessen vissza esik...''
Nem 4 proci felett?

a marketinges video....

igen ugy értetem,hogy 1xxx-hez képest....

Intelt is ugy értettem...

megint mást irok mint gondolok

Jahh, hang nélkül néztem (főleg csak az elsőt néztem végig, a másodikat nem lett volna sok értelme így).

AMD MAGOKRÓL egy összefoglaló táblázatot tud valaki?

"I have never made but one prayer to God, a very short one: 'O, Lord, make my enemies ridiculous.' And God granted it." -Voltaire

Hohó, hogy a két video egészen más. Én a másodikkal kezdtem, és nem bírtam tovább 2 percnél, lehet itt csúszott porszem a gépezetbe, az elsőt akkor megnézem.

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

Ars Technica-s elemzés a Barcelonáról: [link]

VaniliásRönk: hát, azért lehet némi feszültség a cégnél... Kisebb ATI-k is csúsznak, állítólag a Barci is 1-2 hónappal később kerül piacra a reméltnél, pedig minden egyes nap számít, stb.

Illetve ez elsősorban nem is a Barcelonáról szól, hanem az AMD jövőbeli terveiről, részben a korábbi WRT-s cikkre alapozva, melynek - megkérdőjelezhető, lásd korábban - konklúziója az volt, hogy a Barcolona majd inkább csak a multithreaded szerver applikációkban előzheti meg az Inteles vetélytársait, nem pedig a desktopon (legalábbis a korábbi 2.5 GHz-es max. órajelből kiindulva, ami viszont ugyancsak változott állítólag, felfelé). Ebből, és az ATI-s akcióból (GPU alapú számítások) kiindulva tehát arra jutnak, hogy az AMD inkább a szerver vonalra koncentrál, az Intel pedig a desktopra és a mobil vonalra. Számomra nem túl meggyőző...

[Szerkesztve]

Nem érkezik meg júliusban a Barcelona? Na az tényleg gáz.

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

Egy darabig az AMD tartotta magát az Intel-étől teljesen nomenklatúrához (például micro-op vs uop), teljesen jogosan, mert a funkcionális egységek azonos szinten is teljesen mást jelentenek (Intruction Control Unit vs Reorder Buffer), ez mára egy kissé összefolyt, nem kevés kavarodást okozva.

Kezdve ott, hogy az AMD-féle micro-op sokkal általánosabb, mint az Intel uop-ja, tekintve, hogy ez utóbbinak legfejlebb 2 bemeneti értéke lehet. Egyszerűbb esetben pl. az olyan utasítások, amik bemeneti értékként valamely flag-et is használják, mint az ADC reg,reg (eredmény=reg+reg+CarryFlag) két uop-ra fordulnak Intel esetében. Bonyolultabb ez eset címzéseknél: általános címzési forma a reg+reg*scale+offset (scale lehet 1,2,4,8), PPro-tól kezdve egészen Core2-ig lehet találni olyan információkat, hogy ezesetben nem egy uop-ra fordul a címgenerálás, hanem bizonyos ALU-műveletek sorozatára, ha nem csak reg, reg+reg vagy reg+offset formájú. Kardinális kérdés ez Netburst alatt lett amiatt, hogy a reg*scale kiszámítását egy külön shift uop végezte, aminek futása egyetlen portra korlátozódott (port1, complex ALU), 3 órajel latency mellett. Prescott-tól talán ezt kiküszöbölték, a latency 1 lett, kérdés, hogy mennyi maradt meg ebből a Core-családra.

uop-fúzió két esetben lehet Intel-nél, read-modify és store. Előbbinél a load+op egyesül (ez hasonló az AMD load+op macro-opjaihoz), utóbbi azt a kellemetlenséget szünteti meg, hogy egy store operation két uop-ból áll, store_address és store_data (maga a transfer), ezek két külön portra kerülnek még mindig, de decode után együtt haladnak. Ez AMD-nél egy uop, és ha hozzávesszük, hogy egy load+op+store (= op mem,reg) AMD-nél egy macro-op két micro-oppal, Intel esetében összesen 4 uop, amiból a load+op és a store_address+store_data két fuzionált párost alkot, akkor is lemaradásban van még AMD-vel szemben. Ráadásul ez a uop-fúzió a decode utáni lépés, tehát a 4-1-1-1 decoder-szélesség még mindig limitáló tényező.

Makro-opfúzió csak igen speciális esetekben lehet, csak bizonyos feltételes ugrások (amik nem kezelik az Overflow Flag-et, tehát csak előjeltelen esetben) és az azokat közvetlenül megelőző CMP vagy TST utasítások (amik céloperandusa nem memória) fuzionálhatnak. Ráadásul mindez 64 bites módban nem is működik Core2 esetén.


Ez előző, AMD pre-decode-dologhoz: zavart eléggé, hogy tényleg erőltetettnek tűnt az én mondatértelmezésem Raymond-ével szemben. Kérdezted, hogy ''lehetséges-e tetszőleges ponttól kezdve keresni a köv. utasítást'', erre én írtam, hogy ''gyakorlatilag tetszőleges belépési pontban értelmes utasítás találtható.''. A kettő nem zárja ki egymást, ha adott egy egység, ami párhuzamosan a beolvasott 16 (K10 esetén 32) byte-os ablak minden egyes byte-jától meghatározza az ott kezdődő utasítást. Kevesebből nem érdemes, az nem visz előre. Ha ez megvan, és adott az első utasítás belépési pontja, akkor akár egy órajel alatt ki lehet szűrni a 16/32 utasításból a valósakat. No de ki az az őrült, aki ilyen nem egyszerű felépítésű egységből - ismernie kell a teljes utasításkészletet - 16-ot (vagy 32-t) tesz egymás mellé egy CPU-ban.
Hát, az AMD az. Az adott szekcióból Raymonddal szinte az összes mondatot beidéztük, gyakorlatilag csak a lényeget nem (én teljesen átsiklottam felette akkor).
A second instruction can not be decoded until the length of the first instruction is known. The start position of the second instruction depends on the length of the first instruction. The massively parallel pre-decoder avoids this problem by first pre-decoding the 16 possible instructions in parallel. Each instruction starts at one of the 16 byte locations of the 16 byte line. It then filters out the real instructions with the help of the program-counter which points to the start byte of the next instruction, depending on where we jump into the 16 byte line.
[link]
K8 esetében egy-egy alapegység 1 órajel alatt meghatározza az adott byte-nál kezdődő utasítás hosszát és jellegét, 4-4 ilyen egység egy blokkba van rendezve, és 4 ilyen blokk van. Tehát 1 órajel alatt megjön az eredmény mind a 16 egységtől, amiből következő órajelben a Start/End Fixer/Sorter az ismert belépési pont segítségével kiszűri, melyek a valós utasítások. Intel esetében valószínűleg (legalábbis bizonyos esetekben) áll a step-by-step predecode, márcsak abból kiindulva, hogy az adatméret- vagy címméret-módosító prefix-szel ellátott utasításokat újra kell értelmeznie, információk szerint 6 órajel alatt (adatméret prefix pedig ismerős lehet SSE2-utasítások esetén).


Kicsit leült a hét elején, én az utóbbi 5 napban a Csabai Sör- és Csülökfesztiválra fordítottam az érdeklődésemet. Mondjuk inkább a sör-részére, mert csülköt én is tudok elkészíteni, sört viszont nem tudok főzni

[Szerkesztve]

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

Hát, ha még legalább konzekvensen a µop formát használná az Intel, az jó lenne, de állítólag egyes Intel doksikban a mikro-op formát használják. Bár ez még a kisebb gond, mert mikro-opban még valamennyire hasonlítanak egymásra, már ha nincs fúzió, de a ''makro-op''-jaik teljesen mást jelentenek.

''Prescott-tól talán ezt kiküszöbölték, a latency 1 lett, kérdés, hogy mennyi maradt meg ebből a Core-családra.''
Nem tudom, viszont a P4 vonalnak kevés köze van ehhez, mert a Core2 (a Core-on keresztül) a Pentium M-re épül (ami a P2-3-on kereszül a PPro-ra). ;)

Huh, nem sajnálták a tranzisztort és a területet attól a Massively Parallel Predecodertől...

Közben egy ilyet találtam a Core 2 predecodingjáról:
''7.15 Bottlenecks in Core2
Instruction fetch and predecoding
All parts of the pipeline in the Core2 design have been improved over the PM design so that the total throughput is increased significantly. The part that has been improved the least is instruction fetch and predecoding. This part cannot always keep up with the speed of the execution units. Instruction fetch and predecoding is therefore the most likely bottleneck in CPU-intensive code.

It is important to avoid long instructions in order to optimize instruction fetch and predecoding. The optimal average instruction length is approximately 3 bytes, which can be impossible to obtain.

Instruction fetch and predecoding is not a bottleneck in a loop that fits into no more than four aligned 16-byte blocks of code. The performance of a program can therefore be improved if the innermost loop has no more than 64 bytes of code or can be split into multiple loops that have no more than 64 bytes each.'' [link]
(Van itt szó másról is és más procikról is, érdemes átnézni.)


[Szerkesztve]

Általában a hivatalos gyártói dokumentációkra szeretek hagyatkozni, de én is ezt olvasgatom már majd' két hete. A szerző és foglalkozása, a last update dátuma és a bevezető általános leírások meggyőzőek.

Hivatalos Intel guide-okban én eddig csak a uop formát találtam.

A Prescott-os mondatom utólag olvasva eléggé félresikeredett, arra gondoltam, hogy abból, hogy a komplex címek ALU-uopok sorozatára fordulnak le, abból mennyi maradt meg (PPro-P2-P3 is 1 órajel alatt számolt shift-et, de már azok optimization guide-jában is szerepel, hogy it may change in the future implementations, Változott, nem előnyére). Végülis Core-vonalon nincs double-pumped ALU, és se a decode, se a uop-fusion nem hatékony, ha egy [esi+edi*8+record.offset] címszámítás 3 vagy 4 uop-ra fordul le.

És így végiggondolva, az Intel CPU-k hatalmas uop-gyárak, egy egyszerűnek látszó utasítás is elég sok uop-ra fordulhat le. Emellett a 4-1-1-1 decoder-felállás és a ROB mérete igen szűkös.

[Szerkesztve]

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

Annyit megjegyeznék attól hogy az Intel CPU-k uop gyárak, nem jelenti azt hogy nem hatékonyak. Ezen uop-ok valamivel egyszerűbb szerkezetűek mint a konkurens makro-opok, így egyszerűbb vezérlő logikát igényelnek. A Core2-es 96 uop-os ROB-ja még ha szűk keresztmetszetet is jelent, azért jelentősen nem marad le a K8 72 makro-op-os ICU-jától. Ehhez hozzátenném hogy szeretnék látni egy olyan kódot ahol ez jelenti a szűk keresztmetszetet, ugyanis erősen párhuzamos (OoO) végrehajtás szűkséges hozzá. Más szóval egy ilyen limitet csak magas IPC értékű kóddal lehet elérni, ami még ritka.

Pl. ''Inside Intel Core Microarchitecture. Setting new standard for energy-efficient performance'' white paper by Ofri Wechsler.

akosf: Az egyszerűbb vezérlő logika gyorsabb végrehajtást eredményez, vagy hogy érted? Vagy tranyószám/teljesítményben?

A Core2 a Pentium M-en alapul, ami - mobil proci lévén - spórolós design volt, főleg az aktuális csíkszélességhez képest (ami asszem 90nm volt). Aztán ezt némileg kibővítették, de csak annyira, hogy gyorsabb legyen, mint a K8. Viszont így maradt benne néhány szűk keresztmetszet. (Lásd alábbi linken, mik azok, magát a ROB-ot nem látom köztük.)
A K10-nél eleve a 65nm-hez (sőt talán már a későbbi 45nm-hez [értsd: 45nm-en lesz igazán gazdaságos]) alkalmazkodtak, azaz jóval kevésbé spóroltak a tranyókkal, vonalakkal.

[Szerkesztve]

Hali a guruknak!

Lenne egy kérdésem, ha most veszek ramot (800-as DDR2), akkor a jelenlegi lapom ha támogatja a K10-et, akkor a memó elég neki, vagy csak 1066-ossal megy majd 100%-osan?
Tuningram lesz, megy valszeg 1066-on, de ha nincs benne az spd-jébe (remélem jól írtam), akkor lesz belőle hátrányom?
Kösz a válaszokat előre is!

Dezz, néha becsinálok azon amit az AMD mond. Ez a majd ''45nm-en lesz gazdaságos'' dolog is egy kicsit fura. Meg az is hogy a Brisbane magos processzorok gyorsítótára azért lassabb mert így majd nagyobbat lehet gyártni. Na jó, de melyik Brisbane magos prociba tudom utólag belerakni a nagyobb gyorsítótárat? Gondolom a 65nm-es processzorhoz meg majd zsugorítót fognak árusítani...

Az hogy egy vezérlés egyszerűbb vagy bonyolultabb, nem lényeges a számunkra ha ugyanazt a teljesítményt nyújtja. Viszont ami egyszerűbb, azt könnyebb fejleszteni.

A Brisbane-os dolgot én sem értem, de a 45nm-eset nem az AMD mondta, hanem én gondolom, illetve elég logikus. Ti. az Intel azzal ''cikizte'' a Barcelonát, hogy egy ekkora chipet nem lehet jó kihozatallal gyártani (és hogy ezért jobb az ő 2x2 magos megoldásuk). Nos, ez nyilván túlzás, viszont 45nm-en lesz igazán gazdaságos a K10 arch. (4 magos esetén).

Ugyanazt a teljesítményt hozza? ;) Elvileg nem. Attól meg szerintem nem lesz bonyolultabb, hogy szélesebbek egyes adatutak, nagyobbak egyes bufferek, stb. A többi meg adott, legalábbis egyelőre.

[Szerkesztve]

Hali szacsee!

Természetesen minél gyorsabb a RAM-od annál jobb.

Azért remélem hogy a DDR2-800 CL4-es RAM-ok is jók lesznek. Legalább a Kuma magosokhoz. De messze van még július...

Kicsit off-topic leszek, de találtam egy X-bit labs tesztet az AMD 4x4 és az Intel V8 platformok összehasonlításáról: [link]

Érdekes, hogy néhány dologban a 2db-os FX-es konfig dual-core létére megközelíti... (Memória-kezelésben meg jobb is.) Mi lesz, ha jön a Barcelona?

itt érződik a direct connect előnye:

extra

Jo napot uraim...nem voltam elerheto tobb mint egy hetig, de lagalabb valami joval terek vissza

[link]

AMD Phenom X4 hi-res die photo...

Privat velemeny - keretik nem megkovezni...