2. Fórumok
  3. Processzorok, tuning
  4. AMD-s mélyvíz: Raphael, Rembrandt, Zen4
Keresés

Hirdetés

  • Téma összefoglaló
    Utoljára frissítve: 2023-12-13 04:53

    Mobilarena

    OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!

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

  • #932 #95904256 törölt tag P.H. #930
    Új Válasz #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
    Privát üzenet küldése

    #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 ). )

  • #934 dezz nagyúr P.H. #930
    Új Válasz #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)

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