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

• #28 DraXoN addikt paprobert #22

  Új Válasz 2019-08-29 22:12:16 #28

  Ú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

  

  DraXoN

  addikt

  LOGOUT blog

  válasz paprobert #22 üzenetére

  a felépítés mögött az elmélet egy része az volt, hogy egy-egy művelet végrehajtása esetenként több órajelet is igénybe vesz, így a sok tranzisztort igénylő lebegőpontos részek a 2 cpu közötti megoszlása, elméletben nem okoz semmiféle teljesítmény vesztést, főleg, hogy egyes régebbi 64bites kódok esetén "dedikálni" lehetett csak a fél egységet fixen a cpuhoz, így akkor 2 teljes mag volt egy modul (csak kicsit csonka FPU egységekkel).. tökéletesen működő programfolyamat elosztással valóban kb. meg se lehetett volna érezni ezt a felépítést, de sajnos az architektúra más részei is "tranzisztor spórolás" áldozatai lettek (az architektúra felépítése miatt kellett a nagy cache, ami más egységektől vette el a területet), így "buta" lett az elágazásbecslő, ami "végzetes" lett a végső eredmény szempontjából (túl sokszor "összeakadtak" a folyamatok, erősen rontva a hatásfokot)..

  végeredményben a hatásfok ugyan jobb volt mint az aktuális SMT/HT implementációk, de visszatekintve, nem igazán "érte meg" az egyedi út, a programokat is erősen rá kellett volna optimalizálni, de a sors is sújtotta az architektúrát a gyenge gyártási minőség miatt (a tervezetthez képest "alacsony órajelek", magas szivárgás jellemezte az egész élettartam alatt az architektúrát)...

  lényegében "több volt" mint egy sima cpu mag ami 2 szálat kapott, képes volt "korlátozottan" 2 külön magként is működni (így nézve nem volt átverés), de ha teljes szélességű AVX kódokat (például) futtatott rajta az ember, akkor a magok belső késleltetése annyira megnőtt mint ha végső teljesítményben csak "fele" mag lenne (felváltva kapták meg a modulban a cpumagok az osztott erőforrást, nem mindig ideális időzítéssel).. lényében "túl merész" lett a felépítés, és a végterméknek sok gyenge pontja lett ami külön-külön is gyengített, de együtt eléggé rossz lett a felépítés hatékonysága.
  - Túl magas latency a cache felépítés miatt (egymásra épülő felépítés, először L1ben keres, ha ott nincs, L2, ha nincs L3, ha nincs központi memória)
  - "gyenge" elágazásbecslő, így sok volt az "újrakezdett" műveletsor (a magas lantency növelte ennek a hibának a súlyát, mert akár ilyenkor minden adat "beállhatott").
  - rossz gyártástechnológia (4Ghz körül lett volna a kezdőórajel, és 5-6 Ghz az általános működési tartomány)
  - erősebb szoftveres optimalizáció kellett volna a felépítéshez, de már windows szinten elbukott ez, később kapott egy "alap" optimalizálást, de kétlem, hogy valaha is teljesen normálisan megírták volna a windows szálkezelését rá (voltak/vannak ráutaló jelek, hogy nem tökéletes a dolog, már nem is lesz persze).
  látható, hogy a felépítés miatt igen sok cache kell a rendszernek, de még ezzel a rengeteggel a belsejében is "kevés" volt az összmennyiség, ráadásul az L3 cache órajele is csak töredéke volt a cpu órajelének (annak "húzásával" igen szép teljesítmény növekedés érhető el az architektúrában.. egyes esetekben persze)..

  [ Szerkesztve ]

  The human head cannot turn 360 degrees... || Ryzen 7 5700X; RX580 8G; 64GB; 2TB + 240GB + 2TB || Samsung Galaxy Z Flip 5

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