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

• #41 vicze félisten -Skylake- #36

  Új Válasz 2015-04-22 14:58:01 #41

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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.

  forrás - aSMP, forrás - GTS

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