Keresés

Hirdetés

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

  • tibaimp

    nagyúr

    válasz b. #23 üzenetére

    Érdekes! Remélem beválik ez az új rendszer. A telefonok esetében nagyon bejött, kíváncsi leszek.

    A tehén egy bonyolult állat, de ÉN megfejtem...| 2016-tól az tuti, hogy az angyalok is esznek babot...

  • Abu85

    HÁZIGAZDA

    válasz b. #23 üzenetére

    Csak akkor megy az optimális szálra, ha a programot úgy írják meg, hogy jelezze, hogy melyik magon kell mit futtatni. A hardveres ütemező arra van, hogy mérje az egyes folyamatok terhelését és az OS-nek jelzi, hogy mit kellene melyik szálra átrakni, de az OS-nek ezt nem kötelező megtennie.

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • Abu85

    HÁZIGAZDA

    válasz b. #26 üzenetére

    Mert az OS-nek nagyobb rálátása van erre. A hardver a lapkában csak annyit jelez, hogy x folyamat a neki rossz típusú magon fut. De ez csak egy jelzés, és az OS láthatja esetleg azt is, hogy ha átrakja egy másik magra, akkor az ugyan az adott folyamatot jól működővé teszi, de más folyamatokat meg háttérbe rak. Emiatt mondja meg az OS, hogy mi lesz. Ez alól egyedül akkor van kivétel, ha az alkalmazásba direkt le van kódolva a kis-nagy mag. Ebben az esetben biztosan a lekódolt paraméterekkel futnak majd a folyamatok. De ehhez a szoftvert így kell megírni. Erre lesz az Intelnek egy profilozója, amivel a fejlesztők dolgozhatnak. Az ARM-nak is van egy profilozója a saját kis-nagy magjára, csak a fejlesztők elképesztően nehéznek tartják a heterogén programozást, így inkább arra használják ezt a lehetőséget, hogy egy alkalmazást csak a kis, vagy csak a nagy magokon futtatnak.

    A Win 11 ütemezője az nagyrészt a Qualcomm kódját tartalmazza, hiszen nekik sokkal több tapasztalatuk van arról, hogy mit lehet kis-nagy magos dizájnokkal.

    A béta alatt is voltak lassulások az AMD-vel, csak időközben megoldották, majd a véglegesre visszatért. Ez amúgy teljesen független az üzemezéstől. A problémát az adja, hogy az L3 gyorsítótár elérési ideje a sokszorosára nőtt. Erre ugyanazt a kódot hozzák majd, ami a béta verzióban benne volt a Win 11-ben, csak a véglegesbe a Microsoft nem tette bele. Ezért írták, hogy októberben kész lesz, mert már kész a fix, csak be kell építeni.

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • sb

    veterán

    válasz b. #26 üzenetére

    Ez az egész egy black box/reverse engineering az alacsonyabb szintekről ha úgy tetszik. Se az OS, pláne nem a hw fogja tudni, hogy épp mi az optimális annak amit futtatsz. Maga a kód kell, hogy "tudja" első körben. Több folyamat, erőforrásigények, folyamatszinkronizációk igénye, stb... Amíg egy sw nincs eszerint megírva addig szuboptimális a működése szinte biztosan.

    Ettől függően még lehet (lesz) OS szintű vagy OS-el együttműködő sw szintű pakolgatás meg méregetés ami szinte biztosan elég jó megoldást ad az esetek nagy részére, de igazán optimális akkor lenne ha minden program így készülne és nem másnak kellene alacsonyabb szinten kitalálnia mi lenne neki az optimális erőforráskiszotás.

    (Sőt, továbbmegyek, még program szintjén sem feltétlen fix... Mi van ha elindítok egy böngészőt és k*va gyorsan oda akarok jutni, hogy megnyíljon az 5 kezdőlapom? És mi van akkor ha megnyitom, majd a háttérbe kerül mert addig pl. ránézek a levelezésre amíg megnyílik az 5 lap? Előbbi esetben mindenféle big-little nélkül is a turbo a megoldás. A második esetben meg a visszafogott órajelek. Ez az ütemezési - hw/os/app kérdéskör már rég aktuális csak nem nagyon foglalkozunk vele. Max akinek eddig is az akkuidejére ment ki a játék.)

    [ Szerkesztve ]

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