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

• #5589 HSM félisten joysefke #5587

  Új Válasz 2017-04-28 16:20:03 #5589

  Ú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

  

  HSM

  félisten

  válasz joysefke #5587 üzenetére

  Ha már ilyen gyönyörűen levezetted ezt a témát, engedd meg, hogy gyorsan tegyek egy kis kiegészítést, hol jön be az SMT/ HT előnye/hátránya a képbe.
  Szóval az előny ott jön be, hogy azáltal, hogy egyszerre két programszál elérhető az egyetlen fizikai processzormag számára, így a végrehajtás sajátosságai alapján válogathat össze magának egy ideális végrehajtási tervet. Pl. ha az adott ciklusban az egyik szál egész számokon dolgozik, és marad szabad lebegőpontos egység, és a másik szálban épp egy lebegőpontos művelet várakozik, akkor egyszerre tud haladni a program a két szállal. Ugyanez, ha az egyik szál éppen a memóriára várakozik, addig a másik teljes gőzzel dolgozhat. Ennél persze többről van szó, de első nekifutásra ez elég szemléletes. Ezzel lehet nyerni alkalmazástól függően ideális esetben 20-30%-ot magonként.

  Ugyanakkor a hátrány, ami miatt lassulhatnak a kevés szálon dolgozó alkalmazások, vagy laggolások léphetnek fel, az a következő. Ahogy írtad, az iőosztásos ütemező képes kezelni a prioritásokat. Ez SMT nélkül remekül működik. Ugyanakkor SMT-vel a hardver válogat a szálak között, tehát a programozó hiába teszi kritikussá (magas prioritásúvá) a program sebessége szempontjából legfontosabb szálat, nem biztos, hogy ezt meg fogja kapni. Ugyanis az adott szálon ténylegesen ő fog kapni minden erőforrást, azonban az ütemező a másik szálon feladatokat ütemezhet mellé, és onnantól a processzor azt is ütemezni fogja, prioritástól függetlenül, erőforrást és sebességet elvonva a kritikus száltól.
  Pl. van egy egymagos rendszer, amin egyszerre elindítasz egy számításigényes videolejátszást, és egy tömörítést. Berakod a videólejátszást magas prioritásra, hiszen az nem von el annyira sok erőforrást, de fontos, hogy azonnal rendelkezésre álljon neki a processzor, amikor szükség van rá, a tömörítés meg elkészül, amikor elkészül, nem lényeges. Ez így remekül működni fog. Ugyanakkor, ha ez az egy magunk SMT/HT-s, akkor gondok lesznek. Ugyanis az egyik szálon fog magas prioritással dolgozni a videolejátszó, de az ütemező azt fogja látni, húdejó, itt egy üres szál, és oda fog kerülni kis prioritással a tömörítő. Viszont az a meglepő dolog fog történni, hogy így a videó akadozni fog. Ugyanis a hardver számára a két szál egyenlő, számára nincsenek prioritások, csak elvégzendő feladatok, és eszerint egyformán fog erőforrást biztosítani mindkét folyamatnak, felborítva az egyensúlyt, amit egyébként beállítottunk prioritást. Emiatt külön optimalizálást igényelnek az ilyen processzorok programozói oldalról az ideális működéshez.

  "Hogy miért szereti a Windows processzormagról processzormagra átdobálni a futó szálat akkor is, amikor igazából nem kéne, azt nem értem. hogy utána miért kell a Task Managerben CPU-magokra lebontott kihasználtságot mutatni, azt sem értem. Mert nagyon zavaró és megtévesztő az biztos..."
  Indokolt a léptetés, hardveres okokból. Mégpedig, hogy ne féloldalasan melegedjen a processzor. Ha el van osztva a használat, akkor egyenletesen fog melegedni, így az élettartama is lényegesen jobb lesz. Az, hogy utána a diagrammot úgy látod ahogy már a működés következménye, a diagram ugyanis azt mutatja, mennyire volt használatban az adott mag, és tényleg azt látod, ami történik. Csak nem árt tudni a működést, hogy értsd is, mit látsz.

  Általában amúgy a kiosztás az szokott lenni, hogy az egymás utáni két szál szokott egy maghoz tartozni. Régen néhány Intel BIOS-ban volt bug, amikor ez nem így volt, újabb gondokat okozva néhány alkalmazásnak.
  Ezt a mérést is azért tudtam ilyen egyszerűen megcsinálni [link], mert ismert számomra, hogy szépen kettesével vannak a maghoz tartozó szálak, így könnyű volt kapcsolgatni, mennyit használhasson a játék.

  Szval igen, így érdemes kiosztani, hogy egy CCX-en belül minden második szálhoz. De a melléütemezések elkerülés meleltt mégiscsak az SMT letiltása a biztos megoldás.

  (#5588) pipo112: A GPU-használatot jól méri a HWiNFO, a max thread usage viszont nem mér jól, csak a max core usage-t mutatja, ugyanaz a megbízhatatlan ütemező által megkevert cucc, ami a sima feladatkezelőnek is baja. Annak a mezőnek kb. semmi értelme.

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