- Frissült a MediaTek középkategóriás ajánlata
- Xiaomi Redmi Note 5 Global
- Volkswagen ID.7 menetpróba
- Nothing Phone (2) - több, mint elsőre látszik
- Huawei P40 lite - kényszerpályán
- Google Pixel 6/7/8 topik
- iPhone topik
- Különleges kameraszettet kapott a Huawei Pura 70 Ultra
- Macrodroid
- Apple iPhone 15 Pro Max - Attack on Titan
Hirdetés
-
Lenovo Essential Wireless Combo
lo Lehet-e egy billentyűzet karcsú, elegáns és különleges? A Lenovo bebizonyította, hogy igen, de bosszantó is :)
-
Premier előzetest kapott a Sker Ritual teljes kiadása
gp Véget ért az early access időszak, a végső kiadás konzolokra is befutott.
-
Duotts F26 - megoldjuk erőből
ma 1500 watt összeteljesítményű biciklit kaptunk tesztre, amely a legalitás összes határán túl van, kontrollálni nem könnyű, de néha óriási élmény is.
-
Mobilarena
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
Raymond
félisten
''...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...
-
Raymond
félisten
''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...
-
P.H.
senior tag
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 ˙˙˙
-
-
P.H.
senior tag
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 ˙˙˙
-
P.H.
senior tag
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 ˙˙˙
-
laceeek
aktív tag
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 -
dezz
nagyúr
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] -
dezz
nagyúr
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! -
VaniliásRönk
nagyúr
-
ftc
nagyúr
Barcelona bemutató....[link] pár embernek
-
dezz
nagyúr
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] -
Oliverda
félisten
-
dezz
nagyúr
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] -
dezz
nagyúr
-
dezz
nagyúr
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).
-
bruce24
tag
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
-
VaniliásRönk
nagyúr
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)
-
VaniliásRönk
nagyúr
Az első videót sem bírtam végignézni, rosszul vagyok az ilyen marketing rizsától, de ahogy elnéztem az ürgének sem ez volt a nap fénypontja.
"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." (Albert Einstein)
-
dezz
nagyúr
válasz VaniliásRönk #679 üzenetére
Biztos azon izgul, vajon elhiszik-e a meghívottak, amiket mond. Végülis nem kis dolog forog kockán.
-
VaniliásRönk
nagyúr
Hát ha abból indulunk ki, hogy az AMD még nem reklámozott ''industry leading-nek'' olyan termékeket, mint a Katmai, Coppermine és Willamette, akkor elvileg ezen nem kellett volna izgulnia.
"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." (Albert Einstein)
-
dezz
nagyúr
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. -
dezz
nagyúr
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] -
P.H.
senior tag
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 ˙˙˙
-
dezz
nagyúr
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] -
P.H.
senior tag
Á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 ˙˙˙
-
#95904256
törölt tag
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.
-
dezz
nagyúr
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] -
szacsee
nagyúr
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! -
#95904256
törölt tag
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. -
dezz
nagyúr
válasz #95904256 #691 üzenetére
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] -
#95904256
törölt tag
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]
-
Raymond
félisten
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...
Új hozzászólás Aktív témák
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.
- OFF TOPIC 44 - Te mondd, hogy offtopic, a te hangod mélyebb!
- Frissült a MediaTek középkategóriás ajánlata
- ASUS routerek
- WLAN, WiFi, vezeték nélküli hálózat
- Total Commander
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Amazon
- 3D nyomtatás
- Kínai, és egyéb olcsó órák topikja
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- További aktív témák...
- Beszámítás! Intel Core i9 14900KF 24 mag 32 szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i7 6700K 4 mag 8 szál processzor garanciával hibátlan működéssel
- ! Intel 13700KF + ASUS TUF Gaming Z790 Plus D4 + Kingston FURY DDR4 3600MHz CL18 !
- Core i5 10400F BOX
- i3 8100/ ingyen automata