Új hozzászólás Aktív témák
-
Tentalus
tag
Pont ezen gondolkodtam, hogy mennyivel nehezebb különböző teljesítményű szálakat összehangolni...
Ez is jó : a 15W kategóriában -ez a legelterjedtebb - az I7 változat 2C+8c kiépítésű, azaz igazából 2magos. Már azt hittem,végleg megszabadultunk a 2magos I7-től ,erre most visszaszivárog. -
Robitrix
senior tag
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?
-
-
Robitrix
senior tag
hát pont ezt csinálják a program magokat és szálakat legjobban kihasználó mivel ugyan azt a programot futtatják gyakorlatilag minden lehetséges program magon és szálon csak persze eltérő adatokat feldolgozva. ilyenek, a tömöntések, videó feldolgozások. rendérélésék, titkosítások stb. Más felől viszont az átlagos program nem ennyire szétosztható teljesítmény igény alapján. Lesz olyan program ág ami annyit fut, hogy megszakad és lesz olyan ami csak néha ugrik be egy kicsit edzeni a CPU-n.
Főleg egy olyan alkalmazásban, mint például egy játék program. Hiszen annak eldöntése, hogy adott pillanatban mi futhat mi mellet és melyik programágnak kell várni egy másik eredményére meglehetősen kaotikus és véletlen szerű mert esemény vezérelt.
Hibá irok egy játékot arra, hogy mikor tűzet nyit a játékos akkor elindul egy külön programszál arra, hogy kiszámolja a leadott lővés eredményét. Hasba lövöm túl éli az ellenség, vagy surolja a lövés vagy miszlikre robban a feje, mert fejbe találom stb. Semmit nem ér a külön kiszámolás program ág, ha nem nyit tűzet az játékos a célra. Nyilván nem állhatok neki kiszámolni egy le se adott lövés következményét, mert foglamam sincsen hová fog pontosan lőnni a játékos. ezért is nem lehet egy játék program tökéletesen optimalizálva a magokra és szálakra. Hiszen nehezen tervezhető a pontos futás és az események előre. Ezért is ingadozik azért erősen a játék közben használt magok és szálak száma illetve a szüksége idő a futáshoz. Egy játék program nehezen optimalizálható és előre jósolható. -
Alpi.
addikt
A programozónak nem kell ezzel törődnie. Viszont hatékonyságban óriási a különbség, attól függően, milyen felépítésű processzoron futnak a dolgok. Ez az, ami a sok magos cpuk egyik nagy előnye többek közt, ugyanis sokkal hatékonyabb ha sok, kicsi (kis órajelű) magon futtatsz dolgokat, mintha kevesebb "nagyon". Ha meg szükség van a maximális számítási kapacitásra, akkor ott vannak a "nagy" magok. Olyankor a hatékonyság másodrendű.
Pont ebből a szempontból volt olyan előremutató a Zen2-vel bevezetett cpu felépítés, működés. (más kérdés, hogy nem sokan értették, hogy miért csak 3.9-en megy a 16 magosukon a Cinebench, stb., stb. Nem kívánok belemenni, mert végtelen és értelmetlen vitaindító. Abunak (azt hiszem) volt anno erről egy írása, ahol nagyon jól leírta, körbejárta ezt.
" Tehát ha megcsinálom sem fogják azt mondani, hogy marha jó ez a program mert ezzel plusz 2 órát bír a gépem. Tehát nem nyerek semmit."
Ebben valahol igazad van, de itt más is van a képben. Mégpedig az, hogy ez a jövő ! Nincs más út ! Lehet ragaszkodni a kevesebb, erős magokhoz és eltűnni a süllyesztőbe vagy el kell mozdulni a sok magos, hatékony működés irányába. A számítási kapacitásra való igény nőni fog, ez nem nagy titok és ezt bizonyos szint után csak így lehet kiszolgálni.[ Szerkesztve ]
https://www.youtube.com/channel/UCbJjHfBdTsUw3UJAFr-5Gsg
-
Alpi.
addikt
Desktop-ba is jelen van (jelen lesz, egyre inkább) a hatékonyság csak picit másképp. Itt nem a fogyasztás miatt elsődlegesen hanem egyszerűen azért, hogy sok magos cpuk lehessenek. Képtelenség 12 - 16 (ki tudja még mennyi lesz) magos procikat olyan magokkal, olyan órajeleken üzemeltetni, ahol 4-6 magosok mennek. Jó lenne, ha lehetne, de sajnos nem lehet.
Itt is "ég a ház" Intelnél, hiszen Amd már most nagyon komoly előnyben van ezen a téren és menni fognak tovább is ha kell, mert az Ő megoldásuk, típusuk egész jól formálható, ráadásul az inf. fabric miatt még olcsón is gyártható. Az egy dolog, hogy most hol tart a 2 gyártó és a piac, de ha a jövőbe tekintünk, nagyon nem lehetnek nyugodtak ![ Szerkesztve ]
https://www.youtube.com/channel/UCbJjHfBdTsUw3UJAFr-5Gsg
-
sb
veterán
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...) -
arn
félisten
szvsz ezt meg lehet oldani, csak akkor a 8+4 magos mag tenylegesen tobbnyire negy magoskent viselkedik, kiveve, amikor az osszes magot eleresztik.
facebook.com/mylittleretrocomputerworld | youtube.com/mylittleretrocomputerworld | instagram.com/mylittleretrocomputerworld
-
Alpi.
addikt
A szoftver írója arról sem rendelkezik, hogy melyik magon, stb. fusson az aktuális rendszeren. (mármint a konkrét címzésről) Nem Ő dönti el, hogy a szabad magok / szálak melyikén fut, mert nem is tudná, hiszen ehhez tudnia kéne az aktuális felhasználásnál a mellette futó, egyéb programokat is. Ezért van az ütemező többek közt, ami viszont megmondja, hogy Te fiam ide ménsz, Te meg oda.
[ Szerkesztve ]
https://www.youtube.com/channel/UCbJjHfBdTsUw3UJAFr-5Gsg
-
ddekany
veterán
Valószínűtlen, hogy alkalmazás fejlesztőktöl bármit várnának, talán eltekintve nagyon széles körben használtakétól (mint böngésző). 8 big + 8 little az 16 mag és kész. A többi az OS ütemező dolga.
Annyit tudok elképzelni, hogy ha akarod (és amit használsz támogatja), akkor megjelölhetsz egy szálat, hint jelleggel, hogy nem kell vele sietni. (Szál prioritás mondjuk mindíg is volt Win32-ben és Java-ban is, de talán erre valai új flaget kéne használni inkább.)
Ill. azért van az a gond, hogy néhol azt csináljuk (vagy hát a framework azt csinálja), hogy annyi egyenlő részre vágjuk a feladatot, ahány mag van. De mivel a fele little magra esik, nem ideális, hogy egyformákra lettek vágva. Bár ami azt illeti, eleve erős tipp csak, hogy egyszerre lesznek kész, és ezért inkább több kisebbre vágunk, és akkor amelyik szál már unatkozik, az kapja a következő darabot...
Új hozzászólás Aktív témák
ph A cég javarészt kisebb teljesítményű magokkal tömi ki az alacsonyabb fogyasztású termékskálát.
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest