ez a 4-4 db eltérő órajelű A53 nekem kicsit furcsa.

BIOS/UEFI írás, helyreállítás, törlés, mentés! https://www.bvinarz.org/bios-iras/

****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 ]

Mi a furcsa benne, eddig is léteztek ilyen desingra építő megoldások?

Légvédelmisek mottója: Lődd le mind! Majd a földön szétválogatjuk.

Az Imagination PowerVR 7-es szériájáról szólnak a pletykák, azon belül is a GT7200-ről és GT7400-ról.
Amúgy meg meg szuper, hogy eljutottunk a bűvös tízes számig. No comment.

(#1) vinibali

"Szegény ember" big.LITTLE-je. Nem új dolog, a Qualcomm és a Huawei is (van egy olyan érzésem, hogy kihagytam valakit) alkalmazza.

(#2) vicze1

Támogat.

[ Szerkesztve ]

Amikor ezt sikerult ebben a formaban megfogalmaznod , akkor volt mogotte valami komolyabb gondolatmenet vagy csak leirtad azokat a szavakat amik eszedbe jutottak ? Eltekintve attol , hogy hulyeseg amit irsz , nyelvtani szempontbol is ertelmezhetetlen.

ON : a 2db a72 tenyleg jobb mint 4 a53 ? Vagy mukodhetnek a72+a53 felallasban is ?

"Those who would shave the beard for pussy deserve neither the beard or the pussy." - Ben Franklin, probably

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 ]

10 mag, szép kerek szám. Az antutu eredmény csak egy dolog. Kicsit olyan mint egy tuningolt autó a dyno padon. Szép amit a padon kihoztak belőle, de lássok a hétköznapokban mit tud, és mennyiért. Igazából nekem a 8 magos 1,7-is teljesen elég.

Szerintem lesznek itt még szoftveres optimalizációs gondok bőven.

Ha saját szívedben nem találsz békét, nem fogod azt megtalálni a világon sehol. (SCKG)

Igen, jobb. A többi majd jövőre kiderül (vagy az idei év végén, ha nagyon optimisták vagyunk).

(#6) vicze1

CCI-500
Vagy mire irányult a kérdés ?

[ Szerkesztve ]

Lassan tényleg több mag lesz egy telefonban mint egy jó pofa dinnyében...

"Mert Ő küld 100 csodát, csak Benne Bízz!"

Érdekes. Biztos jó ötlet 20 nanon 2,5GHz-n pörgetni 2 CA72-t? 16/14nm-en még megérteném...

Nem teljesen értem a felállást... gondolom 2 ill 4-esével lehet kapcsolgatni a clustereket

tegyük fel a köv terheléseket
full load 2+4H+4L
heavy load: 2+4H
medium load: 2+4L
low load 4H + 4L
ultra low load: 4L

namármost a heavy/medium load között nincs váltási lehetőség, gondolom taskokat migrálni egy proci clusterről a másikra nem igazán lehet, vagy tévedek?

nem tudom miért nem egy 4 (A72) +4 (A53)-es felállással és dinamikusan változó órajelekkel oldják meg a dolgot... ott nem a load a taszkok függvényében szépen skálázható oda/vissza és nem kell semmi extra mágia

Igen arra, hogy a CCI-500 nem csak 2db 4magos klasztert tud kezelni?
Ezért gondoltam, hogy ehhez már a szerveres verzió kell több klaszter kezeléséhez.

Most akkor ez kényszer mert nem tudnak 20nm en kisebben gyártani? Vagy ennek tényleg van értelme?

[ Szerkesztve ]

Ott a képen.
Nem csak két sebességes váltód van hanem 3. Teljesen jó hasonlat, csak hogy ezt ki gondolja jó útnak...
Vezérelni meg kb. rémálom lesz.

Full terhelésen az akksi meg meg murdél

Nem az érdekel,hogy hova postázod,hanem hol van a termék!!!!!

10 mag
és van program ami kihasználja majd?
Vagy Az Android majd alapból használja a 10 magot ha megérintem a képernyőt?

és (#4) tjb007: nem tudtam, hogy volt aki csinált már ilyet, de akkor is tök logikátlan. nem lenne egyszerűbb inkább a freki szoftveres skálázásával foglalkozni, inkább raknak bele még 4 magot

BIOS/UEFI írás, helyreállítás, törlés, mentés! https://www.bvinarz.org/bios-iras/

Nem is tudom, van egyáltalán dinamikusan szabályozható frekvenciájú ARM?
Ha van akkor itt miért nem azt használják?
Ha nincs, akkor mi az akadálya? (Integrált dinamikus fesz.szabályozás?)

Ha tudnám se erősíthetném meg.

(#14) vicze1

Négyet tud, tehát max. 16 p.magig lehet elmenni.
Ha nagyon gonosz szeretnék lenni azt mondanám, hogy a CCI-500 direkt a MediaTeknek lett kitalálva, miattuk lett megalkotva.

(#20) vinibali

Ha arra gondolsz, amire én is, akkor a válasz az, hogy nem. Az ARM által tervezett p.magok nem tudnak egymástól függetlenül órajelet változtatni.

már hogy ne tudnának. cpuz-vel időnként ránézek az órajelekre, különböző frekiken futnak és ha úgy alakul magok elkapcsolásra is kerülnek!

BIOS/UEFI írás, helyreállítás, törlés, mentés! https://www.bvinarz.org/bios-iras/

Az elég érdekes lenne. Milyen telefonod van ?

[ Szerkesztve ]

Nekem is így jelzi ki az MTK chipsetes telefonom. Alapjáraton 1 mag megy 500Mhz-en, és terheléstől függően felmegy az órajel és bekapcsol +1 vagy a többi 3 mag. (CPU-Z szerint).

Szerintem ő arra gondol hogy
CPU0=600mhz CPU1=800mhz pl.
mindez párhuzamosan.

Egyébként mtk6572 esetén is van ilyen,de max 1-2mp,utánna már mindkettő cpu órajele megegyezik,ez lehet a skálázási idő pici elcsuszása is.

[ Szerkesztve ]

Abban biztos vagyok hogy ez valami gagyi marketing fogás lesz, de értelme nem sok annyi szent

Ok, de mi értelme a különböző teljesítményű magoknak, ha megoldható, hogy mondjuk 4 vagy 8 közepes teljesítményű és fogyasztású magból csak annyi menjen (és fogyasszon) amennyire épp szükség van.

szerintem max 4 magnak van értelme azok is egyenlő orajelen.
az alkalmazások szerintem kb 2/3-a max 1 magot használ.

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.

5s és leszabályoz. Biztos, hogy 14nm alatt lesz.

"Az ARM által tervezett p.magok nem tudnak egymástól függetlenül órajelet változtatni."

Rég volt már droidom, de a systemdata Nexus4-en a négy magra vetítve eltérő frekvenciát mutatott.

Nemsikerult megfognod a lenyeget

#32 : engem erdekel. (szarkazmus nelkul , tenyleg erdekel. szerintem is problemas lesz ez a felallas , de erdekel , hogy szerinted miert )

[ Szerkesztve ]

"Those who would shave the beard for pussy deserve neither the beard or the pussy." - Ben Franklin, probably

Nekem sikerült
De a 2+4+4 magnak nincs értelme
Mert az Android sem igényli alapból ezt
Ha alkalmazások támogatják akkor jó
De pc-n nincs olyan app.

N4-ben nem ARM által tervezett magok vannak, hanem Qualcomm által tervezett Krait magok.

@-Skylake-: Ha nap közben lesz időm, akkor leírom.

[ Szerkesztve ]

huge.Medium.TINY, ezt az elnevezést adta a MediaTek ennek a háromklaszteres "saját megoldásnak".

A tegnapi órajel szabályozás témához kapcsolódóan csináltam profilozást két, az ARM által tervezett processzormagokat tartalmazó SoC-ről: [link], [link] Jól lehet látni, hogy miről is beszéltem.

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.

forrás - aSMP, forrás - GTS

Az aSMP finomabb szabályozást tesz lehetővé, de vannak hátrányai is:
- bonyolultabb felépítés, több tranzisztor: több clock domain, több feszültség és frekvencia szabályzó
- szomszéd cache elérés: a cache milyen frekvencián megy?

Amit a Cortex vezérléséről írsz, az nem úgy van, a vezérlés nem olyan egyszerű:
- ha csak egy szál fut 100 %-on, akkor feleslegesen nem kapcsolja be a többi magot, hiszen egy szálat nem tud két helyen futtatni
- ha szükség lenne két szál esetén 100 % + 10 %-os teljesítményre, akkor már bekapcsolja a második magot, és 10 %-os szálat átteszi oda
- ha egy magot nem használ ki teljesen, akkor nem pörgeti feleslegesen, hanem energiatakarékos üzemmódba lép: WFI (Wait For Interrupt), ilyenkor nem kap órajelet, pl. 10 %-os használat esetén az idő 10 %-ában dolgozik és az idő 90 %-ában vár WFI-ben

Az egész eredménye valószínűleg az, lesz, hogy 8 mag folyamatosan járni fog [...]
A fentiekből következik, ha nincs terhelés, akkor nem pörgeti a nyolc magot.

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.

Egészen pontosan 4xA9 és 2xA7. Tudtam, hogy elfelejtettem valamit még odaírni. Krait most azért nincs, mert az ARM magjairól volt szó, de majd holnap csinálok arról is. A nullás alvás meg csak a governor miatt van.

Egyébként én úgy érzékelem hogy Androidban az "érintés" hirtelen feleslegesen pörgeti fel a magokat
Kiprobáltam hogy ha a két mag 598 mhz en fut,alig lassabb mint a két mag 1 ghz-en
szerintem sok esetben a kernel hagyja a magokat feleslegesen felpörögni.
Igazából az lehetne a megoldás ha maga az Android rendszer kapna külön magot,aminek az órajele fix,és az kezelné le a többi mag kezelését is.
Ugyanis igy az a helyzet hogy néha olyan feladatoktól is felpörög amikhez a legalacsonyabb órajel frekvencia is elég lenne.
A grafikus kezelés zabálja a legtöbbet
Hiába van hardveres gyorsitás,ha ennyire cpu függő az UI kezelés.

Azta. Koszonom szepen.

"Those who would shave the beard for pussy deserve neither the beard or the pussy." - Ben Franklin, probably

Itt van a Krait is: [link]

[ Szerkesztve ]