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

• #537 Simid senior tag Petykemano #535

  Új Válasz 2018-11-09 12:41:44 #537

  Ú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

  

  Simid

  senior tag

  válasz Petykemano #535 üzenetére

  "zennél 2x8MB L3$ van
  Egyik CCX-től a másikig elég magas a késleltetés"

  Igen, ismerem ezt a grafikont. Pont ez az a rész amit nem értek. Ugye van egy 8MB-os rész ami gyorsan elérhető az adott CCX számára. Aztán van egy kevésbé gyorsan elérhető 8MB L3 (kvázi L4). És TR vagy EPYC esetében további 16/48MB L3 (kvázi L5) ami még ennél is lassabban elérhető.
  Az Intel esetében az eDRAM a die-on volt, így gyorsan elérhető volt. Ilyen a Rome esetében úgy néz ki nem lesz.

  Továbbra sem kétlem, hogy egy L4 cache nagyon hasznos lehet szerver környezetben, főleg így, hogy a RAM elérés már minden esetben IF-el összekötött I/O die-on történik. De ez semmit nem fog javítani azon a problémán amit ez a lépcsős grafikon mutat nekünk. Egyszerűen megnövelik annak a cachenek a méretét ami lassan (de a rendszer memóriánál még mindig sokkal gyorsabban) elérhető.

  Hogy röviden összefoglaljam, a közeli és gyorsan elérhető L3 hiányát nem lehet pótolni egy távoli és lassan elérhető L4-gyel. Gondolom ezért döntöttek a megnövelt L3 mellett.

  "Azért gondoljuk, hogy a CCX-ek közötti elérésben, adattranszferben valahol a memória közrejátszhat, beépülhet, mert az inter-CCX latency általában a mérésekben magasabb, mint a memory latency."

  Ez is megvan, de én úgy értelmeztem az előadásból, hogy ez nem fog változni a IF 2.0 esetében sem, csak szélesebb a link. Laikusként nézegetve az IF működését pl ezen leírás alapján nekem az jött le, hogy az SDF bár a mem órajelen üzemel a szinkronizáció miatt, de máskülönben független tőle. Ha ez nem így van és ténylegesen a rendszer memórián keresztül történik a kommunikáció, akkor máris értelmet nyer egy esetleges L4 cache.

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