Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Tříúrovňová big.little patlanice je největší idiocie v dějinách CPU. Od roku 2003 existuje perfektní Cool'n'Quiet a ani po 13 letech se ARM nemůže zbavit podobných trapasů odhalujích slabost jeho architektury. Udělat jen 3 až 4 silná jádra (dnes v max. výkonném mobilu asi optimum), co dokáží perfektně škálovat frekvence a počet zapnutých jader, je mnohem elegantnější a hlavně HW i SW jednodušší řešení.
Ani hodně bohatý Intel nedokázal za ty roky, aby bylo fungování hyperthreadingu perfektní a nějací arm-china zoufalci si myslí, že vyladí něco mnohem složitějšího - 3 úrovně velice odlišného charakteru výkonu pro použití ve světě horšího softwaru než měl Intel pod Windows-Linuxem.
Jasně a proto asi intel odpískal své mobilní čipy, nakoupil licence od ARM a bude vyrábět ARM soc.
Problem Intelu je trochu jinde. Atom je tragicky nevykonny procesor jehoz zamereni bylo stoprocentne na cenu, proste Intel dokazal vyvinout opravdu levny cip a nahodou si pritom vsiml, ze to ma i nizkou spotrebu energie a mohlo by se to pouzit v mobilni oblasti. Jenze vyrobci, kteri jedou v ARM segmentu dokazali sva reseni vykonove posunout uplne jinam a tomu Atom konkurovat nemohl.
Intel ma preci skvele vykonne procesory vcetne uspornych i3-xxxxU, jenze uz jsme tu debatovali o tom, ze predstava, kterou jsem tu propagoval, posunout tyto procesory nebo respektive jejich dalsi zusporneni tak, aby to vyhovovalo mobilnimu segmentu pro smartphony, je nerealna a tudiz Intelu nezbyva nez take zacit s ARM, pokud se chce do teto oblasti smartphony, tablety dostat.
Atom bol tragicky nevykonny, posledne Atomy boli viac nez slusne ale to je taka stigma Atomu ktora urcite tiez ma svoj vpliv na to preco to Intelu nevyslo. Tak isto sa Intel dost neskoro nahrnul no mobilnych SoC kde uz proste konkurencia je velka, zvlast ked Intel nieje na to zvyknuty ze musi superit s viacerymi vyrobcami a nie z jednym ktory to mal viac krat na kahanku :-). A uz vobec nemoze konkurovat tej zaplave z Ciny, tam ho proste podlezu cenou alebo uplatia a hlavne je ich vela.
"zamereni na cenu" ? "nahodou si vsiml ze ma nizkou spotrebu" ? ROFL ... ty jses tak brutalne mimo... za a) Intel nikdy nedokazal nabidnout nic, co by cenove konkurovalo ARMum, a za b) dnes se procesory vyviji s tim ze dopredu se urci TDP (nebo rozmezi TDP). Takze zkus priste premyslet nez napises nesmysly typu "nahodou si vsimli ze to ma nizkou spotrebu" ...
Tohle preci nesouvisi primo s ARM.
ARM dela navrhy architektury cipu a dela je dobre. Jenze pak je treba si to dodelat na miru toho, kde to chci pouzivat.
Prikladem tak muze byt skvele SoC Apple A10 Fusion nebo Qualcomm Snapdragon 820.
Ani u jednoho se zadnych 10 jader nekona a energeticka ucinnost a skalovani vykonu je mnohem lepsi nez u trapneho Mediateku.
Samozrejme Mediateku fandim, aby se nove Helio X30 povedlo a dokazalo to konkurovat ostatnim vyrobcim ARM SoC, ale zatim Mediatek predvadi spise tragicke slepovani jader a cipy nemaji ani dobre vyresene skalovani ani potrebny vykon pro highend zarizeni.
A10 Fusion není vůbec povedený SoC, výkon sice má, ale je energeticky hodně náročný, přirovnal bych ho k Snapdragonu810v1 ten také moc nepovedl.
Snapdragon820 je už povedenější, i když Exynos8890 nebo Kirin950/955 mu v některých parametrech ukazují záda.
A10 Fusion má deset jader, 4xCPU a 6xGPU.
Snapdragon820 4xCPU a 4xGPU.
Helio X30 je beatne oba levou zadní, Helia a Exynosy mají oproti Snapdragonu výhodu ve vysokém procesorovém výkonu při nízké energetické náročnosti, jemná se o velice úsporné SoC.
A10 Fusion je šílený žrout...
Můžeš svoje tvrzení něčím doložit?
Jenomže tady se bavíme o jiném energetickém řádu, než obsluhuje Cool'n'Quiet. U x86 procesorů (a opravte mě, jestli se pletu) nikdy nebyl mechanismus, který by umožnil nějakému jádru běžet na jiné frekvenci, než zbytek jader - můžou být buď vypnutá, nebo běží všechna stejně.
Zavedení dalších rychlostí najednou není obecně úplně špatný nápad. Pokud by spotřeba rostla lineárně s frekvencí, pak by to bylo k ničemu. Vezměme si jádro na frekvenci X, které danou úlohu zpracovává Y sekund. Při frekvenci X*2 by jádro mělo sice dvojnásobnou spotřebu, ale úlohu by splnilo za Y/2 sekund, takže při stejném množství energie.
Jenomže takto to není, spotřeba roste s frekvencí exponenciálně, takže při dvojnásobné frekvenci je spotřeba více než dvojnásobná. Pokud všechna jádra tvoří jenom jeden cluster, pak není na vybranou a nejvíce "nenažraný" proces vytáhne celý procesor k nevyšší frekvenci a ostatní procesy, které by teoreticky mohly jet pomaleji, musí jet taky na maximální frekvenci a dochází k plýtvání energií.
Rozdělením do více clusterů můžeme jednotlivé clustery taktovat separátně (a toto nemá v x86 obdobu!) a pomalé procesy nechat v pomalejším clusteru. Přitom "pomalý" cluster nemusí běžet na své maximální frekvenci, třeba tady u toho Mediateku může být klidně první cluster na 2,8GHz a třetí na 1GHz.
Druhá otázka je, jak to ošetřit softwarově. Jak to tam aktuálně je v androidu řešené nevím, pokud scheduler "hádá" jenom z minulosti, tak to není asi žádné terno, ale pokud by se procesy daly "označit" jako low-priority, tak by se z toho dala docela rozumná úspora vytřískat.
Nie, je to pakaren. Este by sa dalo nejak obhajit delenie na dva clustre - vykonny a bezny prevadzkovy. Ale davat dam dalsie to je uz na chuja. Nakoniec skoncime s 20timi jadrami ale kazde bude na inej frekvencii, inou specifickou instrukcnou sadou a zamerane na nieco ine. To uz sme na urovni koprocesorov akurat ze to je v jednom puzdre. A hlavne je otazne do kedy je to naozaj uspora a kedy to uz zacne byt skor problematicke pretoze samotny management takehoto niecoho moze zozrat viac prostreidkov a casu nez potrebuje bezna uloha na tom nevykonnom jadre.
Ostne ako je v komente nizzsie uz tu vyskakuju problemy s cluster riesnim. Vykonne jadra maju vecsiu cache ako tie nevykonne a ked uloha zacne na nevykonnom jadre a OS ju neskor chce presunut na vykonnejsie jadro, nastava problem.
Některé x86 to určitě umí. Minimálně jsem viděl "úsporný" Athlon X2 64 a u Phenomu se dá pomocí malého prográmku nahradit Cool'n'Quiet z BIOSu "vlastním" řešením, jejíž jednou volbou je i řídit jádra separátně. Pod Windows to má nicméně záporný dopad na výkon kvůli jejich schedulleru, který úlohy "pod parou" inzenzivně přehazuje po jádrech a ta přeci jen mají zpoždění než situaci vyhodnotí a najedou na plný takt, takže výsledkem je značný propad výkonu (pokud se nejedná o vzácnou zátěž na všechna dostupná jádra). Takže spíš než že by to nešlo je problém, že pod Windows to je nevhodné řešení.
Co mám Intely, ty jsou zamčené, tak nevím jestli něco takového umí, ale asi není důvod aby nemohly.
S bigLITTLE si nejsem jist, jestli to spíše není následek poněkud bláznivé architektury Androidu, protože jinak mi není jasné proč Apple stačí dvoujádra a na droidy se potom musí s takovými bláznivými mnohojádro-slepenci. Jestli je problém udržet jádra idlovat a tak je lepší nechat slabší zátěž běžet na slabém jádře co tolik nebaští, nebo co.
To bude tak pol na pol :-). Cast popularity bigLITTLE bude zasluhou marketingu. Predsa len vzdy je viac pruhov viac Addiddas :-) no a 8 jadier je vzdy viac ako 4. Aj ked napriklad Qualcomm sa dlho drzal len s 4 vykonnymi jadrami a dynamickym podtaktovanim. Dalsi dovod moze byt ze Apple si predsa len celu platformu kontroluje a dokaze si to cele vyladit kdezto Android je zlepenec. Dalej iOS aplikacie su nativne kdezto Android zo zaciatku bol Javovsky kod beziaci na JVM co gnerovalo dynamicky bordel. Teraz je to trochu lepsie kedze Google zahodil dalvik a pouzivaju ART - javovska binarka sa preklada do nativneho kodu uz pri instalacii. Otazne je ale ci aj art optimalizuje specificky pre kazde SoC alebo ci samotny dodavatelia telefonov doladuju/optimalizuju ART pre svoje SoC (dost pochybujem). Takze sa ide hrubou silou - pridavaju sa jadra pri zachovani, ehm, rozumnej spotrebe.
1) Windows scheduler to nedela jen pro ulohy "pod parou", on to dela se vsemi ulohami, neustale. Proc, to se me neptej, netusim. Linux taky ulohy prehazuje, ale mnohem mene.
2) Jak pise dale jiny prispevatel, prakticky vsechna moderni x86 CPU (AMD i Intel) ridi frekvence jader nezavisle na sobe (teda temer - HT/moduly). Edit: Tak nakonec ne, Intel tohle umi jen u nekterych cpu (Xeony). AMD to ma uz delsi dobu.
big.LITTLE neni nasledkem architektury Androidu, je to zpusob, jakym ARM resi efektivitu pri ruznych stupnich zateze. Tyhle 8 a vicejadrove slepence vznikaji z ruznych Cortexu, pokud si vyrobce navrhuje svoje vlastni jadra (Apple nebo Qualcomm, u Samsungu mam pocit, ze ty jeho "vlastni" jadra jsou jen upravene Cortexy), tak tolik jader nepouziva, momentalne jsou v SD820 a A10 2+2 jadra. SD810 byl v konfiguraci 4+4 jadra, ale tam se jednalo o Cortexy.
Trepeš somariny. Phenom II dokázal taktovať jednotlivé jádrá samostatne. Asi si zabudol pohľadať v googli a overiť fakty. To tak dnešné deti, myslia si, že všetko je na nete a vo vlastných hlavách informácie žiadne.
Nechápu, proč do něj kopete, když zdůrazňuje nejistotu svého výroku.
Když si tím není jistý tak ať neargumentuje! Tvůrců hypotéz je všude jak na*ráno a tohle není brainstorming session....
Dobře, uznávám, že mám málo zkušeností s AMD. U Intelu to ale podle mých zkušeností opravdu nefunguje (a Intel AFAIK nikdy netvrdil, že jeho procesory to umí, takže je to OK), více třeba tady - poslední příspěvek:
https://software.intel.com/en-us/forums/software-tuning-performance-opti...
Tzn. otázka je - funguje to opravdu aspoň u těch Phenomů, nebo to zobrazuje jenom "request" na danou frekvenci? Jede uživatelův kód opravdu různou rychlostí na různých jádrech s různou frekvencí?
Jo, fakt to funguje popisovaným způsobem. :-)
Každé jádro může při "odděleném nastavení" nezávisle přecházet mezi stavy P0 - P3. Je to i hezky vidět na všemožných "monitorech" frekvencí. Defaultně nicméně běhají spřaženě - viz. zmíněný problém se schedulerem.
Nicméně Intelovo Turbo, to by mělo také navyšovat frekvece jen individuálně, ne?
Upresnil bych to - u Phenomu lze taktovat samostatne, u Bulldozeru a novejsich lze AFAIK taktovat samostatne jenom moduly (tj po dve jadra), opravte me jestli se mylim. To same plati u Intelu s HT - HT jsou defacto "virtualni" jadra, taktovat samostatne lze to "skutocne" skryte za nima.
Nevim presne jak u intelu/Win, ale u AMD/Linux to urcite funguje uz leta.
Mam nekolik ruznych CPU rady athlon2, na panelu mam vyhozeny applet na sledovani frekvence kazdeho jadra a krasne je videt jak se frekvence jednotlivych jader meni nezavisle na ostatnich.
To se pleteš, vždyť turbo u Intel Core je postavena na tom že některá jádra se oturbí...
http://www.intel.com/content/www/us/en/architecture-and-technology/turbo...
Jo, ale neoturbí se samostatně. Některá se vypnou a ostatní jedou rychleji, ale všechna stejnou frekvencí.
A este ked maju inu cache line size, su z toho neuveritelne Bugy:
http://www.mono-project.com/news/2016/09/12/arm64-icache/
Helio aj Kirin su take S3 Savage v casoch prvych GPU. Papierovo to ma super parametre ale v reale to uz take ruzove nieje. Vsetky dnesne top ARM SoC pre mobilne zariadenia pouzivaju svoje custom jadra a vykonne GPU zatial co Helio aj Kirin bezi na standardnych ARM jadrach a pouzivaju skor slabsie varianty Mali, tak aby to nieco zobrazilo a to staci.
Tohle by mně nevadilo, pokud je to spojeno i s nižší cenou a to většinou je. Problém je v tom jak se snaží o co nejvyšší výkon a kašlou na co nejmenší spotřebu. Na web, svižné prohlížení fotek a další běžné funkce by stačil třetinový výkon (hlavně nižší frekvence) a tento výkon by šlo dosáhnout s poloviční spotřebou. Pařit náročnější hry na mobilu je stejně zbytečné a ani to většina lidí nevyžaduje.
Jenže on to je takový pěkný tradeoff, třeba zrovna ten Kirin má velmi dobrou výdrž na baterku při rozumném výkonu.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.