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

• #46 Robitrix senior tag dokanin #40

  Új Válasz 2021-03-08 13:36:00 #46

  Ú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

  

  Robitrix

  senior tag

  válasz dokanin #40 üzenetére

  azért ha megszaporodnak a hibrid magok, akkor az meg fog jelenni a fordító programokban is. Utána csak annyi a dolga a fejlesztőnek, hogy mikor fordítja az alkalmazást bekapcsolja az optimalizálást a hibrid felépítésre. Bár ennek valami olyasmi előfeltételét látom, hogy magának a programozónak kéne valamilyen módon minősíteni adott program szálat, hogy milyen erőforrás igényű az adott program ág. Például valamilyen bejegyzéssel a programág elején az adatoknál. Például egy direktívával, ami megmondaná, hogy adott programszál az alacsony, közepes vagy magas erőforrás igényes. Ami valahogy belefordulna a gépi kódba, amit aztán a rendszer erőforrás ütemezője tudna kezelni és akkor igyekezne a nagy számítás igényű program szálat a gyors magokra rakni a kisebb prioritásúakat meg a normál magokon használni. Elvégre legoptimálisabban mégis csak a program fejlesztője tudja megbecsülni, hogy a programja melyik része mennyi teljesítményt igényel. persze tehetné azt is, hogy minden programágat magas prioritással lát el, de akkor lehet magával baxna ki, mert lehet, hogy a kis teljesítményt igénylő programágat akarná ráerőltetni a gyors magra a rendszer és a nagy teljesítményűt a gyengébb magra. A másik megoldás meg az volna, hogy a rendszer figyelné a futás elindulása után, hogy melyik programág mennyi időt használ futásra, amiről készitene egy statisztikát, ahol minősíti maga a program ágak erőforrás igényét. majd egy idő után ez alapján probálná meg összehozni a magok teljesítményét a programszálak igényével. A dolog hátránya, hogy kell némi idő mire előáll futásközben egy használható teljesítmény statisztika és nem biztos, hogy minden programszálra egyből sor kerül és annak minden teljesítmény igénylő része neki áll futni. Simán lehet olyan programot irni, ami elindit egy feladatra valami program szálat majd valami feltétel teljesülése esetén máshogyan számol más részét használva a programágnak egy másik feltétel esetén meg megint mást csinál. Mondjuk kétféle adat beérkezése esetén eltérő dolgot kell vele elvégezni. Az egyikhez sokat kell számolni a másikhoz kevesebbet. Így nem biztos, a rendszer által készitett statisztika pontos lesz. Jobb megoldás ha a program készítő maga határozza meg melyik program ág fog sokat számolni és melyik keveset...... Ki a fene tudná nála jobban, mint aki irta a programot?

