Új hozzászólás Aktív témák

• #2292 Lauda félisten subaruwrc #2290

  Új Válasz 2008-12-16 20:37:07 #2292

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Lauda

  félisten

  válasz subaruwrc #2290 üzenetére

  Gondolom akkor Te érted.

  Ha annyira értitek, akkor ezt lefordíthatnátok nekem:

  [I]Csapjunk a közepébe, először is lássuk a futószalagot, a teljesítményt befolyásoló újításokat a front-endtől a back-endig! Az utasítások előbehívásáért felelős terület némileg megváltozott. Az előbehívó továbbra is 16 byte széles, de az elágazásbecslő javult; egyrészt az L2 elágazásbecslő színre lépése miatt (másodszintű BTB, azaz Branch Target Buffer), másrészt az RSB (Return Stack Buffer) továbbfejlesztésének köszönhetően. Ezekkel az újításokkal nem csak magának a becslésnek a pontosságán javítottak, hanem a rosszul megjósolt elágazásokból fakadó cikluskiesésekből is sikerült lefaragni; az Intel szerint ez egyszerűen a legjobb elágazásbecslő logika, ami létezik (mi mást mondanának). A macro-op fúzió is jobb lett, mint volt, ez már a JL/JNGE, JGE/JNL, JLE/JNG és JG/JNLE utasításpárokat is képes összefűzni, ráadásul működőképes 64-bites üzemmódban. (Ami zavarbaejtő, ugyanis az előbehívó szélessége változatlan, márpedig a Core 2 esetében azért vetették el a használatát, mert a prefixek miatt az előbehívó nem képes optimálisan működni.) A Core 2-ben az előbehívó után és a dekódoló előtt található a 18 utasítás tárolására képes Loop Stream Detector (végülis egy mini-cache), ami a tizennyolc x86-os utasításnál (macro-op) rövidebb (és külső szubrutinra nem mutató) ciklusok tárolásával és újravégrehajtásával gyorsítja a futást. A Nehalemben található LSD már a dekódolók után helyezkedik el, és 28 micro-op tárolására lett felkészítve (különböző mérések szerint ez kb. 20-23 x86-os utasításnak felel meg). Az a tény, hogy az LSD immár az x86-os utasítások (macro-opok) helyett a belsőleg használt RISC-szerű utasításokat (micro-op) tárolja lehetőséget ad a futószalagon előtte elhelyezkedő részegységek (elágazásbecslés, előbehívás, dekódolás) lekapcsolására, ráadásul a dekódolás lépésének kihagyásával közvetlenül áll összeköttetésben az OoO-motorral, ami szintén gyorsulást hoz magával. A Dedicated Stack Manager és a dekódolás nem változott semmit, három szimpla és egy komplex dekóder végzi a munkát (arról nem szól a fáma, hogy a szimpla dekóderek okosabbak lettek-e).

  A Nehalem felépítése [+]

  A dekódolást követően az utasítások (az LSD után) a ReOrder Bufferbe (ROB) kerülnek. A Nehalemben található ROB-ot 96-ról 128 bejegyzés szélességűre bővítették. Erre a Nehalemnek szüksége is van a Hyper-Threading-technológia miatt, amiről később még szó esik. A függőségek kivizsgálása után, miután elérhetővé válnak az operandusok, az utasítások a Reservation Stationbe (ütemező) kerülnek, ami szintén szélesedett, 32 helyett 36 bejegyzés tárolására képes. Az ütemező az utasításokat/operandusokat a végrehajtó egységek felé továbbítja, ezek száma változatlan a Core 2-höz képest, összesen 3 porton keresztül áramlanak át az adatok (Port 0/1/5) a három lebegőpontos, két egészszámos, illetve három SSE végrehajtó felé. Az ötös porton található végrehajtó kiegészült egy-egy lebegőpontos és integer biteltolást végző blokkal, de ezt leszámítva a végrehajtók nem változtak semmit.[/I]

  [ Szerkesztve ]

Új hozzászólás Aktív témák