- Karácsonyfaként világíthat a Thermaltake új CPU-hűtője
- Az USA vizsgálja a RISC-V kínai terjedésének kockázatát
- Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kihívás a középkategóriában: teszten a Radeon RX 7600 XT
Hirdetés
-
Xbox Game Pass [2024] - A májusi lista
gp Az elkövetkező időszakban többek között megkapjuk a Kona II Brume című játékot.
-
Kicsit extrémre sikerült a Hyte belépője a készre szerelt vízhűtések világába
ph A cég megoldása centralizált vezérelhetőséggel, masszív radiátorral és robusztus ventilátorokkal igyekszik vásárlásra csábítani.
-
Új Beats fej- és fülhallgatók jelentek meg
ma Frissítette a Solo termékcsaládot az Apple házi audiomárkája.
Új hozzászólás Aktív témák
-
vicze
félisten
****meg, most komolyan a aSMP hiányát, több tonna clusterrel kompenzálják?
Istenem...
Akkora egy rakás *** ez a big.LITTLE, hogy leíratlan, támogat egyáltalán ilyen felállást? Vagy a két klaszter egybe lesz kötve és kapcsolat majd köztük?"A gond persze relatíve egyszerűen kezelhető."
A GTS eddig is hulladék volt, most adunk a szarnak még egy pofont.[ Szerkesztve ]
-
vicze
félisten
Mivel pontosan? (Persze mire tippelsz.)
Mert akkor egy CCN-5xx kell hozzá, hogy 2-nél több cluster kezelve legyen(olyan verébre aknavetővel módon). Az a baj, hogy MTK-ból egyéb galádságokat is kinézek.
@-Skylake-: Sajnálom, ez volt az első reakcióm.
(Annyira nem hülyeség szerintem. 
)
Viszont az elég jó kérdés, hogy mi lehet egyszerre.[ Szerkesztve ]
-
vicze
félisten
A magokat le lehet kapcsolni 1 klaszteren belül, az független, hogy hány lehet aktív. Az aktív magoknak nincs független feszültség vezérlése, így azonos órajelen kell járjanak. Két különböző klaszter között lehet eltérő az órajel ezt írta le Kopi31415, 1-1 klaszter külön szabályzást kap. Bekapcsoláskor lehetséges, hogy pár ms-re más az órajel és a program késeltetve mutatja, de alapból nem lehet más még egyszer 1 klaszteren belül.
Ez csak a nem Krait architektúrás SoC-ra igaz, amiben Krait van, ott független az órajel magonként.
Ha valakit érdekel leírhatom, hogy a big.LITTLE a fentiek miatt miért is problémás és miért lesz nagyon nehéz jó schedulert írni 3 klaszterre, mert hogy a GTS még 2-re is problémás.
-
vicze
félisten
válasz
-Skylake-
#36
üzenetére
Elnézést a terjedelemért.
Még így is biztosan sok mindent kihagytam, ami épp nem jutott asz eszembe, aki hiányosságot hibát lát, inkább javítson ki.
Van ez az alap felállás. Bal a Qualcomm jobb az ARM megoldás.
A kernel mindig a legkisebb energia állapotra törekedik. 1db CPU-nak van 1db órajele és 1db terheltsége. A CPU scheduler feladata, hogy a lehető legoptimálisabban elossza a terhelést a rendelkezésre álló CPU magok között úgy, hogy a fogyasztás a lehető legkisebb legyen.
Mi történik A esetben Qualcomm, ez aSMP(Asynchronous Multiprocessing) vagy DCVS(dynamic clock and voltage scaling):
Üresjárat 1 mag aktív és alacsony frekvencián megy. Jön egy általában 1magot igénylő folyamat ami megterheli a processzort, mondjuk 95%-ig.
Ez felviszi az órajelet max.-ra és a magas terhelés miatt a rendszer érzékeli, hogy szükség van még 1 magra, amit aktivál alacsony órajelen, mivel arra a magra már nem lesz terhelés.Mi történik B esetben ARM "stock":
Üresjárat 1 mag aktív és alacsony frekvencián megy. Jön egy általában 1magot igénylő folyamat ami megterheli a processzort, mondjuk 95%-ig.
Ez felviszi az órajelet max.-ra, a magas terhelés miatt a rendszer érzékeli, hogy szükség van még 1 magra, aktiválódik a mag max. órajelen. De mivel az órajel magas a második is így szépen aktiválódik a 3. és a 4. mag is szintén max. órajelen. Így 1db program teljesen felesleges terhelést és fogyasztást generál.
(Lehet, hogy az Apple ezért nem vált 2magról 4-re, mert nem tudják szabályozni megfelelően, 2mag még jól kezelhető.)ARM megoldása erre a problémára a big.LITTLE. A megoldás szót szívem szerint idézőjelbe raknám, mert nem valós megoldás.
Az belátható hogy ha nagy fogyasztású magok vannak a rendszerben akkor nem éppen előnyös a B viselkedés, mivel kis terhelés is nagy fogyasztást eredményez. A lépés erre a kis fogyasztású magok bevezetése volt. A lényegi elképzelés, hogy a kis magok mennek egészen addig, amíg el nem érik a max. teljesítményüket, ekkor válthatsz nagy magra. Miért jó ez?
Mert a kis magok fogyasztása annyival alacsonyabb a nagyokhoz képet, hogy nem probléma, ha az összes megy, még így is alacsonyan tartható a fogyasztás, illetve ha túl nagy a terhelés a 1db nagy magra rakják azt és így teher mentesül a kicsit és mehet vissza kisebb energiaállapotra.Mi ezzel a probléma? Hát a vezérlés.
Nagyon intelligens scheduler kell hozzá, hogy az adott feladatott, megfelelő magra rakja alapból, és arra is figyelni kell, hogy a váltások ne legyenek túl hektikusak, mert az is magasabb fogyasztást eredményez. Másik probléma a terhelés elosztás. Akárhogy is nézzük Android szereti a több magot ideálisan 4-et, és általában a scheduler 2-4 magot mindig használtat is alacsonyabb órajelen szinte mindig. Itt jön a B problematikája, terheléssel felmegy mindegyik órajele, és itt jön a scheduler akinek figyelnie kell, hogy a megfelelő folyamatot rakja a nagy magra, valamint statisztikát is vezet, hogy adott folyamat milyen teljesítmény idényű és ez alapján próbálja a megfelelő klaszterbe rakni alapból a folyamatot alapból. (Egészen mellesleg a benchmark trükkök úgy történnek, hogy megadják hogy XY program egyből nagymagra kerül és mind a 4magot aktiválva max. órajelen menjen amíg az a program fut, akkor is ha a program nem terheli le max.-ra, így a migráció és az órajel felfuttatási késletetés elkerülhető és jobb CPU eredmény jön ki a tesztben.)
Na most ha ezt az egészet 3 klaszterbe rakjuk az így elsőre jó ötletnek tűnik, hiszen még több fogyasztási szint van, és jobban belőhető az adott feladat az adott fogyasztási szintre, csak éppen ez az egészet vezérelni is kell. Az egész eredménye valószínűleg az, lesz, hogy 8 mag folyamatosan járni fog és 1-1 esetre fogyja az A72-ket használni ritkán, mivel a valóságban a mai worklodoknak ritkán van szüksége ekkora teljesítményre. Jól megírt vezérléssel egy 2 klaszteres megoldásnál kisebb fogyasztást eredményezhet. Persze azt látva, hogy ez a vezérlés 2 klaszter esetében is problémás és nem mindig működik úgy ahogy kellene, igazából erre a felállásra kiterjesztve nem mondom azt hogy nem lehet jobb, de vannak fenntartásaim.Amúgy marketing szempontból win-win a 10mag. Elméletben kisebb lesz a fogyasztás hosszútávon(jó vezérlést feltételezve), mert az A72-es magok szinte sose lesznek használva, szemben a konkurensek 2 klaszteres felépítésével, ahol a A57/72 magok sokkal gyakrabban lesznek aktiválva. A magas órajel feltüntetető a dobozon, magas órajel miatt benchmarkban jól fog szerepelni, lehet mókust vakítani vele nagyon jól. Sőt még a gyártása se lesz drágább, mivel a két kieső mag helyére jöhet a másik két klaszter, és a GPU is jóval kisebb, de 720p-n mérjük az Antutut és problem solved.
Persze szinte minden valós körülmény között 0 értelme lesz az egésznek és konkrétan 0 előnye a mostani 8magos A53-as SoC-okhoz képest, de így Mediatek is elmondhatja, hogy van 7x ezres Antutus SoC-juk. De az egész SoC a vezérlésen áll vagy bukik, mert ha túl sokat lesz aktív a A72 akkor bizony úgy leszívja az aksit az a 2,5GHz mint a fene.És akkor majd jön a S820 ami kb. pontot tesz a bohóckodás végére és 4 külön szabályozható maggal visszahozza a teljesítmény és a fogyasztás legjobb kompromisszumát.
-
vicze
félisten
Igen ez teljesen így van, van valamennyi overhead, de szerinted manapság egy A72 méretű behemóthoz maghoz képest ez mennyire elenyésző?
Max. Krait-A9 viszonylatban látok inkább overhead-et, de onnantól, hogy big.LITTLE ahol külön vezérlő kell a migráláshoz az in-order és a OOO magok között inkább előnyt látok mint hogy hátrányt. 3 klaszter domainnál meg abszolút overkill, az aSMP-hez képest.
A L1 saját van minden magnak L2 cache tudtommal osztott, így nincs szomszéd elérés és a migráció is gyorsabb a magok között. De ez azonos az ARM-mel vagy nem?A második is stimmelne, csak nem 2db szál van a valóságban, hanem most épp nyugalmi állapotban 150+ process fut N10-en (96 kernel, 56user) úgy hogy nem csinálok semmit, Androidról van szó ugye. Nézd meg a két táblázatot, amit tjb007 belinkelt egyik egy 4xA7 a másik egy 2xKrait. Na most nézd meg melyik SoC-on van olyan hogy alszik az egyik CPU azaz 0. Na ez itt a gond.
Mivel 1 domainak van véve az A7 SoC minden magja nincs mire migrálni, így elosztja kvázi egyenletesen a kis terhelést is, így az összes mag megy és nincs alvó. Ez én is alá tudom támasztani az N10-en sohase alszik egyik mag se, míg One mini-n megesik hogy alszik az egyik, bár ritka tényleg, de több magnál jobban kijön. N4-en már elég ritka hogy 2-nél több megy.Persze a fentiek govenor függvényében változtathatók meg halálig ki lehet helyezni energiahatékonyságra, csak az default interaktív az bizony ilyen, és normál user sose változtatja, illetve esetileg nem is tudja. Még mindig a legjobb kompromisszum a reszponzivitás és a hatékonyság között. Amenynire látom az MTK inkább a reszponzivitás felé tuningol amúgy, amiben azért igazat kell némileg adni nekik.
Lehet, hogy nem 8 hanem csak 4 mag fog menni, de iszonyat nehéz belőni az a határt, hogy mikor migráljon a két A53 domain között, ugye a lagot el szeretné kerülni a gyártó, és reszponzív készüléket akar. Amúgy az SW szabályozás így elég nagy overheadet ad, nagyobbat mint aSMP-nél a HW szabályozás.
Istenem...
(Annyira nem hülyeség szerintem. 
)
Új hozzászólás Aktív témák
ph A vállalat újragondolta az ARM Big.Little koncepcióját, méghozzá a jövőben nagy szerephez jutó új MCSI-re építve.
- Debrecen és környéke adok-veszek-beszélgetek
- ZIDOO médialejátszók
- Futás, futópályák
- Vallás
- TCL LCD és LED TV-k
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Yettel topik
- Huawei P30 Pro - teletalálat
- Azonnali fotós kérdések órája
- Mesterséges intelligencia topik
- További aktív témák...
