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

• #1317 P.H. senior tag dezz #1295

  Új Válasz 2007-08-04 18:38:28 #1317

  Ú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

  

  P.H.

  senior tag

  válasz dezz #1295 üzenetére

  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 ˙˙˙

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