• #119 sb veterán dokanin #40

  Új Válasz 2021-03-10 16:01:05 #119

  Ú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

  

  sb

  veterán

  válasz dokanin #40 üzenetére

  Szerintem sok mindent fordítva látsz ami a mostani nézőpontból érthető de épp ezek változnak. Lásd M1 és úgy általában a mobil/ultramobil világ előretörése.

  1. Írod, hogy csak extra teljesítményre optimalizálnak, de fordítsuk meg a dolgot: magkapod a kis/gyenge magokat. Az Intel specekből nem látjuk de az érezhető, hogy jelentős erőt fognak lekötni a kisebb magok is. Nyilván nem maradhat az Intel 4-6 erős magon. Az édeskevés a mostani 8-12 erős AMD mag ellen. Szóval ez előre menekülés ilyen szempontból is.
  Ha pedig otthagysz 6-8 kis magot kihasználatlanul mert csak a 4 nagyon fut a progid akkor máris a plusz (30-50%?) teljesítményért kezdhetsz el optimalizálni.

  2. Ami szerintem szintén téves, hogy csak teljesítményorientált programok vannak. 10-ből 8 esetben egy rakás app/service fut a háttérben csak, hogy "legyen". Rohadtul nem teljesítményorientáltak, főleg nincsenek rákényszerítve, hogy minden clusteren egyszerre fussanak. Ezeket csak ide-oda pakolni, esetleg fixálni kell és máris nyertek vele, pl. üzemidőt/fogyasztást. Ezeket akár user is állítgathatja... de nem fogja, viszont automatikusan is elég jól be lehet lőni.

  3. Hogy ez mennyire számít üzemidőben/fogyasztásban. Ebben igazad van, hogy relatív és inkább hasznosságfüggő. Hiába fogyaszt/tart vmi a matek szerint sokkal jobban ha nincs rá szükség. Lásd: kibírja 1 napot a noti, csak telefonnál érdekes, stb...
  Ha megüti azt a szintet ami elvárt akkor nyilván ebbe senki nem fog extra költséget beletolni.
  De szvsz nem itt tartunk. Épp most léptünk notiknál is át ebbe a szegmensbe, hogy desktopot váltanak ki, az ultramobil is folyamatosan erősödik de nyilván mindkettőben lehet szintet lépni, ahogy most is történt. Ha 3-5 naponta kéne tölteni, még erősebb lenne (mert energiahatékonyabb), esetleg 2 év múlva arról beszélünk, hogy nem a notik érték el a desktop szintet hanem a telefonok... ehhez szükség van ilyen szempontból is előrelépésre.

  A Zen szokott példa lenni, hogy megmaradt a magas egyszálas teljesítmény, mellé ott a sok mag és az üresjárati (vagy inkább light load és ez szerintem fontos) fogyasztás is oké.
  De ez sem magától jött. A chipletes, IF-es dizájn pl minden csak nem energiahatékony idle közelben. Mindennek mennie kell, nem véletlen, hogy a mobil procik monolit felépítésűek és ebben is folyamatosan lépkedünk előre. Pl. a Renoir nem tud feszskálázást sem magonként.
  Pl. nálam Zen+-tól (2700) "idle" 70W-tól most 42-ig ment le Reonirral. Dvga nélkül már 28W.
  HDD-t, ventiket kirakva, újabb chipsettel már valahol 15W körül lenne. De ez hw oldali főleg, ami érdekes benne, hogy mi az "idle":

  4. És ez lenne a lényeg amiért szvsz sw oldali optimalizálásra biztosan szükség van.
  A 70W elég soknak tűnt, sikerült kisakkozni, hogy 2db tálcán futó "semmittevő" progi a bűnös. Nélkül 50W alá megy a fogyasztás. Taskmgr-ben azt látod, hogy a proci 0.5-1% között ugrál, mégis ha kilövöd őket akkor -20-25W.
  Közben persze másik 10-15 tálcás progi (meg pár 100 háttérfolyamat) ugyanúgy fut.
  - Ez hw-ből megoldhatatlan.
  - Sw oldalon igazán az adott sw-ben kéne erre gyúrni, hiszen gyakorlatilag ezek "szarul" voltak megírva. Ez szerintem már véleményes, hogy hány usernek tűnik fel és fog-e a fejlesztő "optimalizálni" 0 teljesítményelőnyre is. Szvsz fog, ez olyan szint ami áltagusernél is feltűnik az üzemidőben. Plusz magad írtad, hogy telefonoknál ez működik... de miért? Azért mert ott ez is - erős - része volt a hasznossági faktornak. Ha itt is előjön és kritikus akkor foglalkozni fognak vele.
  - És megoldás lehet még a külső ütemező ami a kettő között van. Nyilván csodát nem tud tenni de ilyenkor egy kisebb prioritás, kisebb magra való átrakás azért bőven segíthet.
  Ezt viszont elég körültekintően kell megoldani ill. minél inkább az adott sw felé elvinni a megoldást, mert hátránya is lehet. Épp ez az ami miatt a hw közeli megoldások nem jó hatékonyságúak.
  Írtad, hogy ennek desktopon nincs jelentősége. Szvsz ilyen szinten ott is van, ill. ha ezek nem működnek megfelelő hatékonysággal akkor annak ilyen kézzelfogható eredményei vannak.
  Sokáig ment a Ryzen energiasémák körüli vita is. A fenti problémára pl. egy konzervatívabb séma (fél)megoldást ad. Cserébe viszont brutálisan lelassítja a rendszert reszponzivitásra. Erre születtek anno a kimaxolt sémák: cpu min freki az egekben, core parking letiltva, IF/memória nem vesz vissza, PCIe L1.1-1.2 letiltva, stb...
  Ezek off-ra rakva valóban 0 (ami nincs) terhelésnél lehet, hogy nem sokat zavarnak, de valósan, minimál terhelések esetén rendesen rátesznek a fogyasztásra.
  Alapból nem csoda, hogy engedélyezve vannak, úgy viszont közel sincs meg az a teljesítmény amit megszoktunk és szerinted is musthave. Power saver sémában egy sz*ros TotalCMD 2mp-ig nyílik meg NVMe-ről 6/12-es gépen. A böngészőindítás hasonló, szintetikus 4k IOPS-okat sem érdemes méregetni, stb...

  Ebből elég jól látható, hogy ezt sw oldali támogatás nélkül nem lehet megoldani.
  És akkor még nem tartunk ott, hogy hiába desktop. A tömegigény az, hogy ez (minden) mobilon és ultramobilon fusson.

  Szóval összegezhető az egész úgy, hogy most is látszik, hogy
  1. Nem elég a meglévő mindentudó hw (erős, takarékos és gyorsan frekit/feszt/állapotot váltó) cpu. Ott sem ahol nem lenne jelentősége, mert ott sem tud mindent ami papíron menne neki (max erő vs energiahatékonyság, ill. van a kettő között is élet: sőt, 99%-a ott van, nem a max perf esetekben).
  2. Ahol jelentősége van (mobil) ott pedig el is vérzik még sok esetben.
  3. Az sw támogatást emiatt úgysem ússzuk meg, most sem váltja ki a hw oldali.
  4. Ezt pedig hw oldalról olyan extrával megtámogatni, mint hibrid felépítés akkor már adja magát. (ahogy az eddigiek is hasonlóan adták: több mag, alacsonyabb freki: ez ugyanaz pepitában bár nyilván sokkal egyszerűbb sw oldalról...)

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