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

• #934 dezz nagyúr P.H. #930

  Új Válasz 2007-06-14 00:15:13 #934

  Ú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

  

  dezz

  nagyúr

  válasz P.H. #930 üzenetére

  Nézd csak ezt:
  
  As of writing this Core 2 supports ld+ex and st(a)+st(d)
  uOP fusion, and one load plus one store per cycle.
  
  This suggests that at most two fOPs can show up for re-
  tirement per cycle, plus another two uOPs.
  
  I got a piece of code that can sustain the retirement of
  two fOPs plus ~1.75 uOPs per cycle -- so I'm reasonably
  certain of these limits.
  [link]
  (fOPs = fused uOPs)

• #932 #95904256 törölt tag P.H. #930

  Új Válasz 2007-06-13 22:15:37 #932

  Ú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

  

  #95904256

  törölt tag

  válasz P.H. #930 üzenetére

  Hali P.H.!
  
  A hozzászólásomban ugye azt említettem hogy az inteles mikro-opok jóval egyszerűbb szerkezetűek lehetnek mint az AMD-s makro-opok, így egyszerűbb felügyelő/vezérlő logikát igényelnek. Azonban már kezdek ebben kételkedni. Az intel a ''mikro-op fusion'' kiaknázását tanácsolja az Optimization Manualban, illetve szép számmal akadnak single mikro-op utasítások is. Ezek szerint mégis egy rakás függőségi információt kell tartalmaznak a mikro-opok, tehát mégsem egyszerűek.
  
  Az utóbbi pár napban a Core2 ROB-jával játszadozom az Intel vTune segítségével. Az már látszik hogy a ROB-ot nagyon nehéz teletömni ( ROB.FULL esemény ) egy valamire való, többé-kevésbé optimalizált kóddal. Egyelőre kérdés hogy azért mert a sok renaming miatt nehézen tudja csak tölteni a dekóderekból vagy azért mert az execution unitok elég gyorsak.
  
  Megjegyzés: Egy SSE/SS2 FP számolásokkal teli, K8-ra optimalizált kód a Core2-re adaptálva ( csak az utasítás sorrend módosításával! ) közel 30%-ot gyorsult az eredeti változathoz képest. Az adaptált kód K8-on viszont csak alig lassult pár százalékot. Ez azt jelzi hogy az K8 ICU-ja meglehetősen jó munkát végez. Kár hogy futási sebességben a Core2-es optimált kód mintegy 87%-kal gyorsabban futott le mint K8-on az arra optimalizált, azonos órajelen. ( Az eredeti kód is gyorsabb volt Core2-őn (128 bit SSE engine ). )

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