Új hozzászólás Aktív témák
-
Robitrix
senior tag
pedig egyértelműen szükség van egy hibrid proci esetében a programfejlesztők együttműködésére a hatékonyság jegyében. Elvégre ki más tudná megbecsülni egy program kódban futó procedúrák és szálak teljesítmény igényét, mint az, aki írja a programot. Egy programozónak azért illik elképzelésének lenni, hogy a programjának melyik része mennyi CPU-t igényel. A legtöbb programban párhuzamosan futó szálak erősen eltérő teljesítmény igénnyel rendelkeznek. Lesz olyan program ág, ami szinte végig fut mivel ő a fő vezérlő ág, amiből aztán alkalom és esemény vezérelten indulnak más párhuzamos programágak. lehet egyik szálnak 5 trillió számítást kell elvégezni. a másik program ág elindul 5-ször és végre fog hajtani alkalmanként mondjuk 100 ezer utasítást. A józan logika azt diktálja, hogy ha lehet az 5 trillió számítást végző programág a lehetőségek szerint találkozzon össze a leghatékonyabb maggal. mig az 5-ször 100 ezer utasitást elvégző program ág nos ráér a lassabb magon futni. Persze azért itt hatalmas együttmüködésre nem kell számítani. Elég volna annyi hogy mondjuk a programozó egyfajta fordítási direktivával minősítené a programjának a szálait. Lenne egy alacsony egy átlagos és egy magas jelzés. Aztán ez valahogy érvényesülne a gépi kodban és ez alapján tudná a rendszer, hogy egy futtatndó process akkor most kicsi, átlago vagy nagy teljesítmény igényű. Aztán ennek függvényében igyekezne neki megfelelő magon futást biztosítani. A kérdés, hogy mi motiválná az együttműködésre a programozót és ne állítsa be a programjának össze ágára a magas minősítést. Hát alapvetően a saját jól felfogott érdeke. Egy program egyáltalán nem biztos, hogy adott pillanatban egyedül fog futni egy CPU-n. Lesznek mellette más konkurens folyamatok, amíg szintén versengenek a egy adott procimag 1-1 időszeletéért. Minnél több idő szeletet kap egy programág annál többet futhat a procin. Ha sok process vár egy mag időszeletére, akkor kevés időszeletet fog kapni a gyors magon az adott nagy teljesítményű folyamat. Így lassan fog futni. Hiszen egy procimag időszeleteinek száma korlátozott nem lehet korlátlanul osztogatni. Annyit lehet szétosztani, amennyi van. Vagyis előállhat a sok az eszkimó, de kevés a fóka helyzet. Ha lesznek eszkimók, akik beérik fóka helyett hallal is(lassabb proci mag) akkor csökken a tolakodás a fókák(gyors magok) iránt és 1-1 eszkimónak több szelet fókahús jut. Kérdés persze, hogy mennyire engedem a rendszernek, hogy ha nem jut a fókára éhes eszkimóknak elég fóka szelet akkor mennyire engedem meg, hogy párat átirányítok mégis halat enni hiába van fókára bejelentett igénye. Kérdés mikor járok el optimálisabban ha várok a kevés leeső fóka darabra vagy közben nasizom a halból is mikor nem jut fóka.
Ezért minden képen hatékonyabb ha maga a programozó minösíto a saját programjának a szálait, hiszen ha ő nem akkor kitudja minek mennyit kell adni. A másik lehetőség egyfajta statisztika készítés a futó proceseknek, melyik hányszor és hány időszeletben fut és mennyi az átlagos órajel és egyebek, majd ennek a statisztikai minősítés alapján tudja a rendszer, hogy milyen procest hová kell rakni futni. A hajtsuk kia a belünket magra vagy az ejjjjj ráérünk arra még magra. A dolog hátránya, hogy kell némi futás ahhoz, hogy valamiféle statisztika kialakuljon. A másik, hogy minden statisztikai adat már egy megtört esemény alapján készül. Vagyis a múlt adataiból táplálkozik. Attól, hogy egy process mondjuk az elmúlt 3 másodperceben gyakran és sokat futott egy CPU magon egyáltalán nem következik, hogy a következő 1 percben is sokat fog futni. Sok programnál egy programág futást valami véletlen esemény vagy egy konkrét esemény bekövetkezése váltja ki. Például egy játékprogram esetében Elöre teljesen eldönthetetlen, hogy mondjuk egy játékos mit fog cselekedni. tűzet nyit egy megjelenő ellenségre vagy fogja magát és nyúl cipöt köt és menekül. A játékos cselekdete más jövendő beli kódot fog aktiválni a jövőben. Persze egy játék program tele van véletlen eseményekkel. Mondjuk rálő az egyik tank a másikra a WOT-ban. A lövésnek van egy véletlen(RNG összetevője is) ami alapján lehet, hogy átüti a lövedék az ellenséges tank páncélját vagy lepattan róla, mint a bumeráng. Néha a papir tankot se üti be a lövés egy akkora ágyúból, mint egy hegy máskor meg a papírtank ágyúja mégis csak betalál a hegynyi monstrumba és telibe nyomja a lőszerrekeszt... Már pedig találatot kapni a lőszerrekszbe minden tankos szituba rossz ómennek számít. Vagyis operációs rendszer szinten a múlt adatai alapján elég bizonytalan felvázolni a lehetséges jövöt egy program folymatainak igénye szempontjából. Így mégis csak a programozó becslése lehet a legtöbb haszonnal kecsegtető a kiindulási adat. ki tudja, ha nem ő. Amúgy ma is bele lehet avatkozni prioritás szintján a programok futásának. ehhez csak annyi kell, hogy egy futó processnek egyszerüen magasabb prioritást adjak a feladatkezelőben.[ Szerkesztve ]
Ezért minden képen hatékonyabb ha maga a programozó minösíto a saját programjának a szálait, hiszen ha ő nem akkor kitudja minek mennyit kell adni. A másik lehetőség egyfajta statisztika készítés a futó proceseknek, melyik hányszor és hány időszeletben fut és mennyi az átlagos órajel és egyebek, majd ennek a statisztikai minősítés alapján tudja a rendszer, hogy milyen procest hová kell rakni futni. A hajtsuk kia a belünket magra vagy az ejjjjj ráérünk arra még magra. Új hozzászólás Aktív témák
ph A legnagyobb teljesítmény eléréséhez Windows 11 kell, de a Windows 10 sem jelent leküzdhetetlen akadályt.
